Can confirm on KDE Neon unstable.

Oddly enough when I tried it yesterday on my main (Arch Linux) PC on Wayland I could NOT confirm this, Yakuake actually DID open on the screen with the mouse. However, it was not resized correctly for the secondary monitor which has a lower resolution, thus it was cut off to the right.
I have not found any configuration difference between the two machines that would explain the different behavior (both were also running the master build of Yakuake)

EXPECTED RESULT
Yakuake should open on the screen where the mouse pointer is on Wayland, like KRunner or Yakuake does on X11.

(In reply to m1st0 from comment #2)
> EXPECTED RESULT
> Yakuake should open on the screen where the mouse pointer is on Wayland,
> like KRunner or Yakuake does on X11.

Sorry, should have confirmed rather than noted unnecessary semantics. Confirmed on Kubuntu 21.10, KDE Plasma 5.23.0.

Can confirm that it doesn't working on Kde Neon with 5.24.0

Confirm on Manjaro KDE Plasma 5.23.5

Confirm on EndeavourOS with KDE Plasma 5.24.3

Git commit ae055c29d7f4fb2ca5e8406410611ffb499f5028 by Nate Graham, on behalf of Martin Seher.
Committed on 11/04/2022 at 20:25.
Pushed by ngraham into branch 'master'.

On Wayland, show on active output

QCursor::pos does not work under wayland. So use active output from KWin
to determine startup screen, if not configured otherwise.

M  +14   -0    app/mainwindow.cpp

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

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

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

This no longer works on Xorg after upgrading to Yakuake 22.08.0 (on Arch Linux). Downgrading Yakuake to 22.04.3 restores the functionality. KRunner is also affected.

Experiencing this with Yakuake 2022.04.3 as well.

(In reply to Szczepan Hołyszewski from comment #11)
> Experiencing this with Yakuake 2022.04.3 as well.

As the "Version fixed in" field says, this is expected to be fixed in version 22.08.

Sorry, I got confused because Thomas Brix Larsen above said that _downgrading_ to 2022.04.3 fixed this for him. But it seems that he was in fact reporting a regression on X caused by this fix?

I am not sure if it is right to comment on this closed ticket. However, for me, the problem as described in the summary is not (or not anymore) fixed.

There are other open issues that seem to be about the same or a similar problem, see bugs 383555, 481966.

I actually came here after Git-blaming the QDBus call to KWin’s activeOutputName in app/mainwindow.cpp (see comment 7). It seems that activeOutputName does not always give a result that fits the description “At mouse location”. Instead, it seems to either return the output of the focused window or the mouse pointer, depending on if the focus or the mouse position changed last. This can easily be verified by watching the output of `watch -n.1 qdbus org.kde.KWin /KWin activeOutputName` while Alt-tabbing between windows on different screens or wiggling the mouse on a particular screen.

Consequently, Yakuake opens on the screen with the focused window when window focus change was more recent than mouse move. Unfortunately, the focus change can be caused by Yakuake itself when it closes. This may lead to the the following IMO confusing behavior: Assume Yakuake is currently closed, a window is focused on screen 1 and mouse has recently moved on screen 2. When Yakuake is opened via the hotkey, it appears on screen 2. When Yakuake is closed via the hotkey, the window on screen 1 gets focused. Hence, when opening Yakuake again, it now opens on screen 1.

In `kcmshell6 kcm_kwinoptions`, I use the default window activation policy “Click to focus”. I tried other strategies, but those have other disadvantages for me. Setting focus stealing prevention to “Extreme” actually solves the issue, however, this does not feel right either.

I see the following questions now:

* What is the intended behavior of Yakuake regarding mouse position (and maybe window focus)?
* What is the intended behavior of activeOutputName?
* Do those two match?


PS:

While digging into the problem I added some printf debuging to Yakuake. There I noticed that activeOutputName is queried several times when Yakuake is opened or closed. Sometimes the result changes during the same open/close action. I think I only observed this on close actions, but, since this is inherently racy, I guess this can also happen when opening Yakuake. I cannot say if this has any bad implications; it’s just a hunch that it might have.

There are also bugs about wrong Yakuake window sizes (which I can also confirm), see bugs 482733, 485069, 488780. I was not able to confirm that those are related to the race, nevertheless I wanted to mention it.


Operating System: Arch Linux 
KDE Plasma Version: 6.1.3
KDE Frameworks Version: 6.4.0
Qt Version: 6.7.2
Kernel Version: 6.9.10-arch1-1 (64-bit)
Graphics Platform: Wayland (however, problem also occurs with X11)
Yakuake package version: 24.05.2-1