Bug 375921

I don't think that's a bug at all. @Eike: what do you think?

Ah sorry, I was not sure if it was a bug, or if it was by design.

I thought it was a bug because the other launchers disappear and this one doesn't.

It feels weird to me though that this launcher seems to be treated as an app window (also by alt-tab).

Reassigning to Plasma: it needs to be considered whether appdash should close like other launchers when losing focus.

I sorta do think it's a bug, I don't think it should show in PW.

This is related to 52d04f89e, which made Dashboard try to regain focus when lost, because of the following user behavior pattern:

1. Launch something from Dashboard
2. Immediately open Dashboard again to do more stuffr
3. Launched app actually appears, tries to get focus, Dashboard loses it
4. Dashboard doesn't work right because it's shown but doesn't have focus

Closing Dashboard on focus loss would cause a new problem of the same sort, where the user wants to use it but the app appearing causes it to be closed.

Martin, is there a different way I can hide Dashboard from PW? Or does it make sense for the effect to be adjusted to ignore SkipPager windows when not invoked with a window list to present?

I am not sure if it is another bug (or a bug at all), but hitting super key also brings the dashboard in present windows.

Actually, all launchers appear as plasma windows in present windows if I hit the super key.

> Martin, is there a different way I can hide Dashboard from PW? Or does
> it make
> sense for the effect to be adjusted to ignore SkipPager windows when
> not
> invoked with a window list to present?

No, SkipPager windows should be shown in PresentWindows. Also this is 
just one effect which is affected by this. It would also show in 
DesktopGrid, etc.

To me it's not a problem that the dashboard is shown.

Hmm So is this a bug or a feature?

See comment #4

Martin what do you think?

See comment #2 ... what's the point of this? :)

reproducible on Arch Linux, plasma 5.12.2.

*** Bug 391233 has been marked as a duplicate of this bug. ***

We have multiple bug reports about this issue, and it's not intended or useful behavior from a user perspective (not a developer perspective); in short, it's a bug. The question is how we resolve it.

skipSwitcher does in fact exist, and is visible in System Settings > Window Management > Window Behavior > [new rule] > Arrangement & Access.

Setting a rule and targeting my launcher works like a charm: no more launcher in the Present Windows effect. So fixing this bug is possible; the question is just whose responsibility it is do do it: should (could?) launchers signal that they want to be skipped, or do we need a built-in KWin rule?

It doesn't currently exist in the way that matters from the launcher side:

https://api.kde.org/frameworks/kwindowsystem/html/classKWindowSystem.html#a2fcec2ab4297afe9edae7971b1a4cd86

https://api.kde.org/frameworks/kwindowsystem/html/classNET.html#a08dce7f5ea8a2a6d1d38aea3498f00ee

If it was a simple as that I'd have done it long ago.

OK, so then it seems we have four options:
- KWin exposes something for launchers to signal that they don't want to be displayed in the effect
- We ship KWin with a default skipSwitcher rule for launchers
- KWin does nothing, and it's up to distros to ship with the rule (and we continue to get bug reports from users of other distros)
- Nothing happens, and we continue to get bug reports

Is that correct?

My preferred option is still for KWin to start ignoring windows that have SkipPager set in Present Windows (because my argument remains that any summarized view of windows is conceptually a pager).

In lieu of that, we need a new SkipSwitcher state in the KWindowSystem API (for X11) as well as in the PlasmaWindowManagement protocol (for Wayland).

IMHO the rule-based approach is a hack.

> My preferred option is still for KWin to start ignoring windows that have SkipPager set in Present Windows (because my argument remains that any summarized view of windows is conceptually a pager).

Makes sense to me. Do the KWin maintainers feel otherwise?

