|
Deprecated
|
BuiResearch
Migration of Matchbox to BUI
The original Matchbox code is not exactly suited to use as a set top box. The latter has fewer desktop-oriented requirements but for flexibility needs to keep a number of underlying (less-user visible) features. Matchbox is a desktop-style environment for handheld devices. BUI is a pseudo-desktop style environment for set top boxes. BUI is forked from Matchbox 0.9. In order to migrate the Matchbox 0.9 code to BUI-specific code we need to understand how Matchbox works and where and how it needs to change to support BUI requirements. BUI is a simple environment that manages the UI. It requires far fewer features than a typical desktop environment. It's primary purposes are:
The plan here is to strip Matchbox down to core components that BUI requires and then build it back up as needed. The core of Matchbox is the window manager because it will affect all other X clients. Changes to the panel, keyboard and support libraries will be based on how the BUI window manager is implemented. Doing an analysis of the window manager and panel should be sufficient to understand the matchbox library too, and that should be all that's needed to start doing real porting work. Note: in the following discussions "STB" is short for set top box. Table of Contents This page is under heavy development! Take it all with a grain of salt, for now. Window Manager
The BUI window manager requirements are as follows:
Some features in Matchbox whose value in BUI is unclear include:
Existing support in Matchbox for gcov and gprof can probably be left in to continue allowing performance testing of the window manager. The window manager supports a variety of client types (see structs.h:MBClientTypeEnum). A determination must be made if all of these types are meaningful to BUI. Program flow of the Matchbox window manager:
wm_new Allocate wm structure. This is native structure to Matchbox.
Initialize
load config
Get defaults from Xserver
Tell root we're WM
If using gconf, init gconf - probably don't need gconf
If using xsettings, init xsettings - might want to keep xsettings
If not standalone, load a generic application icon - what does this buy us?
If keyboard use enabled, initialize keys (keys_init)
Initilize EWMH
Initialize composite engine
Initialize theme - keep, but simplify.
Set WM properties
If using libsn (startup notification, see cvs.freedesktop.org), init
wm_init_existing ewmh_update_rects
Find area taken up by panels, toolbars: If panel, don't recalculate. In fact, never recalculate.
Adjusts for window decorations. Windows should never be decorated.
Sets adjusted _NET_WORKAREA, _NET_DESKTOP_GEOMETRY
ewmh_update_lists
Do some startup notification stuff (not sure what's happening here yet)
if root has clients:
Sets _NET_CLIENT_LIST_STACKING, _MB_APP_WINDOW_LIST_STACKING properties on all root window clients
Updates _NET_CLIENT_LIST by client age instead of stacking order
else
Sets _NET_CLIENT_LIST_STACKING, _MB_APP_WINDOW_LIST_STACKING and _NET_CLIENT_LIST properties
Sets MB-specific _MB_NUM_MODAL_WINDOWS_PRESENT property
ewmh_update_desktop_hint
Sets _NET_SHOW_DESKTOP property - we won't need this since we have no desktop
Bring existing clients under management
wm_event_loop - main loop event handling Short loop that test for event types and handles them.
I'm wondering if get_xevent_timed() has a single event queued. If so, each handler in the case statement
should probably call continue since no further processing would be meaningful.
Themes
The theme integration in the window manager is fairly extensive. In order to remove the frames from window and to make sure each window has the full screen size we have to understand how themes are implemented or rip themes out completely. Also, there is code for enabling full-screen mode for client windows but I suspect that full-screen implies that the window is always on top, above all other windows. If so, that may make it difficult to have the menu panels slide out over a full screen client. Instead, the client must be given a width/height equivalent to the display/screen width/height but without giving the window the special label of being "full-screen". Themes are implemented either in two ways: normal and standalone. The latter is probably more in line with what we want for BUI. It may be worth the effort to rip out the other option and force standalone usage just to see what that leaves us. More work is needed in this area... Window Manager Files
The WM code uses an object-styled API but it isn't fully fleshed out as an objectified API. While additional work in this area could be done to better make it objectified, there is probably a lot of code that can be removed for BUI which may make the use of an objectified interface moot.
Panel
The panel has a modest amount of session and system tray handling code. These are unnecessary for BUI and can be removed. The panel still needs communications with clients (applets). And it needs to understand how it is being used: panel for menu applet or panel for OSD. The former can only have west/east orientation and be higher in the window stack than anything except the OSD while the latter should have north/south and always be the highest level of the window stack. The code for the menu can be dropped too since BUI panels don't need menus. Messaging needs to be kept but further analysis is required to understand what messages are being sent and whether they are still needed. Program flow
main panel_init: setup panel structure
Establish system tray, if one doesn't already exist
Tell other clients we have the tray (if we do)
panel_orientation_set_hint - set our orientation?
Create the panel window
Initialize the client session
Run the panel main loop
panel_init Uses non-Xrm command line parsing - switch to Xrm?
Does initial juggling of height/width based on orientation.
panel_main Has code for ConfigureNotify that handles rotation of a device.
This isn't necessary for the STB. Removing this removes a big
chunk of this function.
Panel Files
|