So far we manually updated the toggled state depending on the button
type and the corresponding client property. This had an error sneaked
in for onAllDesktops: it was bound to desktop change instead of on all
desktop change causing the button to not reflect the state correctly.
To prevent such errors it's now setup to a property binding to the
client's state directly.
BUG: 354702
FIXED-IN: 5.4.3
REVIEW: 125917
A check for whether the button is the maximize/restore button was still
for the old syntax causing always the maximize button and never the
restore to show.
BUG: 354702
FIXED-IN: 5.4.3
a) When a group-transient is modal, it still needs to be
on the current or all virtual desktops if *any* of the
blocked clients is
BUG: 354090
FIXED-IN: 5.5
b) ignore demanded virtual desktop for transients. Notably modal transients
should appear where their parent is, and not drag that around. All others
also better show up above their parent and not a distant virtual desktop
REVIEW: 125758
Apparently it's not allowed to set root context properties multiple
times. If one goes to systemsettings, opens effects kcm, closes it
and opens it again it crashes due to setting a context property with
same name again.
This change eliminates the need for the context property by modifying
the property of the QML objects directly.
BUG: 354164
BUG: 351763
FIXED-IN: 5.4.3
REVIEW: 125737
Our decoration is deleted using deleteLater() and that might cause access
to the bridge. Given that we also need to deleteLater() the
PreviewBridge.
To do so the PreviewBridge is no longer directly exposed to QML, but
in a wrapper object which holds the bridge as only element.
BUG: 344278
FIXED-IN: 5.4.3
REVIEW: 125724
Discovered by ASAN on the CI system causing the
TestClientMachine::hostName(ostname) to fail since it's enabled.
What happened is that the QByteArray returned by getHostName() gets
destroyed in the main thread but accessed in the resolve thread. This
is changed by calling getHostName in the resolve thread.
REVIEW: 125458
commit c6bd68d78a2e00ce094a4087c106aaf4067f9f57 fixed a bug
that allowed early invocation when pushback was forced down.
However, it also turned activation and re-activation time
additive again (ie. invocation could only happen after
r+a ms instead of after r ms)
see also REVIEW 124888
REVIEW: 125143
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
