Dear Genode Community,
We have been brewing on the best way to implement an interactive menu interface. We would like to hear your opinions and ideas on this. Currently, only launcher provides this functionality. However, we had the following objectives in mind:
- Decouple the menu state and the functionality. We think the menu should only be responsible for rendering the dialogs and registering input events. Whatever functionality is to be invoked based on this input should be delegated to other components.
- Have a fully customizable menu. The model of what buttons and (nested) submenus exist should be configurable, and should be separated from the layout (such as how a button looks like) and from the current state (which menus are collapsed, etc).
In order to shape this, we have the following ideas:
- The configuration of the menu model can be specified in XML in its config, and be reconfigurable at runtime. Parts of this could be defined by other components as well. Examples of how this could look like is described in the attached xml file.
- Events related to the menu either trigger menu actions (in which case the config dictates the proper response, such as showing or hiding a submenu) or trigger external actions. In the second case, the menu generates a report that for instance states a certain button has been clicked. Again, see the attachment.
- Any (custom) component can read these reports and take certain actions. For example, in case programs are to be started with the menu, we can add an init component that takes its config from another rom module. A subsystem management component containing a more extensive state model would read the events from the menu, change init's config based on this, and monitor the state of started subsystems and perhaps add extra context menus for these subsystems. Another example is a shutdown button that talks to a component that can write the system state, and which could show a dialog with the options to power off or reset a systems. Perhaps it can try to gracefully stop running programs with disk state (such as virtualbox) by talking with the subsystem manager as explained above. In any case, the menu should be able to support any functionality by providing a generic interface to components such as the examples above.
- The layout of the menu can be specified in the config as well, perhaps using (a subset of) CSS, or as it is now, with the styles database that contains pictures for each element. (buttons, bars, etc.)
While looking at ways to implement this, we also encountered the following problems:
-As it is currently with launcher, a lot of subsystem functionality is intertwined with the interactive menu. This makes implementing such a modification a bit more difficult than replacing the subsystem management part with a reporting part. One of the issues we face is that showing and hiding windows of other components is done through the session_control function in the nitpicker session interface, but this is limited to the session of the components and its children. Children of an init component therefore cannot be affected.
One way to fix this is to add a policy in the window manager or nitpicker that allows the menu or some other component to execute session_control on certain or all sessions. Implementing session_control functionality in init itself does not look like a clean solution.
Another issue is that init does not keep track of exited children. Launcher neatly closes the corresponding menu entries by installing a signal when the child exits, but init does not have such functionality now. Perhaps init could be modified such that it generates a report when a child exits? For now, if we would quit a child with another method than through the menu, we have no way of knowing if a child exited.
I'd very much like to hear your comments on these ideas and on the best way to realize it (perhaps together), and for instance how you think we could resolve the above issues.