Feature #7
open
Need a scrolling menu applet for the panel
Added by Hammel over 14 years ago.
Updated over 12 years ago.
Description
The UI needs a scrolling menu. The menu is implemented as a panel applet.
The menu holds icons that can be scrolled up and down using arrow keys on the keyboard. Icons are uniformly sized and an active icon is highlighted in the menu. As the menu scrolls up and down, the position of the highlighted icon remains the same, but the icon content changes. When ENTER is hit the highlighted icon's associated application or URL should be brought up and displayed full screen behind the menu.
Turns out that AIGLX and Mesa/OpenGL are not required for XComposite. It's much simpler than that. However, QEMU uses a Cirrus chipset for video so the proper drivers had to be enabled in kernel and rootfs to get the Composite extension recognized by X at startup.
These fixes are in the build now and xdpyinfo shows that the Composite extension is enabled.
Next up: place the panel on the left edge of the screen instead of at the bottom. When it slides in (unhide) make it overlap the windows and not resize them.
Then: get it to be semi-transparent.
Finally: Add a menu applet that scrolls icons across the panel (which ends up being vertically). Applet should consume entire width of the panel.
Buildroot uses the 0.9 release of Matchbox (as does OpenEmbedded). The latest release of the desktop and panel are 2.0. I ported these into buildroot and tested but the panel was missing. Matchbox doesn't appear to be actively developed and testing the 0.9.3 panel showed that the orientation setting actually worked. So its not clear if continued work should be with the 0.9 release or the 2.0 release. Forking might be a possibility though only if active development has ceased on the mainline.
At this point I think sticking with the 0.9 releases makes sense until I hear from the Matchbox developers.
BUI has been launched as a separate module in the CVS tree. This will become the BeagleBox UI based on a fork of Matchbox 0.9.
MB's window manager is already a compositing window manager (you can't run it with xcompmgr, for example - only one at at time is allowed). In order to test transparency modifications to the panel we have to modify the window manager to make all apps full screen, irrespective of the panel. So we need to understand how the panel and window manager are interacting. It would also help that the wm provide a default, no-solid colored background that can be seen via a composited panel.
A full review of both the window manager and panel should be done and an flow chart made of how they act. These have more code in them than I first thought. Reviewing them may take a couple weeks (since its not my primary job, of course).
Once we have that we can make a plan for the changes required in both.
Updated this task to reflect tracking specific work on the scrolling menu applet for the panel.
Also available in: Atom
PDF
Updated by