Caciocavallo Architecture Overview

I’m not a big fan of UML diagrams, but in this case I think it really helps to explain how Cacio works (and to recognize its beauty 😉 ).

Caciocavallo Architecture Overview

Let me go from top to bottom and explain the parts that make up Caciocavallo:

  • Swing: Everybody knows it. It is a universe of its own. Basically, it builds on AWT, is implemented in 100% Java, only uses so-called lightweight (non-native) components, has a lot of Look & Feel fluff, etc.
  • AWT: Slightly less known than Swing, this dinosaur is the foundation of Swing. It provides another, so-called heavyweight set of widgets, that are usually implemented by the corresponding platform widgets, as well as the toplevel containers (windows, dialogs, frames). It’s still 100% Java, but talks to AWT peers…
  • AWT peers: a set of interfaces that are used by AWT for the platform dependent parts. AWT doesn’t care who it talks to, as long as it provides the implementations for all the widgets in AWT. OpenJDK has two implementations of the peers, one for Win32, one for X11. If you happen to have a system that has all the required widgets and stuff available, this is the place to plug in. Caciocavallo is yet another one that helps for the cases where you don’t have native widgets.
  • The Cacio peers is another set of peers for AWT. It implements all the widgets by using Swing for drawing and logic. The idea is that each AWT widget should live in its own window. This means we have the obvious toplevel windows plus nested windows for all the components and containers. This makes sure that the widgets behave as they should – heavyweight. However, this windowing behaviour is not implemented in the peers directly, but instead hides behind the PlatformWindow interface.
  • PlatformWindow is an interface that provides all the windowing behaviour that we need for the AWT widgets and toplevels. It looks very similar to ComponentPeer aggregated with WindowPeer, but there are also some differences. The PlatformWindow implementation to be used for a widget is created by a PlatformWindowFactory that lives in the CacioToolkit. If you have a system that has no widgets, but supports (nestable) windows, you implement PlatformWindow and get all the AWT widgets for free.
  • ManagedWindow is an implementation of PlatformWindow for the case where you don’t have any native support for windows, for example a plain framebuffer. It implements all the necessary windowing behaviour, including nested and overlapping windows in Java, and builds only on another interface ManagedWindowContainer. Interestingly, it implements this same interface itself. This makes sense so that windows can be nested. ManagedWindows can also be useful on systems where you have support for toplevel windows, but not for nested windows. All you need to do is to implement the ManagedWindowContainer for the topmost container (e.g. the screen or the native toplevel windows).
  • ManagedWindowContainer is a really small interface, it only has a handful of methods, the most important beeing getGraphics(). If you implement this correctly (e.g. the example PlatformScreen class in the diagram), you can serve everything that builds on it – you get windows, you get heavyweight widgets, and of course all the heavyweight and lightweight AWT/Swing stuff.

To summarize, there are 3 points to plug in potential implementations: at the peer level for systems with full widget sets, on the PlatformWindow level for systems w/o widgets but with windows or on the ManagedWindowContainer level for bare bones systems w/o anything. It’s also possible to start a full implementation on ManagedWindowContainer and then work the way up, because the interfaces are similar and higher-level interfaces are more or less supersets of the lower-level interfaces (it should be possible to transform a ManagedWindowContainer into a PlatformWindow, and to transform a PlatformWindow into a ComponentPeer and WindowPeer, etc). To give you a feel of the size: ManagedWindowContainer has ~4 methods, PlatformWindow ~20 methods, the whole set of peer interfaces ~100 methods.

Of course, this overview leaves out a lot of details, but in general it’s that easy. The implementation is not complete though: the peers don’t support all the widgets yet, the managed window doesn’t support every feature yet (i.e. restacking), but the general architecture is in place now, and it will most likely only change in the details.

Advertisements

Caciocavallo Managed Windows

Yesterday evening I got the managed windows in Caciocavallo to the point where they draw correctly even in the case of obscuring overlapping windows. This is pretty neat:

Caciocavallo Managed Windows

You see the dialog in the middle is a heavyweight window that overlaps the main window beneath, which shows an animation. This behaviour is very important for supporting toplevel windows as well as AWT heavyweight widgets.

Implementing AWT on a fullscreen system using Caciocavallo is now as easy as implementing a Java2D pipeline for that screen, and let Cacio do all the funny stuff like handling windows, implement the widget peers, etc. And implementing the pipeline in the easiest (unoptimized) case also boils down to implementing SurfaceData for the system, which is one day of work or so. Rapid prototyping, yay!

Caciocavallo updates

The last couple of days I came around to work a little more on Caciocavallo. I added two notable features:

Event Handling

Event handling is now done in Caciocavallo. We now have a generic event pump that pulls event data out of a CacioEventSource implementation. EventSource is an interface that has to be provided by the target implementation and delivers event data. This data is then processed, possibly transforming some things, and eventually an AWT event is generated of it and posted to the AWT event queue. On the target implementation, only the CacioEventSource has to be implemented, which usually simply polls the native event queue and fills in the event data.

Managed Windows

Cacio will support ‘managed windows’ soon, only needs some cleanup before committing. A little background is probably in place: the idea in Cacio is that all the AWT widgets live in their own heavyweight window. Those windows are nested and laid out according to the structure and layout of the heavyweight AWT widgets. The peers implement the painting and logic by using Swing, and delegate the windowing stuff to an interface called PlatformWindow. A target implementation basically only needs to implement the PlatformWindow interface and gets all the AWT widgets for free.

But what if your target system doesn’t support any windows? Think of a plain framebuffer as example? In this case you need to implement the windowing logic yourself. In order to help making this easier, I added a generic ‘window manager’ (it’s not like the X11 window managers, more like what X Windows itself does: handle rectangular, possibly nested areas on the screen). This implements the PlatformWindow interface and only needs an implementation of an even simpler interface (called ManagedWindowContainer) as the backend.

This also will do alot of work for events: the target implementation only needs to provide mouse and keyboard events, and the window manager will generate focus, window and component events for you.

With this window manager in place it will be possible to support all kinds of setups I can think of: 1. A fullscreen target with no window support at all. The window manager then manages all the toplevel AND nested windows. 2. Basic toplevel window support on the target. Let your target handle the toplevel window and use the window manager to handle the nested windows. 3. Full window support on the target (think X11). You don’t need the window manager then and implement PlatformWindow directly.

Financial crisis solutions

So. In order to solve the financial crisis, german politicians are now considering to give out coupons to increase customer demand. How stupid is that? Sounds like a nice wait to create a (even more serious) financial crisis to me. Oh wait… 🙂

I suppose I should become politician, I’m sure I can think out even more stupid ideas. For example this: We cut the politicians all their salary to, say, what they think should be enough for unemployed persons, that is around 400€ or less. (This should not even hurt the politicians, since they get paid their flights, meals, houses, etc anyway…). Then give this money out to those who really need it for living and for paying their loans. Also, throw away all their bank-rescue-plans. I mean, in good times all the finance people and banks are crying for less state control and more capitalism. Now they want more state control and more socialism? WTF? Let the ill-managed banks go down, give the rescue money to their customers (who don’t deserve to go down with their banks usually), and let the healthy banks (yeah, there are a few…) survive. Evolution should do the rest.

Stupid system that discourages intelligent ideas and encourages greediness in politics. No wonder we have a financial crisis now…