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?