Can repro on Neon unstable, Plasma 5.23.3, Frameworks 5.87, Qt 5.15.2.

Also "Keep window above" doesn't work on Wayland (that is possibly bug #381541), which in combination with this issue makes "keep window open when it loses focus" almost useless, so I turned it off.

I started working on a fix for this. The initial problem was that Yakuake was using a legacy check for determining whether it is the active window, but that check doesn't work on wayland and always returns false. So if the setting was enabled to re-focus Yakuake instead of showing or hiding it, Yakuake would always believe it wasn't focused, and would try to refocus itself instead of showing/hiding itself.

The fix for the initial issue was trivial, but it turns out that there is currently no way for a Wayland application to request activation or focus for itself. There's "xdg-activation" which was added to kwin in 5.23, but if I understand correctly, that's just for the currently-active application to activate another one of its windows or controls - it doesn't seem to support an application requesting focus for itself while another application is active. I'm not sure if this is a fundamental design decision of xdg-activation or a design choice in the kwin implementation - the xdg-activation documentation seems to leave some things to the compositor's discretion. I believe the issue is this line in kwin: https://invent.kde.org/plasma/kwin/-/blob/master/src/xdgactivationv1.cpp#L44 - it denies permission for any client other than the active one (or the window manager) to create the activation token necessary to active a window.

Am I correct in these assumptions? If so, this functionality can't work in Wayland, at least not without kwin changes.

This seems to be partially related to bug 424795, but I don't think the upstream fix there will be sufficient.

It seems that there's no way on Wayland for an application to request focus for itself when another application is focused ("stealing" focus). xdg-activation only supports the currently-active application switching between its own windows, or voluntarily relinquishing focus to another application (and both applications, or the frameworks they're based on, need to be specifically coded to support relinquishing or receiving activation).

As far as I can tell by Google searching, there are no plans for Wayland to allow an application to "steal" focus from another application. Something like this would have to be added to kwin, and I imagine this would be a lot of work - probably a brand new protocol extension. And I'm not confident the Wayland team would even want something like this (they specifically designed xdg-activation to prevent focus stealing). So - I don't think there's any reasonable chance of getting this functionality to work on Wayland in the foreseeable future.

I don't mind quickly tapping F12 twice, which accomplishes the same thing. Although, this brings up a question about Wayland in general: a currently running application can create and display a NEW window any time it wants, and this will steal focus (dependent on the compositor, but kwin obviously supports it) - so I'm not sure how useful it is to prevent an existing window from stealing focus.

Since this won't work on Wayland, I'm thinking it's best to disable the feature there. I'm not sure the best way to do that though, as it might be kind of tricky with settings, or a confusing UI with the checkbox, due to being able to switch between X11 and Wayland sessions.

The current situation (with recent Neon unstable packages) is that if enable "Use Open/Retract action to focus window" (which requires "keep window open when it loses focus") - then the Yakuake window both cannot be hidden (which on X11 would normally work by either tapping the global shortcut again, or exiting the last shell) and if the Yakuake window loses focus - there global shortcut cannot be used to give it focus again. Even if Yakuake is configured to appear on the active screen, and I move my mouse to another screen and try to activate it - the window jumps to the active screen by remain unfocused (even if it is the only window on that screen).

When disabling "keep window open", the behavior is more as expected, including being able to hide the window using the global shortcut again (which is weird to me why it depends on the setting of "keep window open") or by closing the last shell.

