I've just posted the formatted log of our meeting from Thursday on the IRC page. In this meeting we discuss what we should target for M3.

The M2 release is the first one with a release cycle as short as three months. As such it was an experiment, and I think it was quite a success. The milestone is released even though not all assigned bugs could be closed in time. I think for now it's more important to send out the signal that we are actually able to stick to such a release cycle. May be we should be more realistic about what bugs/tasks to assign for M3... Find the release at our releases page.

Long awaited, this release marks the end of the transition from the old 'berlin-consortium.org' to the new 'fresco.org' with all the implications: new website and infrastructure, reworked and much enhanced source code structure, and quite a lot more. Read the M1 Release Notes or get it from our releases page.

Fresco now has its own issue tracker. It is used to track bugs, as well as tasks, and milestones. The tool will be further enhanced as we learn how to make good use of it, but it's already doing a terriffic job. Have a look at issues.fresco.org !

Nicholas did some work on hardware accelerated OpenGL on SDL a while back. To allow for that Stefan had to change the Console layer yet again (breaking every console but GGI). This time you can add Extensions, this time the API should be flexible enough to stay around for a while.

I just committed a SDLConsole using the new API. You can run the LibArtDrawingKit or the GLDrawingKit on top of that. It uses the same hardware acceleration as other SDL applications!

It really rocks running Berlin on SDL/GL on my GeForce! Check out the sources from CVS and try for yourself.

Nicholas sent us a patch that enables the PSDrawingKit to actually do something. The result can be seen at The February 5, 2002 Screenshot. Of course, there are still a lot of tricky issues ahead, but being able to demonstrate how to get a printout just be traversing the scene with a PS renderer is such a nice thing :-)

I committed some changes that will allow for bidirectional textflow according to the Unicode standard. The editable text demo uses the new VisualTextBuffer, so give it a try if you can enter hebrew text with your keyboard.

After some furious work Stefan moved the Console, an abstraction of the underlying Input-/Output system, into a module. So you can now select whichever Console you want when starting up the server. The reason for this was a dependency issues Bastian discovered when building his debian packages: All Kits implicitly depended on the graphic's library used by the Console (GGI, SDL, ...). The bad news: Currently only GGI and SDL consoles are operational.

Stephen Davies has spend some time profiling Berlin and found that a lot of time is spend inside the ORB. The omniORB developers were asked about possible optimisations and a day later those were already in their upcoming omniORB 4 release. Berlin uses them now and Stephen reports a massive speedup. For further research on ORB-based optimisations Stefan ported Berlin over to TAO, which offers more optimisation options then omniORB. This code is not very well tested yet, but it seems to work.

Alexander Johannesen is working on a new website for Berlin. It will have a structure that will hopefully make it easier for people to get into Berlin.

I have spend my time building and debugging some code for bidirectional textflow. I hope to get it into a presentable state before new years eve...

With all these new features we are heading for a new release, hopefully hitting a server near you early next year. For now you will have to check out our sources from CVS. Stay tuned for more exciting news:-)

Stanislav Ievlev has just informed me that the russian ALT Linux distribution has a and a of Berlin. He said the RPM is specific to ALT Linux, but the SRPM should work for any RPM-based distribution.

I had trouble downloading the files with Mozilla, but I was able to retrieve them with a normal (passive) FTP client. Give them a try;-)

Thanks to Bastian Blank's work we now have debian packages! Try them out and give bug reports. They are available at incoming.debian.org or people.debian.org, but should get moved into the unstable distribution soon.

Robert Jacolin spend a lot of time translating the Berlin Tutorial and the Berlin Manual into french. Those documents are available from his homepage (see the new page) or from our page}.

Not much is happening these days, but still, there is some new code from time to time. Today it's a couple of fixes to get basic 3D Primitive support up and running, so Tobias has something to show next week in Stuttgart at the LinuxTag. It's not much, mind you. Here is a little teaser.

A new release just hit the wire, featuring lots of new and interesting things, such as support for a number of different consoles, a GGIKit for animation and client side rendering, a UnidrawKit for graphical editors, and lots more.

Some demo clients written with Java are working (see here):

• a Mailnews client (using the Mozilla Mailnews backend) (it is not usable: it can only list folders so far)
• a primitive XHTML browser
• a XML tree viewer.

One of the advantages of using CORBA so fully is that of process and location transparency. This screenshot shows a Graphic, a node of the display graph, implemented entirely in Python by reimplementing the appropriate CORBA interfaces in Python. The server itself was not even recompiled to use this new Graphic; it just worked! Of course there is a speed penalty due to the context switches, but this leads to exciting opportunities for RAD using Python. Once tested, redesigned, optimised etc, the Python prototype can then be reimplemented in C++ in a short time to run at full speed.

In Unicode 3.1 the requirements for Unicode conformance will be changed. So Babylon will be fully Unicode compliant once version 3.1 is out. This is great news (especially since I don't even need to do anything;-)

I hope to have more time soon, so that I will be able to add Unicode conformant code for bidirectional textflow.

With the Unicode-related functions in Prague growing out of size, I moved them into a new library called 'Babylon'. It will provide all the functionality defined in the Unicode standard (it is not Unicode but ISO 10646 compliant as it uses 32bit wide characters internally) and is written in C++. Since it only depends on Prague it can be used independent of Berlin. More information can be found here.

Berlin now uses Babylon instead of Prague::Unicode (which is now obsolete and was removed from the CVS-tree) for its text processing.

The UnidrawKit starts working. The client registers a catalogue of tools, and the selected tool then intercepts events (by means of 'Manipulator' objects) to create and modify client side objects (Unidraw::Component). As expected, a couple of bugs and missing features have been fixed en passant... Here is a screenshot of the first Unidraw editor in action.

While the last build system was already quite good, it seemed far to complex and messy. The new system aims to be small, yet flexible. One of the new features is the ability to build anywhere, i.e. in particular outside the source tree. This implies that we now can maintain multiple build trees depending on the same sources. On a different note, we now have some first draft of a UnidrawKit. The goal is to port John Vlissides' Unidraw framework to Berlin, which provides the backbone for domain specific graphical editors (diagrams and graphs, vector graphics, UI builders, may be even 3D modellers,...). Here is a first minimal drawing editor, similar to Fresco's 'figgy'.

There has been quite a bit of work going on over the summer, which flows into this release. Even though there's nothing visibly new, the architecture changed quite dramatically: First of all, there is the port to the POA, which triggered a number of changes. We now have working memory management and the server is somewhat more fault tolerant. Also, Berlin has a new abstract console layer which makes it independent of GGI and allows it to be ported to even more platforms. Finally, the first steps towards generic 3D support are done, some interfaces for 'Primitives' and a 'DrawingKit3D' are part of this release. You can pick it up at our page at SourceForge.

With amazingly little effort we finished the move to omniORB3 and the POA architecture. This is very exciting because finally people can try out different ORBs and see what the speed and memory footprint is.

After some busy weeks of profiling and bug hunting we have finally decided that it's time to release again and this time increase the major number by one. This means we consider this a somewhat self-contained and coherent version. This shot demonstrates what we are able to do now: 3D rotations and freetype support. What you don't see on the image, is the dramatic speed increase you'll notice when actually running it.

Phew. After some hard fighting with autoconf and make the new build system is in place and the release out the door. It features a total of 8 (eight !) packages. Now we need to document how to use them... Meanwhile, Graydon improved the libArt DrawingKit so it features transformable glyphs.

The website redesign that's been in the works for a while has finally gone live; you're looking at it. Hopefully this rehaul will make the site much easier to navigate while still looking as nice as it did before. Email me if you have any problems, suggestions for usability, pages that should be linked but aren't, want to take my job, etc. I should also take this opportunity to plug Latte, which is the wonderful little text-processing, html-outputting language the new site is written in. You can see the raw sources in the web module's site2 directory in CVS.

Berlin now has its first non-demo application, a Jabber client. It's somewhat proof-of-concept at the moment, but it already supports multiple simultaneous conversations. You can check it out on the screenshots page.

Even though the last weeks have been quiet, lots of things have been going on. We have a completely overhauled kit loading mechanism which allows to select among the implementations of the same interface via attribute lists. The kits in general have been refactored quite a bit. The WidgetKit has become much cleaner in the process. Finally a terminal widget brings us really close to our goals for this second milestone. See it in action here.

Rather unnoticed, release 0.1.4 hit the wire a couple of weeks back. Since then, we have been concentrating on the TextKit and the Viewport, both to get closer to the terminal we are so keen on.

Here is what we have so far: Two new demos, one featuring text input (yes, using Unicode) and the other a viewport which you can manipulate through a panner or two scrollbars. Here is a screenshot.

Stefan and Graydon have been coding like machines. The next release will sport real focus management (which the older incarnations of Berlin hadn't the slightest inkling of), a number of rewired module interfaces, and a great many other features. Graydon has been making the slow shift away from Mesa toward a might lighter backend: vanilla GGI. This will be the greatest optimisation the Berlin display server has ever seen -- although, sadly it probably won't be near finished by 0.1.4 -- try waiting until at least 0.1.6.

In the meantime, Tobias has been making great progress on Berlin's Unicode subsystem, while Nathaniel has contributed a great deal to our development tools (LXR, a postgres version of Bugzilla...). I (Aaron) have been doing little more than site maintenance and a little bit of work on memory management optimisations inside the display server.

Anyway, if I missed anything or anyone, they will be announced with the release of 0.1.4, probably sometime within the next two weeks.

Oh! I forgot to mention... Both mirrors of our site should be fully functional now. If you find any broken links, please please please let me know. I'd like to make the site completely seamless.

The actual release was stalled as we were hoping to get full control of the domain name back. We sort of have it now, but not quite entirely, and we've got sick of waiting. The release is up (and by accident, I revoked the 0.1.2 version so you'll need to get the one labelled 0.1.3). We're keeping most of the administrative utilities on SourceForge now, which is where you'll find current releases.

Stefan and Tobias have been furiously pouring new code into CVS, and now that we've got a stable image out the door, we'll all be putting even more in. Near-term changes include a new DrawingKit (possibly 2), a completely reworked DrawingKit interface, style decorators, Tobias' new Unicode support stuff (in the current release), new IPC code, and much faster drawing and event handling. Plus, we have very snazzy looking demos now -- things which are a real pain to do in X are simple for us (see the new screenshot).

So, we did a presentation at the Alternative: Linux conference in Montreal, and actually had the server in a rather stunning state of good repair by the time our demo actually happened. In addition, we have a new home on a faster, slightly-more-dedicated machine SPI just put online. So now, for instance, people can actually do CVS checkins under their own name (gasp) and we can run a whole pile of dynamic content stuff on the website, which is nice to keep people informed and involved. We'll be following up this glorious new state of affairs with another snapshot of the server as we demo'ed it up at the conference shortly. Just getting things moved at the moment. There will also be some new mailing lists coming online shortly.

0.1.1 hits the wire today. it is a stability and feature addition release (yes, occasionally such things happen), containing all the stuff mentioned below as well as significant speed improvements. it is the sept 18 snapshot, over on our snapshots page. go take a look and test it!

The past month has been the time for polishing things a little and adding features which we were putting off in order to get 0.1.0 out the door. Stefan has been working on decorator controllers, which allow you to place a control facility (such as dragging or clicking) around any graphic on screen; a focus management system for routing keystrokes and mouse events through the tree in a slightly saner manner than before; and a new Desktop kit which plays some of the roles that an X11 window manager plays. I've introduced a self-contained miniature SGML environment into our tree and cleaned up the docbook building process a little. Encouraged by this and by the fact that Norm Walsh has put up stylesheets for OO languages, Aaron has started on perceps templates for churning out an API reference in SGML from the source tree itself. Tobias has been working at adding in a Unicode support layer to Prague, as we found there were license incompatibilities with the recent IBM Unicode kit. On a sadder note, the freetype project has mentioned the possibility of patent problems with the use of truetype rasterizers. Although this is a bit of a downer, it also encouraged me to pursue other fonts in an attempt to get our basic text services alive, and I soon found the GNU Unifont, which is a GPL'ed fixed width bitmap font that covers most of the world's languages. Its storage format is so simple that I couldn't resist, and it solved in a nice unambiguous way the problem of which font(s) to include with the distribution. I took a few evenings aside and wrote some DB-layer storage code and a rasterizer for it, and now we have working a pretty much universal text rendering system. Check this page to see it in action.

A long time coming, we have now reached a formidable milestone with the new server. You can manufacture transformable buttons, attach commands in the client processes to them, click the buttons, and trigger the commands. Take a look on the screenshots page. The programming model is clean and simple, yet typesafe and efficient. We welcome you to download the most recent snapshot (July 22) and try it out. We are calling this release 0.1.0 of the Berlin server, to indicate that it is a total rewrite from 0.0.1. Most of the hard work in this release came from Stefan, who integrated masses of code from Offix and Fresco. If you are familiar with Fresco it should make pretty good sense. In addition, Brent and Stefan's ImageKit it working, and you can now load and display server-side PNG objects. Unfortunately due to obligations at work I've been unable to deliver a working TextKit in this release, but that shouldn't stop you from enjoying the code.

We've pretty much wrapped up this round of feature additions and are cleaning things up in preparation for the first 0.1.0-branch release. This will (hopefully) be the basis of the future Berlin versions, and we will not need to rewrite it anymore times. I think we're all pretty satisfied with the architecture at this point, and it seems to work well (although it's not been optimised at all yet). Stefan has added in a controller interface for distinguishing between objects which want events and those which do not, and I'm polishing off the TextKit so as we can get work underway on a terminal emulator. Also I've been playing with Fnorb and Python, in hopes of assembling a test suite. We have some very slick new logging and debugging classes, and the major reference bugs seems to have been cleared up.

I'm out of school for the summer now, and things are starting to heat up. Stefan and I have been fighting (kindly) over how to do text layout and we've arrived at a (surprise) slight modification of the fresco system which does error compensation both for hinting and for font mismatches between multiple DrawingKits. So WYSIWYG text layout is becoming a little more probable in the printing realm. Stefan has also done a tremendous overhaul of the building process, and the modifications work quite nicely. A number of fatal server crashing bugs have been swept away into oblivion, we've got a reasonable strategy for inheritable styles in the scene graph, and we're having some success with debugging graphics and pick traversals. I patched GGIMesa to fix the depth-ignoring problem, as well. I've put a CVS status page online so you can watch which files are being modified, and I've posted another snapshot of the tree. Clients are also being disconnected from the server properly when they idle and their kits are reclaimed. The mailing list archive has been updated to look much prettier and be more easily navigable, and Brent completed a preliminary PNG image object. Everything's busy! Should be headed into another tag and release shortly.

I rewrote the TextKit (finally) and made an adaptor for GLTT so we could get some cheap and dirty text output. While there are some serious problems with the rasterizer (metrics are being generally ignored, Unicode high-bits are being chopped, it only does TrueType(tm), and the pixel copying loop in GGIMesa fails to take into consideration visual depth so you get some groovy scanline action in anything other than 8bpp) the fact is that the thing works, and I'm pretty damn happy about that. So I took a screenshot and posted it. The design is the way it should be, it's not totally messed up and wrong, and each of the above problems can be dealt with in order.

In further news, Brent has seemingly taken on the task of writing the PNG image object type and the ImageKit (or, well, he was making noises about it). Stefan has gutted the graphicOffset interface and replaced it with structs, saving us several zillion bytes of memory at runtime; he has also imported a system level wrapper library from his OffiX toolkit (code-named "libPrague") to handle process, IPC and file abstractions in the server; he has also written a quadtree for doing positional layout like on a canvas or a window manager; he has also written the text buffer-gap subject. In short, the man is an unstoppable coding machine. All this might make CVS a little unstable, but hopefully it'll balance out shortly.

First off, we got the display server and FigureKit to draw things now. It works on rectangles and paths, and understands color style preferences. So it's starting to limp along. The test client is just so delightfully clean and small, it's worth taking a look -- /test/client.cc. Also, the documentation page and tasklist page of the website have been updated to reflect the current state of affairs and resources to help you contribute to Berlin development. Please check 'em out and comment if you're confused about anything.

More confirmed sightings of compiling and running Berlin servers -- most of our developers can now get it working, including on RH machines. I adapted the event distribution code from the first server and the PickTraversal implemented. Also, I have finished a rough rewrite of the programming section of the Berlin manual, which should serve to explain a little more of how this generation of the server works.

Stefan has spent a huge amount of time porting code from fresco, and the "new drawing model" has expanded to be an almost complete rewrite of the core parts of Berlin (object creation, layout, graphic containment, etc). I spent a long while merging this code with the useful bits in the last version; Aaron and Jordy attacked the build tree with great enthusiasm, Duncan patched omni to remove a number of lingering flaws and Brent has kept us up to date with fresh debian packages. All this has come together and we are now getting results: the first prototype server (0.0.x) is no longer the only working version -- the new server (0.1.x) compiles and boots. Many bugs still to work out, of course, but this is very promising. A lot of inefficiencies and lingering questions about how we were going to accomplish things in the 0.0 branch have vanished. Remote drawing, postscript printing, efficient screen updates, encapsulation of OpenGL, etc. are all nicely dealt with in this version.

Despite all the excitement of having a stable package released (and with omni 2.7 out, it's even a reasonable size now), Berlin 0.0 branch didn't really have a decent layout and drawing model. it redrew too often, lacked structure, and was generally considered a hack. This february I went and visited Stefan in Montreal, and made great progress in understanding (and critiquing) the fresco drawing system, much of which Stefan is presently adapting as a replacement for the next branch. In the mean time not too much has happened. We are all still here but there's been a little slowdown with other responsibilities taking over for a time. Luckily I have also purchased a new CPU and network connection, and gotten new employment, so we can expect a very featureful summer once classes finish. It takes less than 15 minutes to compile Berlin now.

The holiday was quite a productive time. The CVS tree has branched at version 0.0.1, which now has a truly fascinating, working button widget in it, with a test client that repositions the button every time you click on it. That server will be packaged shortly -- the snapshot is available on the snapshot page. The text system has been rewritten after a lot of discussion with out anonymous text advisors, and is much more flexible in the delegation of mapping roles. The documentation is maturing, and a number of fatal and annoying bugs have been killed in the main server.

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!