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.
--
Met vriendelijke groet / kind regards,
Boris Mulder
Cyber Security Labs B.V. | Gooimeer 6-31 | 1411 DD Naarden | The Netherlands
+31 35 631 3253 (office)
<!--
A simple menu that has three entries.
The first entry contains the text 'foo', and if you hover over it it displays "This is foo!" to the right.
The second entry shows the icon bar.png. If you hover over that picture, it will expand a submenu that fades if you no longer hover over it. That submenu again contains two entries, that generate reports if you click it. For instance, when you left click on the text "one", it will generate the following xml report:
<report id="bar -> one">
1
</report>
This report will then be sent to some other server through a Report session. The bar_2 report will specifically be done through a report session with the "bar_2" label. This way, policies can decide which reports are sent where and not all components need to be aware of all events happening in the menu.
The third entry contains a rom node that acts as a placeholder. A ROM connection with the corresponding label will be opened and the <rom> node will be replaced with the content of that ROM. Some other component is able to specify the structure of that submenu this way.
-->
<menu>
<element id="foo" label="Foo">
<action event="hovered">
<hint text="you just clicked foo!"/>
</action>
</element>
<element id="bar" label="bar" icon="bar.png">
<action event="hover">
<menu fading="yes">
<element id="one" label="One">
<action event="left_click">
<report> 1 </report>
</action>
<action event="right_click">
<report> -1 </report>
</action>
</element>
<element id="two" label="Two">
<action event="left_click">
<report label="bar_2"> 2 </report>
</action>
</element>
<!-- we can put more entries here, including even more nested menus -->
</menu>
</action>
</element>
<element id="baz" label="Baz">
<rom label="abc"/>
</element>
<rom label="def"/>
</menu>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
genode-main mailing list
genode-main@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main
