before, hiding the buttons relied on the effect
seeing a paint event for the (with a low timeline
value) what's too wonky at least for instant animations
(certain failure) or when effect exits immediatey
(due to screen edge invocation issues or whatever)
BUG: 351869
FIXED-IN: 5.4.2
REVIEW: 124970
notably *after* storing the old values.
Otherwise the old value is polluted because of
m_hints being nullptr, thus a default value is
returned (instead of the actual old value)
BUG: 347818
FIXED-IN: 5.4.2
REVIEW: 125007
Theory:
----------
because PresentWindowsEffect::screenCountChanged() is shortcut
for "if (!isActive())", but the desktopgrid doesn't call
PresentWindowsEffect::setActive (or at least
PresentWindowsEffect::screenCountChanged), so the effect can
"miss" the increasing screen count change (it sees the signal,
but ignores it) and when desktopgrid calls it, it assumes the
m_gridSizes array is big enough (but it isn't)
Steps:
----------
1. effects are loaded, 1 screen present
2. 2nd screen gets added, but inactive effects ignore that
3. desktop grid gets activated, updates according to screen count,
calls presentwindows for screen #2
4. presentwindows data is only prepared for one screen from step 1
=> BOOM
BUG: 351724
CCBUG: 326032
FIXED-IN: 5.4.2
REVIEW: 124960
A quad might have a null size in case it has a null width or null height.
Not just one dimension.
BUG: 236353
BUG: 210467
FIXED-IN: 5.4.2
REVIEW: 125131
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
