nitpicker focus

[Boris Mulder]

Hi,

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.

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?

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.

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?

-- 

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)