Understanding Fresco

Fresco is a consistent, configurable, stand alone, modular, and device independent user interface system, formerly known as Berlin. Fresco is based on the concept of a server side scene graph. It uses CORBA, which results in the whole system being network- and language transparent. To access input and output devices low-level graphic libraries are used: We are not implementing any device drivers ourselves.

These were lots of buzzwords: What is all this supposed to mean?

• consistent: All applications running on one server for one user will always have the same look and feel.
• configurable: The consistent look and feel can be set by the user. How do we do this? Basically by moving the Toolkit and windowmanager we all know from X into the server.
• stand alone: Fresco does neither need X nor any other windowing environment to run. It can run in an X window, but it runs on the framebuffer as well. In fact we hope to be able to replace X some day.
• modular: The server itself is tiny, loading modules (Kits) as the clients need them. All Kits can be exchanged at runtime.
• device independent: A client does not know where its window is on the screen. In fact it does not even know whether it is rendered on a screen, printed or running in a 3D walk-in environment. To make this possible all measurements are given in real-world sizes, colours are given in a normalised form. This device independent format is turned into some form the hardware can process as late as possible. This allows to switch output forms from OpenGL to Postscript, rerender parts of the screen using Postscript to get a print out, and then switch back to OpenGL to continue displaying your data.
• server side scene graph: All the graphics (everything on screen) is usually stored in the server. That way there is hardly any communication necessary if you run your applications remotely: All the informations the server needs to rerender the scene is already there.
• network transparent: You can have your applications connect to the Fresco server over the network. In fact you can even distribute your application over the network on a per object basis.
• language transparent: You can use any language with CORBA bindings for your application.
• device drivers: We don't write them. In our opinion drivers belong close to the kernel into low level libraries, not into a windowing system.

Before you ask: We absolutely depend on CORBA. There is no way around it, there is just nothing else powerful enough. The whole architecture depends on objects communication in a location transparent manner. Since we use everything CORBA offers, we do not consider it bloated: Things you use can't be bloat.