https://bugs.kde.org/show_bug.cgi?id=445158

Flupp <flupp+bugs.kde....@mailbox.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Flupp+bugs.kde.org@mailbox.
                   |                            |org

--- Comment #14 from Flupp <flupp+bugs.kde....@mailbox.org> ---
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

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to