(In reply to Tiernan Hubble from comment #3)
> It seems that there's no way on Wayland for an application to request focus
> for itself when another application is focused ("stealing" focus).
> xdg-activation only supports the currently-active application switching
> between its own windows, or voluntarily relinquishing focus to another
> application

I've reviewed the XDG activation (https://wayland.app/protocols/xdg-activation-v1) and I don't understand why this protocol would not allow any application to request focus by creating an activation token and using it immediately - the accompanying text only suggests that activation tokens *may* be unusable due to focus stealing prevention. The spec in no way requires the composer to implement focus detection or any focus stealing prevention algorithm, just that the activation protocol make it easier for a composer to implement such algorithms - if it wants to.

A possibly relevant merge request was started @ https://invent.kde.org/utilities/yakuake/-/merge_requests/81

(In reply to Oded Arbel from comment #4)
> I've reviewed the XDG activation
> (https://wayland.app/protocols/xdg-activation-v1) and I don't understand why
> this protocol would not allow any application to request focus by creating
> an activation token and using it immediately - the accompanying text only
> suggests that activation tokens *may* be unusable due to focus stealing
> prevention. The spec in no way requires the composer to implement focus
> detection or any focus stealing prevention algorithm, just that the
> activation protocol make it easier for a composer to implement such
> algorithms - if it wants to.

That would definitely make more sense if it's the case. I never actually looked at the protocol docs, only the implementations that have been done (mainly kwin). I haven't checked in detail since I posted my last comment, but I'm pretty sure kwin still only considers an xdg activation token as "valid" if it was requested by the currently-active window. A change in Plasma 5.24 made it so that if an app tries to activate itself and it doesn't have a currently-valid token, it will bounce the taskbar icon but not automatically activate the window: https://invent.kde.org/plasma/kwin/-/merge_requests/2206  - you can see this behaviour in Kate if you un-focus the Kate window and then open a new file with "kate [file_name]" in a terminal.

In the comments of the main xdg_activation tracker issue (https://invent.kde.org/plasma/kwin/-/issues/39) there's mention of the currently-active window being able to pass its valid activation token when requesting that another application activate itself. The problem with yakuake is that it's not the currently-active application "passing" focus, it's the hotkey. Unless there's some way in KGlobalAccel to do it?

(In reply to Tiernan Hubble from comment #6)
> you can see this
> behaviour in Kate if you un-focus the Kate window and then open a new file
> with "kate [file_name]" in a terminal.

That seems like a deficiency in Kate (or in QCoreApplication?) - the trivial approach is to have the new process (the one you invoke by typing `kate` in the terminal), after it becomes active and determines that there's another window that should get the focus - to grab an activation token and pass it to the older Kate instance: it is quite obvious that the use would want to see the file editor immediately, so doing anything else is a bug.

I love Kate, but this isn't my workflow so I won't work on that, but someone who is interested should definitely report that bug. 

> The problem with
> yakuake is that it's not the currently-active application "passing" focus,
> it's the hotkey. Unless there's some way in KGlobalAccel to do it?

I'm currently on Wayland, and yakuake knows top open and activate its window when it is closed - I believe it is definitely the KGlobalAccel framework doing it, though I'm not sure how - tracing on Yakuake's `toggleWindow()` the calls comes from deep within Qt core, and I have no idea how KGlobalAccel work, but as it obviously does work - I'll chalk it up as "magic" and trust it :-D

With the above merge request, the only thing that is still missing - for me - is why KGlobalAccel correctly activates an existing Yakuake app with a hidden window but not an existing Yakuake with a visible window. I think its is again something to do with Yakuake's over-reliance on KWindowSystem as a window abstraction layer - but as its Wayland implementation is basically "nothing to see here, move along", KWindowSystem is an abstraction layer for X11 only and for everything else you'd need the app to implement windowing support on its own.

I'll try to figure that out.

BTW - regarding why Yakuake should not rely on KWindowSystem, see bug #442662. The main problem with all of Yakuake Wayland issues is that Yakuake relies heavily on KWindowSystem to work, and it does not work on Wayland - apparently by design.

As for KGlobalAccel allowing activation - I don't know how it works: after triggering, Yakuake can do `QWindow::show()` to show and activate itself, but I found no way to activate if the window is already shown (calling `show()` again obviously has no effect). I can workaround the issue of handling "activate existing window" by call `hide()` then `show()` - works great if you don't mind the flickering...

Another feature that is missing in Wayland, that I forgot to note previously, is "keep above" for the Yakuake window. A user can workaround it by creating a KWin window rule, but it shouldn't be that way - KWin should allow applications to request that. Unfortunately, the Plasma Wayland interface to do these kind of things (including activation) is `org_kde_plasma_window_management` that is "privileged" and application's can't get it. This is a regression from X11's KWindowSystem, but at this point I'm not going to dig into KWin's internals and I think any additional work requires support from a KWin developer.

Still, MR 81 offers some obvious small improvement with no ill effects (it doesn't include the flickering workaround) and I would appreciate it if someone with commit permissions can merge it.

xdg-activation isn't supposed to allow application to arbitrarily raise themselves, it was designed for a specific scenario, which is allowing a focussed application to pass that focus to a different application. That is why kwin checks whether the requesting application has focus. That makes it unsuitable for fixing this bug

(In reply to Nicolas Fella from comment #10)
> xdg-activation isn't supposed to allow application to arbitrarily raise
> themselves

It is a bit useless for that, though. As the new commit in the above looked MR shows - it is easy to abuse: if an application can create a new top level window (for example, by calling `QWidget()`), it can give itself activation rights.

With the current state of the MR, all the Wayland functionality that I was missing is now working well for me. If people want to test it and report issues, it will be appreciated, as well as if someone with commit access will be able to merge it.

(In reply to Oded Arbel from comment #11)
> With the current state of the MR, all the Wayland functionality that I was
> missing is now working well for me.

Correction - the "keep above other windows" setting, and the (always on in X11) "show on all desktops" feature aren't working on Wayland due to missing APIs to ask these behaviors from KWin. I've opened bug #460873 to ask for these features in the plasma-specific wayland interface org_kde_plasma_surface.

Git commit f0a2c72a6c52a16a0f74382e3c5d3218daa4363d by Nicolas Fella, on behalf of Oded Arbel.
Committed on 20/12/2022 at 21:59.
Pushed by nicolasfella into branch 'master'.

Reduce use of KWindowSystem on Wayland
Related: bug 381541

This patchset was originally part of MR !81.

Problem description: Currently most of KWindowSystem standard API does not work on Wayland, on purpose - the code for Wayland support was actually removed from the KWindowSystem framework into a standalone [plasma/kwayland-integration](https://invent.kde.org/plasma/kwayland-integration) where [src/windowsystem/windowsystem.cpp](https://invent.kde.org/plasma/kwayland-integration/-/blob/master/src/windowsystem/windowsystem.cpp) has almost all API implementations empty and just issue warnings in the form of "This plugin does not support...".

Additionally, in [bug report 442662: KWindowSystem on Wayland is missing many signals, some of which are needed by Yakuake](https://bugs.kde.org/show_bug.cgi?id=442662#c1) David Edmundson says "Wayland is different, trying to shoehorn that into the exact same abstractions simply won't work. Lets split this up as individual bugs on yakuake".

So this is some of that work of changing Yakuake Wayland behavior to not rely on non-working (or mostly non-working) KWindowSystem and replace with operations using Wayland APIs directly, or Qt API that is known to work with Wayland.

This patch set is not complete in that:
a. There are some operations that are as of yet not possible under Wayland (for example - set visible on all desktops), so removing those code calls under Wayland will hide warnings that we may want to keep to remind us there is missing behavior.
b. There are still some wayland-integration warnings that are shown when running Yakuake on kwin_wayland. I did not work on these because changes do not affect my use case (also see (a) above). If there is need, I can review more APIs and do more KWindowSystem reduction.

M  +17   -7    app/mainwindow.cpp

https://invent.kde.org/utilities/yakuake/commit/f0a2c72a6c52a16a0f74382e3c5d3218daa4363d

Sorry, that's my bad - MR 83 doesn't solve this issue (or at least the important parts of it). We need MR 84 (https://invent.kde.org/utilities/yakuake/-/merge_requests/84) for this issue.

Any news about this issue? Wayland is now the default compositor on Plasma 6 and this bug is breaking the experience of using Yakuake.

I can see there is a MR that is supposed to fix this issue (https://invent.kde.org/utilities/yakuake/-/merge_requests/91), but it was never merged.

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

even after update my system to plasma 6.0.3 the issue si still there

Operating System: EndeavourOS 
KDE Plasma Version: 6.0.3
KDE Frameworks Version: 6.0.0
Qt Version: 6.6.2
Kernel Version: 6.8.2-zen2-1-zen (64-bit)
Graphics Platform: Wayland
Processors: 12 × Intel® Core™ i7-9750H CPU @ 2.60GHz
Memory: 15.4 Gio of RAM
Graphics Processor: NVIDIA GeForce GTX 1650/PCIe/SSE2