That focus_request sounds useful indeed. We are looking into it!
For now we are starting experiments with a component that uses init as a way to start subsystems.
Perhaps it is easier to have the menu and subsystem state management combined for now, and use qt5 for bigger applications that require more flexibility.
We will try to separate these two in code a bit instead of splitting it into two components.
Boris
On 19-04-17 14:57, Norman Feske wrote:
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