Hi,
Good to hear that you are also going to do this! For us, there is a clear need for a GUI system that is both dynamic and simple in use.
This is actually very similar to what the existing menu_view already gives you.
This configurablility would indeed be similar to menu_view. Another main difference is that it does not aim to replace menu_view, but is an overlapping component that could also handle input, and take actions, such as collapsing and expanding submenus. It could still use menu_view, fading_dialog and such parts. So instead it aims to replace the menu part of launcher, except that it is dynamic and generic. What we would like is such a menu component that could be used at many places; not only for a desktop environment, but also inside any application, or settings menu, or subsystem.
It would be complete with elements such as buttons, submenus and dialogs, and the notion of clicking on these elements. These events could somehow be communicated to other elements such that the corresponding actions are taken.
I'd advise not to use the report/ROM interface to propagate events, but only state. Even though one (myself included) is sometimes intuitively tempted to mix up events and states, it calls for trouble. [...]
Makes sense, you are right. However, for clicking buttons in this context, it makes sense to communicate events instead of states. Perhaps using another way than reports could be useful here, such as some list of events like in Input, or a packet-stream like functionality.
This raises the question of where does the responsibility of the menu end, and where do the responsibilities of the subsystem manager start? If we need a subsystem manager anyway, couldn't it use the menu_view(s) directly to implement menus?
We would like to separate the menu with all its buttons from the subsystem state logic.
Whenever we want an application that uses the GUI that does different things, we would have to import the menu management code into these applications. This could be done as a library with functions for creating buttons and menus, or as a separate component that can be configured and uses some IPC mechanism. In the latter case, more than one component can talk with the same menu, depending on the application programmer's needs. This can be made as complex or simple as is desirable. However now it is already quite complicated to create only a basic menu as all the features are very intertwined, which makes the code a bit hard to read and modify.
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.
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?
The state report generated by init already contains a 'state' attribute for each child. Right now, the attribute is present only if the child is "incomplete". We could add a value "exited" that would be presented as soon as the child issued a 'Parent::exit' call. Also the exit code could be added to the report, if needed. The subsystem manager could then inspect the state reports for children with this attribute value and remove them from the init config.
This is exactly what I'm looking for in that case.
Thanks,
Given that we have qt5 ported, my plans with implementing GUIs have generally involved using a qt-based component as the frontend, and using report_ROM or a custom RPC interface to communicate with the backend. Is there anything wrong with this approach? I get that it's not enough when untrusted data (e.g. icons) needs to be displayed, but shouldn't this work for most situations, provided untrusted data is processed by other components?
On Apr 18, 2017 7:24 AM, "Boris Mulder" <boris.mulder@...434...> wrote:
Hi,
Good to hear that you are also going to do this! For us, there is a clear need for a GUI system that is both dynamic and simple in use.
This is actually very similar to what the existing menu_view already gives you.
This configurablility would indeed be similar to menu_view. Another main difference is that it does not aim to replace menu_view, but is an overlapping component that could also handle input, and take actions, such as collapsing and expanding submenus. It could still use menu_view, fading_dialog and such parts. So instead it aims to replace the menu part of launcher, except that it is dynamic and generic. What we would like is such a menu component that could be used at many places; not only for a desktop environment, but also inside any application, or settings menu, or subsystem.
It would be complete with elements such as buttons, submenus and dialogs, and the notion of clicking on these elements. These events could somehow be communicated to other elements such that the corresponding actions are taken.
I'd advise not to use the report/ROM interface to propagate events, but only state. Even though one (myself included) is sometimes intuitively tempted to mix up events and states, it calls for trouble. [...]
Makes sense, you are right. However, for clicking buttons in this context, it makes sense to communicate events instead of states. Perhaps using another way than reports could be useful here, such as some list of events like in Input, or a packet-stream like functionality.
This raises the question of where does the responsibility of the menu end, and where do the responsibilities of the subsystem manager start? If we need a subsystem manager anyway, couldn't it use the menu_view(s) directly to implement menus?
We would like to separate the menu with all its buttons from the subsystem state logic.
Whenever we want an application that uses the GUI that does different things, we would have to import the menu management code into these applications. This could be done as a library with functions for creating buttons and menus, or as a separate component that can be configured and uses some IPC mechanism. In the latter case, more than one component can talk with the same menu, depending on the application programmer's needs. This can be made as complex or simple as is desirable. However now it is already quite complicated to create only a basic menu as all the features are very intertwined, which makes the code a bit hard to read and modify.
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.
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?
The state report generated by init already contains a 'state' attribute for each child. Right now, the attribute is present only if the child is "incomplete". We could add a value "exited" that would be presented as soon as the child issued a 'Parent::exit' call. Also the exit code could be added to the report, if needed. The subsystem manager could then inspect the state reports for children with this attribute value and remove them from the init config.
This is exactly what I'm looking for in that case.
Thanks,
--
Met vriendelijke groet / kind regards,
Boris Mulder
Cyber Security Labs B.V. | Gooimeer 6-31 | 1411 DD Naarden | The Netherlands+31 35 631 3253 <+31%2035%20631%203253> (office)
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
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
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
-
Boris Mulder -
Nobody III -
Norman Feske