nitpicker focus

[Boris Mulder]

Hi Norman,

Thanks for your reply.

> Furthermore, I think that the current nitpicker interface for passing
> the focus between sessions needs to be improved. It immediately triggers
> an action (which depends on conditions such as whether the calling
> session has the current focus or not) but if the condition is not
> satisfied, focus-change action gets lost. I plan to change this
> interface such that a client will be able to specify the session label
> it likes to yield its focus to. This is will be not an event but a
> state. Regardless of when the client becomes focused, this focus-yield
> information will come into effect.
That might make implementing features such as mine easier!

> Since the layouter is the arbitrator of the focus, but you still want to
> consider the wishes of an external component, it would be natural to let
> the layouter listen to these wishes and consider this information for
> its decision. Hence, you would need an interface to let the layouter
> know these wishes. Still, the layouter's stays in the position to take
> the ultimate decision. I have no suggestion of how such an interface
> should look like. Ideally, it would be a state presented via a ROM module.
Actually that is what I am trying to do now, and it sort of works for
bringing other sessions to the front.

However, the problem here is that the nit_focus component only checks
the clicked session, not the ones brought to the front externally.

> Ideally I want the focus of windows to be decided by the wm/layouter,
> but also have the possibility for an external component to bring certain
> windows to the top and focus them without the need of a user click.
So we need to have another nit_focus like component (or an extension of
the existing one) that bases its output on some report generated by the
layouter. The layouter should generate a report with the label of the
current window on top of the stack, and this new component generates the
focus report accordingly. With rom_filters this can then be integrated
into the scenario the same way as with nit_focus. Whenever another
window is put to the front, either by clicking or through the new
external report, the layouter should update its own report with the top
window. Then the nit_focus component can update its focus report in turn.

One option would be using the "focus" report of the layouter together
with the window_list or window_layout report.

In this case, since the wm lives above the runtime init, the report
generated by the new nit_focus would need to have a label_prefix
appended, e.g. the window list reports label "noux -> nit_fb -> "
whereas nitpicker wants to see "runtime -> wm -> noux -> nit_fb -> ".
This depends on your scenario so should be configurable.

What do you think of this direction? Worth integrating into Genode?

-- 

Met vriendelijke groet / kind regards,

Boris Mulder

Cyber Security Labs B.V. | Gooimeer 6-31 | 1411 DD Naarden | The Netherlands
+31 35 631 3253 (office)