December 11, 2008 2 Comments
The last couple of days I came around to work a little more on Caciocavallo. I added two notable features:
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.
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.