nitpicker focus

[Norman Feske]

Hi Boris,

On 08.02.2018 14:28, Boris Mulder wrote:
> I have implemented a scenario with nit_user_focus similar to the one you
> described below. For such scenarios this works fine.
> 
> However, the scenario I want to make is a little bit more complicated. I
> would like to hear your opinion on this.
> 
> On one end I have the login popup that behaves a bit like the
> leitzentrale from sculpt. When it is up, it always gets the focus
> through the rom_filter rule. So far, so good.
> 
> However, on the user end I am using the window manager. All the user
> applications' nitpicker sessions are routed to the wm. Windows can be
> maximized or not maximized. The maximized state might be toggled with
> buttons or keys or it might be fixed.
> 
> Also, I want applications that have just started to be focused and put
> on top of the window stack immediately. For this I and Martijn made some
> changes in the layouter such that if the layouter gets a new
> focus_request ROM update, it will try to bring the requested window to
> the top and focus it. The request is then generated by our launcher
> component. This also works fine.

That sounds all as intended.

> However, the nit_focus component does not really do what we want here.
> This can be illustrated with the following example.
> 
> - We have three GUI components: the login screen which should always be
> focused; a noux window and a virtualbox window, all of which are in
> maximized state.
> 
> 1. Initially, the login screen is focused and shown since it is up. I
> login and it disappears.
> 
> 2. I start the noux component. Now the noux component is visible, though
> it does not have the focus yet as it is not clicked and nit_focus has
> not produced a report. The focus_request from the layouter is not
> applied since the window manager is not in control of the currently
> focused nitpicker session (which is none).
> 
> 3. I click on the noux window. Now it is both visible and focused.
> 
> 4. Now I start virtualbox. Because noux is a client of the wm, the
> focus_request is applied and our hack made sure the new window is
> immediately visible and focused.
> 
> 5. Now I lock the screen. The login screen pops up again and is focused.
> 
> 6. I login again. the VM is still the top window and is visible now.
> However, the focus is back to the last clicked component, which is noux.
> I am an uncaring end-user and type in my password for the trusted VM and
> hit enter. My password is now entered in noux, as it had the focus. Now
> suppose it is not noux but an untrusted/possibly compromised VM
> connected to the internet.
> 
> Now what causes this issue is the fact that I wanted there to be other
> ways besides clicking to bring a window to the front. In fact, it would
> be nice if the window manager was always in charge if the login screen
> is not up. So I tried removing the nit_focus component and hardcoding
> the focus attribute to be "wm -> " in case the login screen isn't up. It
> seemed to me that this might solve point 2 (since the focus now belongs
> to wm) and point 6 (since the wm is in charge and automatically focuses
> the hovered window). However, the focus_request does not seem to do
> anything now and no window ever gets the focus, even if clicked. I do
> not really understand how this works. Can you give an explanation?

In the sculpt scenario, the nitpicker focus is actually defined by a
cascade of ROM filters.

The 'nit_user_focus' component represents the focus defined by the
window manager (the layouter actually). This is the 'nit_focus' binary.
In contrast, the 'nit_focus' component is a ROM filter that takes the
output of the 'nit_user_focus' and generates the real nitpicker focus.
This ROM filter is the point where the global override of the
window-manager's policy happens. Admittedly, the naming is a bit
ambiguous since the 'nit_focus' component does not use the 'nit_focus'
binary.

That said, since I integrated the wm in the Sculpt scenario last week, I
encountered a few focus-related complications. In particular, there
apparently are situation where the window manager takes the focus away
from the leitzentrale. This is a bug in nitpicker that must be fixed.

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.

> One thing I could do is let the launcher also generate a focus report
> focusing the last started application whenever it starts. However, this
> would mean it needs to keep track of the window stacking order and
> focusing besides the wm/layouter, as switching focus no longer works.
> This does not sound like a good direction to me.

I agree. This is the responsibility of the layouter, not the launcher.

> 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. Do
> you have any ideas for how to accomplish this?

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.

Cheers
Norman

-- 
Dr.-Ing. Norman Feske
Genode Labs

https://www.genode-labs.com · https://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth