These shots are actually from a few months ago, when I first got this working, but I forgot about them until now.

What you see is XGGI running inside a Fresco window. In the first one, I'm reading the Fresco homepage in Mozilla; in the second, I'm chatting on #fresco in xchat. There are still bugs with the input (which will have to wait until we rewrite some bits of our input system to be fixed), but it is at least minimally possible to use. It would be nice in the long run to get X compatibility by, say, porting Qt or GTK+ to work on Fresco, but that's probably quite difficult (because of assumptions they make); in the shorter term, this form of compatibility works now.

(Some of you may recall seeing something like this from way long ago; that version could display X apps, but you couldn't interact with them at all. Now we can properly handle the mouse, and some keyboard events; enough to do what you see here.)

This shot shows Fresco on the Sharp Zaurus. The whole deskop is rotated by 90 degree and scaled down to 80% of the original size. I forgot to turn of the mouse pointer which still shows the physikal orientation of the screen.

Do not try this at home: This setup eats up the memory of your Zaurus and it is so slow that you can hardly call it interactive. This is because of Fresco's extensive use of floating point values. The StrongARM CPU used in the Zaurus has no floating point unit and needs to emulate floating point instructions with integer arithmetic.

Fresco gets a background image, and some improvements to its look

Guess what you are seeing here: it's a screenshot taken of ghostscript showing an eps file. Yes, that's right. We can print now.

I used Chalky's python code for prototyping this new 3D stuff. Did I tell you how easy it is to play with Berlin using the python runtime ? After determining all the relevant functionality, I recoded the stuff in C++, stuffed it into the PrimitiveKit, and here you are...

The client-side tree view widget in some demo clients -- a mail/news reader (not yet fully functional) using the Mozilla Mailnews backend, a minimal XHTML browser, and a simple XML viewer (latter screenshot edited for conciseness).

The "?" means that it is not yet determined, if this node has childs.

Berlin even uses CORBA inside the display server itself, although in-process objects are accessed almost as quickly as normal objects with virtual methods. This means that objects such as Graphics can be implemented out-of-process, like this Clock which is written entirely in Python by implementing the Graphic interface. This proof-of-concept leads to exciting opportunities such as RAD of Berlin interfaces in Python, which can then be ported to C++ with no changes in application code at all! Of course you can use any language that has a CORBA ORB.

The Unidraw port is slowly coming together. Here is an editor with three tools and a Viewer displaying the current scene. The nice thing is that all the domain specific stuff such as the tools as well as the graphical objects are implemented in the client.

A major architectural part of InterViews is the Unidraw library, a framework for domain specific graphical editors. While we try to reproduce ('port') that in the context of Berlin, we'll write more and more elaborate drawing editors. Here is our first try.

What you see here is a GGI application mapped (via shm) into the screen. It's still pretty rough, but a good starting point for drawing intensive drawing and a backward compatibility kit (X and low level toolkit emulators)...

A couple of demo windows mapped and zoomed and rotated in 3D. This shot features freetype rendered text. Not fully optimised yet but pretty nice already. What the shot doesn't tell us is how much it has become faster since the last post. Try it out to believe it...

Another nice snapshot of the terminal running, under a DrawingKit backed by Raph Levien's LibArt. Now we have text inserting in the right manner, and linear transformations apply to text as well; so here we have a rotated and scaled terminal widget, rendering the still somewhat chunky GNU unifont, a GPL'ed Unicode bitmap font we include in the distribution.

Berlin has its first application! Here's an initial screenshot of a Jabber client for Berlin, which is already functional enough to allow multiple simultaneous conversations. The whole thing is less than 200 lines of perl code. Now to add roster support...

We finally have a terminal widget! It's still buggy but the mere fact that it does interact with the user is so exciting that i decided to post it. And besides, this terminal is really translucent ;)

MVC is a really powerful paradigm. It let's you fully control how you manipulate your data. Here is a shot of an image, clipped inside a Viewport. It exposes two BoundedRange models, which I have attached three widgets to, a panner, controlling both simultaneously, and two scrollbars, each controlling one axis...

Most windowing systems have their basic interface written in one certain language like C (a la Xlib), and if you want to write programs in another language you either need to reimplement that interface in your language, or put together a complicated wrapper library. Berlin's basic interfaces are written in IDL, and so allow any language with a CORBA library to talk to it directly. This is a screen shot of a perl program using Berlin, through the COPE perl CORBA library. Rather than spending months writing and debugging a Berlin library for perl, getting this little demo working took about 2 days, most of which were spent fighting with bugs in the pre-alpha COPE.

This is a shot of the new 'focus' demo, which will eventually serve as a demonstration of the new non-positional event/focus architecture by allowing you to navigate among the buttons with the keyboard (the lack of support for keyboard focus is the primary thing preventing the creation of a terminal emulator for Berlin). However, for now, you can see the texture support in the new DrawingKit. Also note the old 'demo' test application running at the same time, and the alpha blending taking place between the two separate applications.

This pretty shot shows Berlin's demo application with most of its windows up. As you can see, we have multilingual transparent text working, buttons, radio groups, as well as arbitrary linear transformations (the rotated buttons), PNG images, window stacking, etc.

Here's a fresh screen capture from the upcoming point release (0.1.1) which should be hitting the streets later on this month. The major new features in this release are the addition of a focus management system, controllers (such as dragging decorators, from which we build windows) and a usable, though still somewhat underpowered text system. In this shot we have a beveled title bar on a draggable window, with the words "Hungarian", "Russian", "Greek", "Japanese", "Chinese", and "Korean" written in their respective languages in a black box within the window.

Here are some screen captures from the most recent release (0.1.0) which we just published. You can see 3 important new capabilities here:

• Buttons with bevelled decorator frames (not visually stunning, mind you)
• PNG images stored within the display server
• Arbitrary linear transformations

Having totally rewritten the display server, we are now at a point where we can show how drawing is supposed to work, rather than just having what we had before, which was essentially a policy of loading a widget and letting it take over the openGL library and do whatever it wants in order to draw itself. The new approach, with a replaceable DrawingKit wrapped inside a standard interface, is much better suited to the long term goals, which require drawing on non-openGL devices such as PDAs and printers. Here's a screenshot + magnification from the current server running with an openGL DrawingKit.

As you can see, the text is both colored, semi-transparent, and anti-aliased. The geometric primitives are not done with any sort of weird hacks to simulate geometry with tiled windows -- you just feed it a vertex path and it builds a geometric figure. Same as with text: the entire text renderer is a replaceable server-side component. Right now we're using one which is just a couple small adaptor classes wrapped around Stephane Rehel's GLTT library for copying Truetype glyphs from the Freetype library to an openGL color buffer. The API is quite simple: to insert the text you see here, the following calls are made: