Genode's window manager is very simple and lacks the following functionality: minimize/maximize/restore close window force kill
It seems like the nitpicker service should be modified to support whichever of these functions it doesn't already. I'm unsure of how exactly force kill could be implemented--especially since not all users can be considered trustworthy. How do we fit users into the Genode security model? Users need to be given reasonable authority--complete authority in some cases. Any ideas?
Hi Ben,
On 05/09/2015 05:53 AM, Nobody III wrote:
Genode's window manager is very simple and lacks the following functionality: minimize/maximize/restore close window force kill
are you referring to the window management of the default demo scenario or the window manager that is hosted in repos/gems? In the latter case, adding minimize/maximize/restore/close would not require any change of the nitpicker interface. Instead, these functions could be implemented in the so-called "layouter", which is a separate component. You can find more information about the architecture here:
http://genode.org/documentation/release-notes/14.08#New_GUI_architecture
It seems like the nitpicker service should be modified to support whichever of these functions it doesn't already. I'm unsure of how exactly force kill could be implemented--especially since not all users can be considered trustworthy. How do we fit users into the Genode security model? Users need to be given reasonable authority--complete authority in some cases. Any ideas?
Nitpicker is equipped with an emergency feature called "kill mode". It can be activated by the user by pressing a configurable key. In the default demo scenario, this key is F11. When activated, nitpicker tints the screen in red color, marks all screen regions with the labels of the corresponding clients, and allows the user to pick a view to remove. Nitpicker will then lock out the selected client from the user interface. Technically, it is not killing the program but merely suppressing its output.
In practice, the kill mode is not that important, especially since we introduced layered domains to nitpicker in the release 14.08 (see the link above). Using layers, a trusted application such as a panel can be guaranteed to always appear in front of all others. This application would be a natural place to implement application-management functionality. The launcher as featured in the gems repository is a representative of such an application. You may give it a try with the repos/gems/run/launcher.run script. After starting a subsystem, you can press the corresponding button again, but a bit longer. This activates a context menu, where you can kill or hide the subsystem.
Cheers Norman
Thanks for getting me to reread the New GUI Architecture page. It answers some of my questions, but not all of them. For adding minimize/maximize/restore/close buttons to the window decorations, how do we handle the decorator not recieving input? Should it send rectangles to indicate where the buttons are, and be sent signals from the layouter when the mouse is over/clicking on one of them? Also, what is the best way to implement focus on click? People won't want to have to click on the window decorations or the panel every time they want to switch windows. It seems like the destop and panel should be at least partially combined. I understand that there could be security issues with this. I have been thinking about how to allow users to have user-specific applications appear on the desktop and menu. What seems the most logical (secure yet user-friendly) is to use different text colors for system-wide and user-specific applications. Do you have any ideas on this? I could see the panel/desktop becoming overly complex.
On Sun, May 10, 2015 at 5:15 PM, Norman Feske <norman.feske@...1...> wrote:
Hi Ben,
On 05/09/2015 05:53 AM, Nobody III wrote:
Genode's window manager is very simple and lacks the following functionality: minimize/maximize/restore close window force kill
are you referring to the window management of the default demo scenario or the window manager that is hosted in repos/gems? In the latter case, adding minimize/maximize/restore/close would not require any change of the nitpicker interface. Instead, these functions could be implemented in the so-called "layouter", which is a separate component. You can find more information about the architecture here:
http://genode.org/documentation/release-notes/14.08#New_GUI_architecture
It seems like the nitpicker service should be modified to support whichever of these functions it doesn't already. I'm unsure of how exactly force kill could be implemented--especially since not all users can be considered trustworthy. How do we fit users into the Genode security model? Users need to be given reasonable authority--complete authority in some cases. Any ideas?
Nitpicker is equipped with an emergency feature called "kill mode". It can be activated by the user by pressing a configurable key. In the default demo scenario, this key is F11. When activated, nitpicker tints the screen in red color, marks all screen regions with the labels of the corresponding clients, and allows the user to pick a view to remove. Nitpicker will then lock out the selected client from the user interface. Technically, it is not killing the program but merely suppressing its output.
In practice, the kill mode is not that important, especially since we introduced layered domains to nitpicker in the release 14.08 (see the link above). Using layers, a trusted application such as a panel can be guaranteed to always appear in front of all others. This application would be a natural place to implement application-management functionality. The launcher as featured in the gems repository is a representative of such an application. You may give it a try with the repos/gems/run/launcher.run script. After starting a subsystem, you can press the corresponding button again, but a bit longer. This activates a context menu, where you can kill or hide the subsystem.
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
One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi Ben,
On 05/10/2015 10:50 PM, Nobody III wrote:
Thanks for getting me to reread the New GUI Architecture page. It answers some of my questions, but not all of them. For adding minimize/maximize/restore/close buttons to the window decorations, how do we handle the decorator not recieving input? Should it send rectangles to indicate where the buttons are, and be sent signals from the layouter when the mouse is over/clicking on one of them?
it should work like this:
1. The layouter produces a report for the window layout. Each window that is to be equipped with a maximize button has an attribute set, e.g., maximize="yes".
2. The decorator receives the layout report and renders the window decorations. It detects the 'maximize' attribute and draws the maximize widget accordingly. It is up to the decorator to decide where the widget is located or how big it is.
3. The window manager (the parent of both the decorator and layouter) virtualizes the nitpicker session of the decorator. It thereby intercepts the user input that is referring to the decorator's nitpicker session. The stream of input events is routed to the layouter. However, the current pointer position is presented to the decorator (it is updated only if the pointer moves over the decorator's views).
4. The decorator observes the change of the pointer position and determines the widget at the pointer position. It reports this information as a "hover" report to the window manager.
5. The window manager routes the hover reports from the decorator to the layouter.
6. Thanks to the hover model, the layouter knows the type of the pointed-at decoration widget. Since it receives the user input events that refer to the window decorations, it can implement the application logic to respond to user input events. For example, if it observes a mouse-button-press event and the hover model reports "maximize", the layouter can adjust the window position and size and reports the updated window layout. The story continues at 2.
Intuitively, this procedure sounds pretty daunting, doesn't it? The more fascinating is the fact that it performs quite well. ;-) In return, this design achieves the following goals:
* It sandboxes the potentially complex (and bug prone) graphics operations in the form of the decorator component.
* It protects the content of and user input to applications from the decorator and layouter.
* Since the graphical style of the window decorations is defined inside the decorator component, it can be simply replaced by another implementation. We spare us the complexity of adding theming support to the window manager.
* Since the window-layout policy is defined by a separate layouter component, different implementations could accommodate a variety of window layout approaches like tiled and tabbed windows, virtual desktos etc.
* The window manager has a very low complexity, which is important because it is in the TCB of its client applications.
As you noticed, the implementation is not complete yet. I plan to pick up this line of work again in June.
Also, what is the best way to implement focus on click? People won't want to have to click on the window decorations or the panel every time they want to switch windows.
I guess you are referring to click-to-raise, not click-to-focus. The current version of the window manager does not propagate mouse clicks targeting the application views to the layouter, which would be a precondition to allow the layouter to respond to such events. I agree that this should be added in the future to give the layouter this ability.
It seems like the destop and panel should be at least partially combined. I understand that there could be security issues with this. I have been thinking about how to allow users to have user-specific applications appear on the desktop and menu. What seems the most logical (secure yet user-friendly) is to use different text colors for system-wide and user-specific applications. Do you have any ideas on this? I could see the panel/desktop becoming overly complex.
This is definitely a valid concern. As an experiment to see how to avoid complexity in such security-critical graphical components, I have designed the launcher (gems/src/app/launcher) as a multi-component application. Similar to how the window manager separates the concerns of the layouter and decorator, the launcher separates the concerns of widget rendering and fading from the application logic. Thanks to this design, the launcher's actual application has very few lines of code.
I think that there won't be _the one_ Genode way to address the application-management issue. I foresee different implementations of panels, decorators, layouters, and widget renderers that accommodate different users. For example, personally, I don't need a panel and would rather prefer to activate an application-management interface via a keyboard shortcut.
Marking "trusted" applications with a special color is not an effective security measure unless you prevent all other applications to use this particular color. Otherwise a malicious application could just mimic a trusted application. Nitpicker's X-ray mode addresses this integrity issue by giving the user (not the software!) a mechanism is toggle the security feature at any time. While activated, it actually revokes the ability to use the entire color space from the applications. Bright colors are preserved to nitpicker only. Another complementary approach is the preservation of a certain screen region to the trusted application-management interface and making sure that this region always remains unobstructed from other applications. Nitpicker's layering mechanism accommodates this idea.
Cheers Norman
Okay. Thanks. I can probably get started on improving window management. You have clearly thought a lot about these issues too. As for the text color, don't worry—I would enforce specific colors. My main concern with any launcher with icons is this: can we trust the image loading libraries (e.g. libpng) to be secure? Even if sandboxed, an image loader could still switch icons around to make the user think something is something else. This could be used to trick the user into running spyware (e.g. an infected web browser). Sorry if I'm being too paranoid. On May 12, 2015 2:04 AM, "Norman Feske" <norman.feske@...1...> wrote:
Hi Ben,
On 05/10/2015 10:50 PM, Nobody III wrote:
Thanks for getting me to reread the New GUI Architecture page. It answers some of my questions, but not all of them. For adding minimize/maximize/restore/close buttons to the window decorations, how do we handle the decorator not recieving input? Should it send rectangles to indicate where the buttons are, and be sent signals from the layouter when the mouse is over/clicking on one of them?
it should work like this:
The layouter produces a report for the window layout. Each window that is to be equipped with a maximize button has an attribute set, e.g., maximize="yes".
The decorator receives the layout report and renders the window decorations. It detects the 'maximize' attribute and draws the maximize widget accordingly. It is up to the decorator to decide where the widget is located or how big it is.
The window manager (the parent of both the decorator and layouter) virtualizes the nitpicker session of the decorator. It thereby intercepts the user input that is referring to the decorator's nitpicker session. The stream of input events is routed to the layouter. However, the current pointer position is presented to the decorator (it is updated only if the pointer moves over the decorator's views).
The decorator observes the change of the pointer position and determines the widget at the pointer position. It reports this information as a "hover" report to the window manager.
The window manager routes the hover reports from the decorator to the layouter.
Thanks to the hover model, the layouter knows the type of the pointed-at decoration widget. Since it receives the user input events that refer to the window decorations, it can implement the application logic to respond to user input events. For example, if it observes a mouse-button-press event and the hover model reports "maximize", the layouter can adjust the window position and size and reports the updated window layout. The story continues at 2.
Intuitively, this procedure sounds pretty daunting, doesn't it? The more fascinating is the fact that it performs quite well. ;-) In return, this design achieves the following goals:
It sandboxes the potentially complex (and bug prone) graphics operations in the form of the decorator component.
It protects the content of and user input to applications from the decorator and layouter.
Since the graphical style of the window decorations is defined inside the decorator component, it can be simply replaced by another implementation. We spare us the complexity of adding theming support to the window manager.
Since the window-layout policy is defined by a separate layouter component, different implementations could accommodate a variety of window layout approaches like tiled and tabbed windows, virtual desktos etc.
The window manager has a very low complexity, which is important because it is in the TCB of its client applications.
As you noticed, the implementation is not complete yet. I plan to pick up this line of work again in June.
Also, what is the best way to implement focus on click? People won't want to have to click on the window decorations or the panel every time they want to switch windows.
I guess you are referring to click-to-raise, not click-to-focus. The current version of the window manager does not propagate mouse clicks targeting the application views to the layouter, which would be a precondition to allow the layouter to respond to such events. I agree that this should be added in the future to give the layouter this ability.
It seems like the destop and panel should be at least partially combined. I understand that there could be security issues with this. I have been thinking about how to allow users to have user-specific applications appear on the desktop and menu. What seems the most logical (secure yet user-friendly) is to use different text colors for system-wide and user-specific applications. Do you have any ideas on this? I could see the panel/desktop becoming overly complex.
This is definitely a valid concern. As an experiment to see how to avoid complexity in such security-critical graphical components, I have designed the launcher (gems/src/app/launcher) as a multi-component application. Similar to how the window manager separates the concerns of the layouter and decorator, the launcher separates the concerns of widget rendering and fading from the application logic. Thanks to this design, the launcher's actual application has very few lines of code.
I think that there won't be _the one_ Genode way to address the application-management issue. I foresee different implementations of panels, decorators, layouters, and widget renderers that accommodate different users. For example, personally, I don't need a panel and would rather prefer to activate an application-management interface via a keyboard shortcut.
Marking "trusted" applications with a special color is not an effective security measure unless you prevent all other applications to use this particular color. Otherwise a malicious application could just mimic a trusted application. Nitpicker's X-ray mode addresses this integrity issue by giving the user (not the software!) a mechanism is toggle the security feature at any time. While activated, it actually revokes the ability to use the entire color space from the applications. Bright colors are preserved to nitpicker only. Another complementary approach is the preservation of a certain screen region to the trusted application-management interface and making sure that this region always remains unobstructed from other applications. Nitpicker's layering mechanism accommodates this idea.
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
One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
-
Nobody III -
Norman Feske