The X property _KDE_NET_WM_COLOR_SCHEME can be set on a window and
specifies the absolute path to a .color file describing the color
scheme of the managed client.
The Client reads this property and creates a QPalette from it. If
the property is not set or the value is incorrect, the Client uses
KWin's default palette.
The idea behind this property is to allow an application with a
custom color scheme to tell KWin which color scheme the window
decoration should use. So that the window looks as a solid pattern
again.
The QWidget of the window decoration is otherwise still thinking that
the button is pressed and waits for a release. Thus the next click on
the decoration doesn't trigger the move mode.
If the user actions menu is closed Qt looks for a QWidget at the mouse
position. If it finds one it tries to activate and raise it. If the
QWidget at the mouse position is a window decoration, it gets raised
above the Client. This makes the window unfortunately unusable.
To prevent this from happening we listen for the ZOrderChange event
in our event filter on the decoration widget and unconditionally lower
the decoration widget again - we never want the decoration widget to
be above our Client, so we can just always lower it. We have to use
the low level functionality and cannot use QWidget::lower as that would
result in a loop.
There is a check in Client::buttonReleaseEvent() for the state of the
mouse buttons compared to the button masks for button 1, 2, 3 (X11
button indices).
The check was:
if ((state & (Button1Mask & Button2Mask & Button3Mask)) == 0) { ... }
<=> if (state & 0 == 0) <=> if (true)
This change assumes what the check was supposed to be and fixes the problem. The correct fix was proposed by Thomas.
REVIEW: 113359
1. when adding a full damange, that must not replace existing (larger) repaints
2. emit geometryChanged before invoking and to update shadowGeometry through addRepaintFull
BUG: 324560
FIXED-IN: 4.11.2
During startup we only create the request, the reply will be fetched
once the atom is needed.
To make proper use of this async behavior the creation of Atoms is
moved directly to the claim of the manager selection, so they can be
fetched while we wait for the previous manager selection to give up
on it.
If the eventWindow is none the check for InputIdMatchPredicate will find
a matching Client and pass the even through the windowEvent filter which
returns true for all not handled events and thus filters out all events
processed later on in KWin.
This explains why some events were eaten...
Using a QTimer to move the resize/move related code to the end of the
event queue. In case there is another motion event in the queue it will
cancel the timer.
Instead of inspecting the XEvent queue we create a Timer with a
singleshot of 0 msec to move the setActive(false) call to the end of the
event handling. In case there is a matching FocusIn event this will be
handled before the timer fired and can cancel the timer.
the present check can break quick everything depending
on screen snapping settings.
It so far. only worked for quick maximization due to horizontal
"judder" and failed whenever that judder was not possible
(due to screen snapping on left and/or right edge)
BUG: 322852
FIXED-IN: 4.11
REVIEW: 111740
We get the missing send event attribute from anding the event's
response type with 0x80.
This fixes the issue that all open windows got unmapped. The reason for
this was that the existing new Client got reparented to the wrapper which
caused the UnmapNotify event which we used to release the Client and by
that unmapping the window completely.
Focus out handling used to check the event queue for a matching focus in
event to prevent short flickers when no window is active. This is not
possible with XCB and needs a replacement. Maybe a short timer event.
Interestingly the attribute send_event from XUnmapEvent does not exist in
xcb_unmap_notify_event_t and also the X protocol doesn't know anything
about send event.
