Aaron has had some ups and downs getting the packages together, and I've been pretty busy with school, but work is in fact proceeding at a healthy rate once again. Alistair and I are working on a new Unicode library, Jordy committed a new and very spanky reimplementation of the registrar, I rewrote the reactor class and removed the dependence on RTTI in the factory loader, Laurie fixed up libdatatype, and Stefan (while presently on vacation) promises to be working on much improved graphic classes with Jonas and myself early in the new year. My big goal on the holiday is to get the text renderer alive and displaying text; although the complete glyph layout and remapping will proceed more slowly as I learn the guts of opentype a little better, some basic functionality should be pretty quick in coming.

The DR1 packaging process is officially underway. We're working out bugs in the build tree and writing documentation in DocBook (SGML). The Packages should hopefully hit the net before the Atlanta Linux Showcase (23rd), assuming everyone manages to compile the thing and work out all the dependencies. This will be a baseline release with virtually no visible functionality but a reasonably stable core on which you can build OpenGL widgets and client applications. The text system is still untested and the registrar remains to be integrated into the display server, but these will not prevent you from playing with it.

Ok, I think we're at a point now where there's nothing but bugfixes going into DR1. Basically I've got most of the showstoppers killed (with the help of my smiling Buddha, rubber frog, and an unholy amount of coffee), and the design isn't shifting under our feet every couple days anymore. In the meantime, egcs 1.1 is out and Berlin works well (and a little smaller) under it; a new omni snapshot is out with all the trimmin's, Mesa 3.0 was finally released with full GGI support, and GGI itself is moving towards 2.0. The Berlin server has stabilised tremendously, and it now runs 95% out of shared libraries and plugins -- the actual executable is a couple hundred k. People are setting up packaging environments to ship DR1, so it should be along shortly. If only I had a faster CPU!

Sorry, I've been moving recently and that has stalled things a bit. I have lifecycle up and working now, in a state I hope to leave it for some time. It supports object migration and hot-swapping now, including automatic reloading of all instances and state transfer. Hopefully it doesn't need anything else fancy before DR1, although the skeletons have become truly astronomical. I suspect egcs 1.1 will address some of this. I've redone the message passing system as per Duncan's recommendations, and it now uses Anys instead of messages, although you can still use messages if you want hierarchical typing. This should make events a lot cheaper to process. So we're a little ways behind schedule, but only a week or 2. I'm all moved in now so I can bang out some more code nice and fast before classes begin.

I've done most of the lifecycle changes and text subsystem, and Jonas and Yusef have rapidly taken up the slack in developing new widgets for our DR1. A tweaked omniidl2 backend (from Duncan's web page, available here) is required to use the new lifecycle code. I also got a groovy graph-visualisation package working, so you can see the Warsaw inheritance hierarchy on the Warsaw intro page.

Well, good news followed by good news: Mesa 3.0b7 comes with GGI support in the mainline source tree, so no more messing around with patch-of-the-month-club. Secondly, perhaps more significantly, Andrew's libGFont is now in the CVS repo. This is the last thing standing in the way of making text work -- now we just have to glue things together in the right shape and fight egcs tooth and nail until it lets us compile and run. You'll also notice there's a new "timeline" page, which details the planned milestones and where we're at now. This might keep people from sending the "how close are you to done?" email I seem to be flooded with.

The majority of the interfaces and implementations are in place to begin displaying text on the screen. This is good, because ANOQ has committed a whole bunch of DOM implementation code, and Andrew has committed a library for automatically determining file types, including multiple font formats. We should be on track for text-displaying programs by the end of the summer

We now have a skeletal, but extensible security system in place, allowing you to selectively grant access to operations depending on the principal talking to the display server. This should serve as a basis for future security enhancements like public key authentication. Also, Jonas has begun work on mouse events and some widgets which actually do things, like buttons.

