| davidedmundson |
| KWin |
With this patch the previously activated client becomes deactivated while the
user is switching windows. This leads to a more homogenous look and as a side
effect disables all pointer constraints on client surfaces while switching.
When window switching is canceled or a window accepted the respective window
is activated again.
Tested manually on X and Wayland. Pointer constraints deactivation tested with
the pointer constraints test app.
| No Linters Available |
| No Unit Test Coverage |
| Buildable 373 | |
| Build 373: arc lint + arc unit |
| tabbox/tabbox.cpp | ||
|---|---|---|
| 1484 | Maybe if (!clientList.isEmpty()) { ? | |
-2 from my side. This has side effects which could in worst case trigger alt+tab to cancel.
In this case can you point out which side effects exactly and if possible propose a different solution?
Activating a null client causes things to happen. E.g. a window activating itself or a window closing. Especially on X11 Things are happening. Due to the focus to null a lot of things happen.
I looked into years ago when reworking alt+tab. I came to the conclusion that one cannot implement it and as I didn't implement another solution I cannot provide you one.
The deactivation happens in the input filter and therefore only happens on Wayland.
I looked into years ago when reworking alt+tab. I came to the conclusion that one cannot implement it [...]
As you said "years ago", so it might be possible now on Wayland. At least I couldn't spot any issues with it in my tests.
I think it's worth it to try, since besides solving the pointer constraints problem on a conceptual level it makes sense to have no client activated while the TabBox is active.
also on Wayland we have X11 Windows with the negative side effects.
I don't think that Wayland changed anything in that regard. Also I think it's bad to introduce functional differences as that makes debugging way more difficult.
Overall I would recommend against it as the devil is in the detail here like the which window to activate on abort. Tabbox is complex and has many corner cases.
| tabbox/tabbox.cpp | ||
|---|---|---|
| 1485 | This may not be the window you started with! You need to track which window you started with, if it got destroyed you need to ask the focuschain | |
This may not be the window you started with! You need to track which window you started with, if it got destroyed you need to ask the focuschain
Marking as request changes as that's clearly important.
As for the general concept:
This leads to a more homogenous look
Don't really care either way. You could make an argument that it helps you know what you have if you press cancel.
and as a side effect disables all pointer constraints on client surfaces while switching.
This sounds relevant. Is that the main motivation behind the patch?
| tabbox/tabbox.cpp | ||
|---|---|---|
| 1485 | Somewhat related, if a new toplevel gets activated whilst we're tab switching with a pointer constraint is that an issue? | |
I replied in the inline comment.
As for the general concept:
This leads to a more homogenous look
Don't really care either way. You could make an argument that it helps you know what you have if you press cancel.
True, but using the activated state as an indicator for "what-is-happening-when-you-abort" feels like a misguided design language to me.
and as a side effect disables all pointer constraints on client surfaces while switching.
This sounds relevant. Is that the main motivation behind the patch?
Yes, see also the linked task.
| tabbox/tabbox.cpp | ||
|---|---|---|
| 1485 |
I would expect that in case of an abort with prior destruction of the first element the next window defined by the list order of the tab switcher will be activated (which might be the most recently used one besides the destroyed first one or the next one in the stacking order). | |
| 1485 |
Do you mean while the TabBox is active? With this patch the new toplevel gets only activated on close. On current master there should be no problem with pointer constraints, but KWin seg faults anyways for me on this occasion in KWin::Toplevel::effectWindow(). | |
| tabbox/tabbox.cpp | ||
|---|---|---|
| 1485 |
No. If you cancel alt+tab did not happen. So the ordering in Alt+Tab is irrelevant. And KWin uses the FocusChain to decide which window to focus next. That is btw. just one of the interesting issues here. It could also be that the active window was never in the list and so cancel would change the active window. As I said Alt+Tab has many corner cases. | |
Because of risk of regressions abandoned. Pointer constraint deactivation on TabBox invocation was alternatively changed to be done explicitly through f0ba436c724e.