(In reply to Nate Graham from comment #18)
> > My preferred option is still for KWin to start ignoring windows that have SkipPager set in Present Windows (because my argument remains that any summarized view of windows is conceptually a pager).
> 
> Makes sense to me. Do the KWin maintainers feel otherwise?

Yes

For the record: KWin ships a script which synchronizes skip taskbar to skip switcher. Any user can just enable this.

Ah, so it does! That's nice. I can confirm that it works for me on Plasma 5.12.2

However, the power of good defaults is that they're, well, default. :) The set of users who understand this matter well enough to know that this script exists and should be enabled is probably equal to the KWin developers. :)

Let's consider enabling the script by default, and if any expert users or KWin developers don't like it, they can turn it off, and the huge mass of regular users will benefit from it at least.

Turning this script on by default should be a trivial change, if we can agree on that.

If someone wants to do code on it the IMHO only solution is:
 * add skipSwitcher to the Plasma Surface protocol
 * use this in Plasma
 * add it to KWin (relevant method: ShellClient::installPlasmaShellSurface)
 * ignore X11

I'm strictly against just mapping skipPager to skipSwitcher. There's a reason why we introduced it in KWin.

It is not a huge issue. SkipSwitcher was introduce in 2011 and since then nobody cared about adding it to the X11 API. This means it's not as much a deal as it looks like in the last few comments. Now it's of course too late to add it to X11, KWin is feature frozen.

(In reply to Nate Graham from comment #21)
> Let's consider enabling the script by default, and if any expert users or
> KWin developers don't like it, they can turn it off, and the huge mass of
> regular users will benefit from it at least.
> 
> Turning this script on by default should be a trivial change, if we can
> agree on that.

Absolutely not! This would remove windows with skip taskbar also from Alt+Tab. It would create way more problems than you expect. There are many, many applications setting this state and one should be able to Alt+Tab to them. E.g. Yakuake.

> If someone wants to do code on it the IMHO only solution is:
>  * add skipSwitcher to the Plasma Surface protocol
>  * use this in Plasma
>  * add it to KWin (relevant method: ShellClient::installPlasmaShellSurface)
>  * ignore X11

Eike, is that an approach we can agree on?

Sorry, I didn't mean for you to lose too much time on this small issue.


Nevertheless, IMHO hiding the menu in present windows is a partial solution:
- If I open the dashboard, activate present windows and select a window, the dashboard is still there underneath .


Just my two cents here but:
- I think that the dashboard should quit when it loses its focus. 
It seems to me that the focus stealing that the menu is trying to prevent is introducing more issues, and the behavior is inconsistent with the other menus.

- And, if it is possible, present windows should inhibit the super key just like it does for alt+F1 (but I guess the super key is handled differently).

(In reply to grouchomarx.fr from comment #25)
> - And, if it is possible, present windows should inhibit the super key just
> like it does for alt+F1 (but I guess the super key is handled differently).

Present windows doesn't inhibit alt+F1 - that's just a long-standing bug on X11 and fixed on Wayland.

Re comment 24:

Yup, I can agree with that. I think exposing SkipSwitcher in the API makes sense. I also think this makes an excellent "my first kwayland/kwin patch" Junior Job, since it's basically just taking a look at how the other Skip* stuff works and doing the same. Could be a nice way to onboard a new contributor.

> I think that the dashboard should quit when it loses its focus. 

Here's the thing: It already does. Activating Present Windows doesn't make it lose focus.

(In reply to Eike Hein from comment #28)
> Here's the thing: It already does. Activating Present Windows doesn't make
> it lose focus.

Thanks. I've made a wrong assumption.

But then, why do the other traditional menus disappear when a switcher is launched and the dashboard doesn't?

More importantly, why selecting a window with present windows or alt+tab doesn't make the dashboard go away? Shouldn't that make it lose focus?

(open some apps, launch the dashboard, launch present windows with the hot corner or launch alt+tab, select an app other than the dashboard -> the app is selected, but the dashboard is still there)

(In reply to Eike Hein from comment #27)
> Re comment 24:
> 
> Yup, I can agree with that. I think exposing SkipSwitcher in the API makes
> sense. I also think this makes an excellent "my first kwayland/kwin patch"
> Junior Job, since it's basically just taking a look at how the other Skip*
> stuff works and doing the same. Could be a nice way to onboard a new
> contributor.

I'm always open to being onboarded, but would like to clarify a few things before bumbling around in the KWin code.

I think I understand this correctly... `skipTaskbar` and `skipPager` are essentially just flags (in `NET::State`) that can be set on a window. Adding `skipSwitcher` requires adding another available flag, more or less. KWin itself doesn't directly act on these flags, but makes them available to other applications. In other words, KWin doesn't control what shows up in a pager or a switcher or a taskbar - it just reports which windows are eligible, according to which `state` flags are set. It's up to the pager/switcher/taskbar to show only the correctly-flagged windows.

Do I understand that correctly?

I apologize if this question is elementary to any of you. The internals of a windowing system are new to me. I'm eager to help out (as always), but I'm also not in the habit of wasting people's time with guesswork submissions.

Thanks.

The states are from X11, in KWayland they are all booleans. As Eike wrote: just look how it was done for the other cases and adapt. It should be straight forward

@Scott: Find me on IRC (Sho_ in #plasma) some time if you want to work on this, I can give you a hand / answer more detailed questions.

(In reply to Eike Hein from comment #32)
> @Scott: Find me on IRC (Sho_ in #plasma) some time if you want to work on
> this, I can give you a hand / answer more detailed questions.

Thanks, Eike. I've got it partially completed (since yesterday). The autotest for setting the window state (kwindowsystem version) is failing on me; trying to sort out what I've got wrong. I'll be stubborn a bit longer before bothering you. Thanks for the assistance.

Fixed with https://cgit.kde.org/kwayland.git/commit/?id=10b00a219e9fddd57431d6bdb6550cdba6ed73bf

Thanks, Nate. You beat me to the comment.

*** Bug 395425 has been marked as a duplicate of this bug. ***