Nitpicker changes

[Norman Feske]

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

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