After much fiddling and tweaking, the Berlin server will now happily load widgets, move messages between them (including keyboard events), compile OpenGL display lists, and show them on the screen using a multi-threaded, asynchronous hierarchical double buffering scheme, exactly as we had planned. I actually had this working on the July 1st, but I wanted to work out some display bugs and a deadlock problem before I posted news to the site. This represents a major milestone in the development process. It's not yet at the stage where it's easy to install, so unless you've got a lot of patience and luck with shared libraries in C++, you'll probably have to appease yourself with this screenshot. It's just a grey box, but it could well have been anything representable in OpenGL, like a huge semi-transparent NURBS chihuahua.

In other news, ANOQ has incorporated the interface declarations for the W3C's Document Object Model into Warsaw, and is now filling in implementations of the various classes.

I have finished tweaking a patch against the mesa 3.0b5 source tree in order to get it to work with libggi 1.4.0 (degas). The patch has been added to our CVS repository along with the Omni Patch, in a new "patches" subdirectory. At this stage, Berlin is booting cleanly into an up-to-date GGI. Now it's onto porting koala and gltt!

I have produced a bare-bones version of our display server ported to GGI-Mesa. Each display area is no longer a rectangle; rather it is an arbitrary piece of OpenGL code compiled into a small display list, which is called hierarchically as its parent renders itself. This neatly circumvents the requirement of finishing libGWT, although it may turn out to be really useful in optimising special clipping cases. We shall see ;)

Further improvements in this version include a new debugging class and a vastly improved demand-loading system for plugin objects (Duncan thinks it's looney, but I like it). Unfortunately you need a really obscure combination of software versions and patches to make it run, and until I've got my GGI-Mesa patched against the new GGI source tree you're not likely to be able to reproduce the conditions on my home machine too well. You can try it with a Uwe's GGI-Mesa patch and libGGI 0.0.9, but I make no promises yet. Getting a proper, up to date patch into our CVS repo is my #1 priority right now.

Things went very well at Linux Expo. Lots of discussion about what Linux GUIs need in the long run and how to go about accomplishing it. Also lots of people who were new to Berlin expressed interest in hacking it. So happy-day for us! The most significant item was that OpenGL emerged out of conversations as a viable imaging model for Berlin. Whether we can achieve the speed we need through optimisation of the Mesa-GGI library remains to be seen, but it certainly gives a good direction to work in. The goal of a prototype by fall seems not only possible, but very appealing to the people I talked to at the convention.

The web site has been somewhat updated along with the cvs repository, thanks to Jordy. Jordy has also begun work porting registrar to use COS Name service to simplify access. We had another major meeting and worked out a lot of details, hopefully all of which will come together as we have increasing free time over the summer to work on it. I am focusing now on getting our interfaces in line with the CORBA COS 2.2 specifications for lifeCycle, Naming, Relationships, Security, etc. wherever appropriate; as well, I'm developing a very nice text rendering and layout system with Andrew, and also path-based geometry interfaces for DTP and CAD. Jonas is hard at work getting libGWT working. Brent is working closely with GGI people to get a stable kernel image for us to work with, and ANOQ is developing and implementing APIs for string storage and editing. So everyone's busy! If you want to help out, please get in touch.

Thanks to Martin Schulze of the Debian Project, we have our mailing list moved to a nice stable friendly location which hopefully will not change for some time. The address remains "design@berlin-consortium.org"

If you want to subscribe, mail to design-request@berlin-consortium.org with the word "subscribe" in the body. If you're having trouble with the mailing-list software, mail listmaster@berlin-consortium.org. NOTE: If You were on the old list, you're STILL on the new list -- don't re-subscribe!

The Berlin display server now performs more-or-less successfully the following bootstrap sequence:

1. GGI initialisation
2. CORBA initialisation
3. Loading of plugin messages, commands, and widgets
4. Registration of plugins with COS nameservice
5. Instantiation of terminal object, including obtaining message and command clones from nameservice

Furthermore, this is all going on in separate threads. Terminal is serving requests asynchronously from the moment it's created, as are the proto-objects. Very exciting!