Hi Boris,
On 08.02.2018 16:20, Boris Mulder wrote:
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.
exactly! The sole purpose of the nit_focus component is to be replaced. :-) With less than 50 lines of code, it showcases the implementation of the policy that was formerly built-in in nitpicker. Since I moved this policy to this external component, we can do anything we want by replacing it.
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.
Yes.
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?
It is exactly the direction I want to go. The externalized nit_focus component was just a stepping stone.
Still, my remark about the nitpicker-focus handover between sessions holds because such a mechanism is needed regardless of the layouter's / nit_focus policy, e.g., for implementing dialogs with menus or sub-dialogs.
Cheers Norman