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.
- Initially, the login screen is focused and shown since it is up. I
login and it disappears.
- 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).
I click on the noux window. Now it is both visible and focused.
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.
Now I lock the screen. The login screen pops up again and is focused.
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