Summary: | _NET_WM_STATE_FOCUSED is not set for CSD enabled windows | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | Martin Stransky <stransky> |
Component: | compatibility | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | kde, nate, notuxius, zeratul976 |
Priority: | NOR | ||
Version: | 5.13.4 | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
Latest Commit: | https://commits.kde.org/kwin/ce1a5eae156a544da06a9a37ee00b6b55dd13bb3 | Version Fixed In: | 5.16.0 |
Description
Martin Stransky
2018-09-19 09:44:25 UTC
X or wayland? Also window_state_event is an internal GTK thing, if you can phrase things in terms of the relevant atoms / protocols that's a lot more useful. Can reproduce this bug on X11 - not on Wayland Operating System: KDE neon Developer Edition KDE Plasma Version: 5.14.80 Qt Version: 5.11.1 KDE Frameworks Version: 5.51.0 Kernel Version: 4.15.0-34-generic This is out of scope for an X11 window manager. I suspect KDE does not set _NET_WM_STATE_FOCUSED when the window is running in CSD mode although I didn't look into the KDE sources. We currently do not set it.
But we also don't announce it in our _NET_SUPPORTED which implies something is also wrong on the GTK side to rely on expecting it.
>Clients that modify the appearance of internal elements when a toplevel has keyboard focus SHOULD check for the availability of this state in _NET_SUPPORTED and, if it is available, use it in preference to tracking focus via FocusIn events. By doing so they will match the window decorations and accurately reflect the intentions of the Window Manager.
It's not available so surely GTK should be falling back to the manual FocusIn tracking?
We do not support _NET_WM_STATE_FOCUSED. Git commit ce1a5eae156a544da06a9a37ee00b6b55dd13bb3 by David Edmundson. Committed on 10/05/2019 at 14:32. Pushed by davidedmundson into branch 'master'. Support NET_WM_STATE_FOCUSED Summary: This is used by GTK clients to know whether to draw as though they have focus or not. Whilst it's most visible for CSDs headers, use of the active/inactive palette (or backdrop class in GTK terms) applies everywhere. Rationale of the flag is to allow the WM to hint visual states without giving input, i.e so you can hint that the parent of a modal dialog should be shown as active. Though kwin only sets it on the truly active window to match the behaviour our other windows follow. I expect this to be potentially controversial as it's new code in X11, so in advance: * Unlike GTK_FRAME_EXTENTS, it is part of the specificiation (albeit 1.4) even i3 supports it. * It does fix a real world issue * It's only 2 lines (plus trivial boiler plate in kwindowsystem) * It's in code path that we rely on for our existing code * If there's a situation where this does break, the worst that will happen is a client gets a visual hint to have focus incorrectly, which ultimately is the same as the current state Test Plan: Used my CSS for breeze-gtk moved between windows Reviewers: #kwin, rooty, zzag Reviewed By: #kwin, zzag Subscribers: zzag, ognarb, ngraham, rooty, graesslin, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D19613 M +1 -0 activation.cpp M +2 -1 netinfo.cpp https://commits.kde.org/kwin/ce1a5eae156a544da06a9a37ee00b6b55dd13bb3 |