We need to send a fake HoverMove event on minimized to remove all
hovered states of the decoration.
At the same time we need to ensure that no further hover events are
sent to a minimized client.
BUG: 351984
FIXED-IN: 5.4.1
REVIEW: 124997
regardless of whether the pushback is forced down or the user
has deactivated it or whatever. The edge is waiting from previous
activation and we need to prevent immediate reactivation since that
may cause duplicate action and unwanted state toggles
BUG: 351627
CCBUG: 351869
FIXED-IN: 5.4.1
REVIEW: 124888
The test put a reference to the XCB::Window as data
to the _net_wm_transient property, not the window ID
This "works" (you get various garbage transients for
the leader in addition) as long as the window id itself
is the first item in the structure (because that is what
the test resolves to verify what it has done) bug fails
when the XCB::Window structure changes and anything
is the first item (or, btw., when the compiler feels
to re-align the structure and adds some padding...)
So let's fix the test by at least passing the proper
data reference.
is FIXED-IN: 5.4.1
REVIEW: 124888
also see REVIEW: 124864
I don't understand why, but this fixes the TestXcbWrapper::testTransientFor().
Failing code fragment in question:
Window transientWindow(createWindow());
transientWindow.changeProperty(XCB_ATOM_WM_TRANSIENT_FOR, XCB_ATOM_WINDOW, 32, 1, &m_testWindow);
// let's get another transient object
TransientFor realTransient(transientWindow);
QVERIFY(realTransient.getTransientFor(&compareWindow));
QCOMPARE(compareWindow, (xcb_window_t)m_testWindow);
the QCOMPARE failed with one compareWindow being 0. It looks like the
cast from Xcb::Window to xcb_window_t in the changeProperty failed.
REVIEW: 124864
not everytime the current screen changes.
a) that pollutes the geometry when the tabbox is invoked
b) it's insufficient for "Active Screen follows mouse" (the default)
c) less overhead (ok: "on multiscreen")
BUG: 337790
CCBUG: 341531
FIXED-IN: 5.4
REVIEW: 124814
the (old) button effect windows used to be unreferenced
with the re-invocation of the effect. because we stopped
deleting/recreating the window, this approach failed and
the effect window was never deleted.
Unreferencing the window at proper occasion (see new hide
location) coked up - guess what - the exact same "texture is
junk" issue as for the QtQuick close button in present windows...
So we resort to the exact same stupid "hide by moving" solution
as we have there.
BUG: 348577
FIXED-IN: 5.4
REVIEW: 124136
1. if a client has oversize, ensure to keep the titlebar in
sight
2. if a maximized client *almost* covers the entire maximization
area, users can easily be trapped to click into the missing
pixels, thus the client below.
Therfore the clients is then stuffed into one corner, with
preference to the titlebar edge and the screen area (ie.
*away* from panels and towards actual screen borders because
of fitt's law)
BUG: 349935
REVIEW: 124286
FIXED-IN: 5.4
Without the componentDisplayName the shortcut dialog takes the name of
the application e.g. Systemsettings or "KDE Control Module", but we want
it to be KWin.
REVIEW: 124706
Note:
The diff is completely misleading, because the latest docbook in kde 4 has <date>2014-03-10</date> + <releaseinfo>&kde; 4.11</releaseinfo>
but kwin master in kf5 has <date>2010-10-28</date> + <date>2015-07-24</date> <releaseinfo>&kde; 4.5</releaseinfo>
The diff against the latest kde4 docbook version 4.11 has only 4 or 5 lines
REVIEW:124475
Remove the outdated docbook
This KCM is now in Display and Monitor -> Compositor
Compositor is not for Joe User, only for workarounds with broken drivers as confirmed by Martin
X-DocPath now points to userbase
REVIEW:124436
So far if the new position fell outside of the screen, we ignored
the movement completely. This change only discards the event if both
x and y coordinates are outside the screen. If one component is still
on the screen it will be used. So a movement to top-left on left border
will result in a pointer movement towards top.
If we were on e.g. vt 1 and pressed Ctrl+Alt+F1 KWin broke as it
disabled rendering for vt switch and vt switched to vt 1, which
obviously failed.
So let's check whether it's going to switch to the vt we are already
on and ignore surch requests.
For the appId we use:
* wl_shell windowClass for Wayland clients
* resourceName from window class for X11 clients
This is implemented by sharing the window class implementation in
Toplevel.
CCMAIL: hein@kde.org
If the backend specifies
{
"input": false
}
in it's plugin metadata, it means that it does not handle input by
itself. In that case we can enforce libinput.
With this change one does no longer need to specify --libinput when
starting kwin_wayland on the drm or fbdev backend. So
kwin_wayland --xwayland
will bring up a fully functional kwin_wayland on drm platform.
Instead of setting our own filter rules we install a categories file
to allow to configure them. This seems to still have them enabled by
default, but should at least give distributions the possibility to
disable logging by default.
