A GUI for Genode

Norman Feske norman.feske at ...1...
Fri Jan 25 12:13:57 CET 2013

Hi Paul,

I like the idea of the uniform navigation throughout the hierarchy.
Hereby, I'd like to share my thoughts about it.

Why would we limit the hierarchy to four levels? The hierarchy could be
entirely dynamic, depending on what the user is doing, in particular
when moving a bit towards a more data-centric way. Just an example, the
top level could host an item "new web page" among several others. When
clicking on it, a new subsystem is created that will host the website.
When starting up, it presents some bookmarks, possibly the list of
recently visited web pages, and and an URL entry field. Once the user
clicks on one of links or enters the URL, the subsystem will just load
and display the single website. There is no dedicated browser needed.
Because of the uniform navigation that you suggested, any number of web
pages can be open at a time (be repeatedly clicking on "new web page"
without any browser-specific tab navigation. Now, when the website
contains a mailto link, the website subsystem will launch an new
instance of an email subsystem once the user clicks on the link, thereby
adding just another hierarchy level. So things like "email" or "website"
are first-level objects. This email subsystem may, in turn, provide a
button "new attachment". When clicked, a new attachment subsystem will
be created where the user might decide to attach a new image. By doing
so, we just instantiate a new subsystem for creating and manipulating an
image. So the work flow would be completely in line with the hierarchy.
It is quite different from what we have today, but it would be fun to
experiment with this idea.

This scheme could be applied everywhere where we have hierarchies in our
work flow and data, which is, ermm.... almost everywhere. ;-)

I am not sure though, that the hierarchy presented at the GUI level
should one-to-one correspond to the Genode hierarchy. Both are not
necessarily the same thing. But I have to think this more through.

While pondering a bit about the best way to go forward implementing it,
I found a way, which does not look overly complicated and quite doable
given the current state of Genode. There is already the
'Framebuffer::Session' interface, which all graphical applications are
using (directly or indirectly). So this new UI server could provide a
"Framebuffer" service as well as a "Navigation" service. The latter one
would implement the logic behind the visible bands, maintain the current
focus, and notify its clients about the user interactions with the
bands, i.e., "new item" clicked. Each node in the hierarchy would open a
"Navigation" session. When such a session is created, the UI server
receives a label string that tells him, where the session request comes
from (this label already exists in Genode and is used for applying
client-specific policies, e.g. as used by nitpicker). So the UI can
maintain a global view of the nodes in the hierarchy. Because the
"Framebuffer" sessions are created with the same label as the
"Navigation" sessions, the UI can even match those.

Internally, the UI server might use the existing nitpicker GUI server as
compositing engine. So it does not need to implement things like
mouse-cursor handling, alpha blending, etc. This is all already
implemented in nitpicker.

I agree that we also need a notification mechanism. But I think of it as
a feature that is largely decoupled from this UI navigation idea. So
maybe it would be beneficial to focus in the navigation and defer the
discussion of notifications for now.

As a closing remark, I think that there won't be "the" Genode GUI.
Genode is a tool box, which should enable us to build very different
kinds of systems. Your idea is very compelling to me but other people
may have different tastes. So we should try to design the software such
that we get little components that are easily reusable in different
contexts. For example, for doing my daily development work, I need a way
to see multiple terminals at once. So a tiling window manager would be
the way to go (rather than full-screen GUIs as you suggested). It would
be fantastic if our solution would be modular enough so that your
navigation scheme could be combined with my preference of using tiled
windows (or another's preference of using floating windows) in the end.


Dr.-Ing. Norman Feske
Genode Labs

http://www.genode-labs.com · http://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

More information about the users mailing list