Ideas about interactive GUI

[Norman Feske]

Hi Boris,

>> The answer may depend on the complexity of the subsystem manager, which
>> is obviously critical. Does the separation of the menu from the
>> subsystem manager contribute to significantly lower the TCB of the
>> subsystem manager?
> 
> It does not necessarily change the TCB, but it is done for the sake of
> reusability and code readability/ease of programming. From that
> perspective we think it would be nice if these things were separated,
> and for instance the menu part could be used in another application as well.

Please don't get me wrong. I do not oppose your idea. In contrary, I am
all for the creation of re-usable components! It is just that I feel
unable to fully grasp the requirements on a generic menu component. I
encourage you to pursue your approach and let us see where it takes us.

Also, however the menu will emerge, by using (and possibly improving)
the menu_view as the basis for its presentation, we will both walk on
the same ground. :-)

>> This leaves the question about the input focus. When using the wm, the
>> focus is already defined by the window layouter via the 'focus' ROM. The
>> window layouter, in turn, already consumes a 'focus_request' ROM to
>> respond to externally triggered focus changes. This would be the right
>> hook for the menu / subsystem manager.
> 
> I've been looking into this mechanism, but so far it's not entirely
> clear to me. Do you mean that the subsystem manager could write to this
> focus_request report and the layouter would for example show/hide the
> appropriate windows automatically? If so, what about the focus_requests
> that come from the window manager?
> In short: how would that work?

It does not work out of the box but I think that a minor extension of
the window layouter will do the trick.

First, the 'focus_request' ROM is merely a vehicle to bridge the gap
between nitpicker's session_control interface and the aspired
report-ROM-based focus management. In the longer term I would like to
manage the nitpicker focus solely by the report-ROM mechanism. But this
is not easy because nitpicker changes the focus autonomously whenever
the user clicks on an unfocused view. So in order to streamline the
focus handling, we need to possibly redefine the role of nitpicker as
the sole arbitrator of the focus. Frankly speaking, there are still
loose ends. I hope to have the design clarified in summer when I will be
able to turn my attention to the tiled window manager.

Until then, I recommend you to follow the pattern of the 'focus_request'
in the window layouter. The most pragmatic way would be to add another
'external_focus_request' ROM and let the layouter respond to both.

The story about the hidden applications is similar. You will need to
extend the window layouter to request a 'hidden' ROM, which tells the
layouter which windows to suppress. The menu (or subsystem manager?)
would solely generate / update the 'hidden' reports.

Do you think this approach is viable for your line of work?

Cheers
Norman

-- 
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