Hello,

with the incorporation of my recent work on issue #1690 [1] into the master branch, the use and configuration of the nitpicker GUI server has changed.

[1] https://github.com/genodelabs/genode/issues/1690

Up to now, nitpicker used to handle the so-called X-ray mode internally. When activated by the user by pressing a configurable key, this mode tinted all views with domain colors and added labeling information to all views. It was meant to assist the user with uncovering Trojan Horses.

However, the built-in policy started to stand in our way when implementing advanced scenarios like Turmvilla [2]. Here, we want to be more flexible with how the X-ray mode is activated, and how it affects the behavior of the user interface. For example, the delivery of hovering motion events to unfocused sessions, the ability to change the input focus by clicking on a unfocused view, the suppression of the labeling for trusted parts of the GUI.

Building-in all those "features" into nitpicker would ultimately increase its complexity, and still fail to cover all thinkable use cases. To avoid that, I removed the notion of the X-ray mode altogether but added all the various aspects of the policy as explicit attributes of nitpicker's domain configuration. The idea is that the notion of the X-ray mode is provided by a separate component (xray_trigger), which reconfigures nitpicker each time when the X-ray mode is toggled. The X-ray trigger component contains the policy of when the X-ray mode is activated. E.g., by interpreting certain global keys. It simply produces an X-ray report that tells whether X-ray is active or not. The reconfiguration of nitpicker is done by a separate component that takes the information of the X-ray report and generates a nitpicker configuration. To avoid this component to be nitpicker-specific, I came up with a generic 'rom_filter', which is able to generate a ROM module with arbitrary XML, depending on other ROM modules, like the X-ray report. The output of the ROM filter is fed to nitpicker as configuration.

Granted, to achieve the original effect as present in the demo.run script, the scenario becomes more complicated because we have to start the xray_trigger and rom_filter in addition to nitpicker. However, we gain a lot of flexibility that can now be expressed by the means of combining and configuring those components. To see the interplay of those components to emulate the original behavior, please have a look at the os/run/demo.run script.

Most other run scripts use nitpicker solely as an output facility. Here, the X-ray mode is actually unimportant and it suffices to set up the nitpicker configuration in a way that allows for basic interactions. For example, the following configuration can be used as a template:

<config> <domain name="pointer" layer="1" content="client" label="no" origin="pointer" /> <domain name="default" layer="2" content="client" label="no" hover="always" focus="click" />

<policy label="pointer" domain="pointer"/> <policy label="" domain="default"/> </config>

It assigns the pointer to its dedicated domain, using the pointer position of the origin of its coordinate space. All regular clients end up in the "default" domain, their content is presented as is (not tinted) without any labeling, motion events are delivered to the clients whether they are focused or not, and a client can be focused by clicking onto one of its views.

As for a more sophisticated example, I have incorporated the new concept into my Turmvilla branch [2] where not only nitpicker but also the window decorator dynamically responds to the X-ray mode. Here, X-ray is activated whenever the pointer hovers a window decoration, which illustrates quite well the flexibility of the new approach.

[2] https://github.com/genodelabs/genode/issues/1552

Cheers Norman