Now, I was beginning to think of a general form application. Many application need forms to be filled, and a general application for that seems to make sense. When a button is click, or a text area is changed, the general application could signal it to the application 'model'.

Anyway, that is not what this message is really about. About the GUI, I now realize that what is good for database needs might be good for the GUI.

I did suggest a Up,Down, and Launcher. In database we have the Up,Down,New,Delete. Launcher is New. Delete was missing.

Often, Delete is restricted. New could be.

What's good about the Up,Down,New,Delete, is that it is hierarchical, like the internal structure of Genode.

Highest level is the task: Play, Work, Communicate, Administrate

Second level is the applications category (or application if there is just one) relative to a task: -Play: Strategy Games, Card Games, Arcade games -Work: Office apps -Communicate: Email, InsantMessenger, Web Navigators -Administrate: Desktop, Updates, Backup, etc.

Lower levels: gedit (Up: next document, Down: previous document, New: Open or New?, Delete: current document).

So all that to say that the applications could and probably should use a left band too with up, down, new and delete buttons. And the application area of an application, could very well be an application too.

Should an application area contains it's own notification area for it's chils only? It make some sense.

Scrap almost all.

Let's have 4 levels: Tasks -> Categories of applications -> Applications -> Instances of an application

There is always just one band shown on the left, showing these buttons: Esc) Go to the higher level Up/Down) Navigate between items +/-) Level dependant meaning Ok) Level dependant meaning

Instance of an applicaton Esc) Go to the Application level +) Open a new instance -) Close this instance Ok) Not available Main area is managed by this instance of the application.

Application level Esc) Go to the Categorie level Ok) Go to Instance level of the selected application +) Add an application to the list of this categorie (from?) -) Delete this application from this categorie Main area give the name+description of this application

Categorie level Esc) Go to the Task level Ok) Go to Application level of the selected categorie +) Create a new categorie for this task -) Delete this categorie from this tak Main area give the name+description of this categorie

Task level Esc) Not available Ok) Go to Category level of the selected task +) Create a new category -) Delete current category Main area give the name+description of this task.

Each left band level should have a different color.

I now believe that there should be just one notification area, to the bottom of the screen.

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

I realize I am becoming a bit off topic with this window manager idea. Complain if you think I am too much.

Just adding some late thoughts on this.

First, previous comment was making corners to accept just one application, by the fact that once you added a program in a corner, the opening icon was changed to a closing one. This is really a mistake because one of my main usage pattern expected is to use just center area plus many applications open in one corner, only one being visible at a time. So my first change is to say that the opening icon is always visible in a corner. I wish also to allow opening in the same way many programs at the center (full-screen) area, only the last being visible. That is why I wish to make the opening icon permanent on the floating 'control center'. This allows the usage pattern of just using the center slot, making it similar to one of my previous 'full-page' only one window open at a time.

One of the rational of the design is to make it easy to change how programs are 'tiled' on screen with minimal keybord shortcuts: Ctrl-PageUp to rotate programs counterclockwise (probably 2 to 8) among the visual slots (corners). Ctrl-PageDown to rotate in the other direction: clockwise.

I have seen realized that sometime, the corner will cover a usefull spot of the center (full-screen) program. For this, my first idea, that I am keeping is to have a button on the control center to hide/show all corners. This button would alsow hide/show opening/closing icons too. If floating windows is kept in the design, on other button to hide/show all floating windows (except control center) would be added too.

A fancy design, could allow each corner to hide/show individually. I came with the 5 on a dice toggle buttons for this: O O O O O

Each corner would hide/show the corresponding corner. The center button would hide/show all the corner. There could also be small buttons between the center button and corners buttons, to allows flipping the program in the corner with the one in the center.

Now, an other solution to a corner hiding important window on the center app, is to allow to rotate not only the programs but the corner themselves. I guess I would not only rotate active corners, but all the corners. So now we would add to buttons in the control center: RCL: Rotate Corners Counterclockwise (Left) RCR: Rotate Corners Clockwise (Right)

It has also come to my mind that maybe corners could not be the best place to put my slots. Maybe, Up, Right, Down, Left would have been less used on the center app than it's corners. So at first, I thought about changing the CornerWindowManager to a CrossWindowManager. Actually, I guess it is a question of taste.

So I suggest that: Rotating Clockwise/CounterClockwise corners of a CornerWindow would make it a CrossWindow. Rotating Clockwise/CounterClockwise Up/Right/Down/Left slots of a CrossWindow would make it a CornerWindow.

Basically, the slots would looks like 1 2 3 4 5 6 7 8 9 in the initial position.

Rotating Slots Right (Clockwise) on initial position leads to: 4 1 2 7 5 3 8 9 6

Rotating Slots Left (Counterclockwise) on *initial* position leads to: 2 3 6 1 5 9 4 7 8

It is important to note that each slots is not just one program, but a stack of programs (latest open on the top, which is the visible one). So that when rotating clockwise *Programs*, if you examine one of the slots: -The program on the bottow of the stack goes to top of the 'next' slot -All programs goes down one level in the stack -The top (visible) level of the stack is filled with 'previous' slot

When rotating counterclockwise programs, one one slot: -The top level program is moved to the bottom of an other slot -All programs goes up one level in the stack -The bottom program is filled with an other slot top program

Frankly, I am not too sure how this design would feel. But sure I'd like to be able to test it!