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.
Cheers Norman