The js code contains code such as
window.frameGeometry = {x: 42, y: 42, width: 100, height: 50};
However, QJSEngine doesn't know how to convert js object to QRect. For
that purpose, we need to register conversion functions.
So far, we kept registering converter functions only for integer based
geometry types, i.e. QRect, QSize and QPoint. In 5.26, Window was ported
to QRectF, QSizeF and QPointF, but the corresponding conversion helpers
were not added.
BUG: 459369
The desktopClient is a weak pointer and therefore can be null. This
makes sure that we are not calling a null instance of it.
It seems likely it was introduced here 45486ce515
This is a blind non-reproduced fix for the issue here:
https://errors-eval.kde.org/organizations/kde/issues/158/
Unlike D&D actions, this method does not return any feedback as to
whether an item drop was accepted by any other screen, and so whether it
is going through destruction process already, so the best we can do is
add another typeof/undefined check after calling that method.
Fixes the following error:
file:///usr/lib/qml/org/kde/kwin/private/effects/WindowHeapDelegate.qml:415:
TypeError: Cannot read property 'deleteDND' of undefined
DND was failing with the following error
file:///data/projects/usr/lib/qml/org/kde/kwin/private/effects/WindowHeap.qml:96: TypeError: Cannot read property 'mapToGlobal' of undefined
Change the render cycle for slide effect. Now, windows will be drawn on each desktop or not in the paintWindow() loop instead of the paintScreen() loop. This allows us to respect stacking order better by painting all of the same window together instead of per VD.
BUG: 457486
BUG: 458622
This special signal was designed to remove the need for such
bikesheddings and workarounds. Use it to react to user-driven changes.
BUG: 459202
FIXED-IN: 5.26
It is used in QML code, just like in windowview (Present Windows)
effect, but developers forgot to copy the implementation in C++
backend.
BUG: 459202
FIXED-IN: 5.26
Without window title being shown, background highlight should shrink as
well, otherwise it created a questionable gap at the bottom e.g. in a
Desktop Grid effect.
FIXED-IN: 5.26
Unfortunately, *Animator QML types have some problems with rendering,
sometimes affecting general smoothness, other times (like here, for me)
just not animating entirely. On my NVIDIA graphics system the animation
or a desktop returning from drag just looks like a freeze for a second,
then it suddenly jumps back to {0,0}. So let's just replace with less
optimal NumberAnimation which works fine.
FIXED-IN: 5.26
DragHandler does not travel along with its target heap, so it only
affects the cursor shape when the mouse pointer is directly over it; but
when a desktop is dragged far outside, the cursor resets.
Besides, this is how we already implemented it in WindowHeapDelegate.
FIXED-IN: 5.26
Use methods with semantic naming instead of raw data manipulation, and
make sure to perform clean up of DND data, so it won't haunt us back
later e.g. when a window delegate is recreated not because of a drag
of itself but due to a desktops rearrangement.
Because of const/non-const issues, iterator got invalidated in the loop,
which led to a crash.
Cases that trigger it: interaction with a thumbnail while the effect is
returning to initial state and shuts down. For example, slightly
dragging and releasing a thumbnail such that both TapHandler & DragHandler
would react and play each their own transition (yes, it's another bug);
or by pressing Escape key while dragging.
Having one state machine instead of two somehow simplifies the code and
makes it less fragile.
The new property `substate`, which replaces `thumbSource.state` still
supports imperative assignments that are so important for Drag&Drop,
and still triggers state updates. However, now a substate may not
become an active state: that behavior didn't make sense in previous
iterations, and has led to a glitch where a window won't resize during
return-to-initial animation. The glitch happened because two state
transitions were starting almost-simultaneously (and by Murphy's law in
the worst possible order, of course), and both animations were playing,
but one animation was supposed to to a property that is managed by the
other. But since QtQuick animations cache their from/to values before
they start, the dependent transition essentially didn't animate at all.
The Compositor is destroyed after the Workspace, so the placeholder has
shorter lifespan. We need to guard the destructor of EffectScreenImpl
from accessing a dangling pointer. For what it's worth, the destructor
of EffectScreenImpl was written with QPointer in mind, but it was never
added.
the existence of Window is bound to the one of workspace so it
will always be there.
We also need to check the window sizes before workspace is done
initializing,
otherwise when KWin restarts and there are maximized windows, they won't
be resized to take panels into account and will always span the full
screen.
Remember to release all resources before the wayland socket goes:
- release the seat as we give up a seat
- release the ssdManager
- release the output decoration with the output itself
Otherwise they leak and stay dangling.
When debugging something I realised that SIGTERM was always making KWin
crash like I'd never seen it crash. It turns out we are calling
QApplication::exit() on the signal handler which is highly forbidden as
the handler preempts the process altogether.
Use KSignalHandler instead which takes this issue into account.
Each screen has its own WindowHeap. So setting WindowHeap.activeClass
won't be visible on other screens.
In order to address that limitation, we could monitor
Workspace.activeClient property.
BUG: 455974
We use the PMF syntax so the isValid() check is unnecessary as the
compiler will notify about wrong signal at compile time. It makes
writing autotests feel less boilerplaty.
It adds more test cases in OutputChangesTest, particularly swapping
outputs.
Swapping outputs is an interesting case because outputs can temporarily
overlap so workspace()->outputAt() can return wrong output and the
window is going to stick to wrong output.
re-trigger the edge *only* if the user keeps the mouse still for at
least edges()->reActivationThreshold() - edges()->timeThreshold()
so that the user has to actually keep moving.
if the user keeps moving the cursor in the direction of the edge, it
wion't continuously retrigger it
BUG:457280
the Drag attached was set to active in a taphandler which didn't
accept touch, breaking drag and drop on wayland+touch
moving the logic on the other handler makes it work everywhere
