This removes the "OpenGLIsUnsafe" flag and replaces it with a timestamp
that we can check to see how long ago we tried enabling compositing, so
we can retry it if a certain amount of time has elapsed.
BUG: 452344
The drm fd can get stuck in readable state, in which case the
QSocketNotifier will fire the activated signal as often as it can
leading to high cpu usage.
We need to read() the drm fd in order to make the socket notifier stop
firing QSocketNotifier::activated.
This change removes the m_platform->isActive() check to ensure that
drmHandleEvent() gets called, in general, it should be safe as we only
notify the outputs about completed pageflips.
BUG: 452726
With this change, when the specified output is disconnected, it will
just behave as if none were selected but when it's connected again it
will pick it back up.
BUG: 456857
QRect.contains(somePointF.toPoint()) will round the values.
This is problematic for the case of a mouse being at -0.4, we will
consider it in bounds for the screen, but obviously this doesn't match
any surfaces.
The detection and confineToBoundingBox need to behave the same and
floor.
BUG: 459328
Instead of InputMethod directly calling showClient() on the input panel,
call methods that properly show or hide the panel as needed, with readyForPainting
set appropriately. This removes the cases where it's shown without being ready for
painting, which causes crashes.
BUG: 459404
This makes kwin's behavior consistent with other wayland compositors
(sway, GNOME Shell, etc) and it's reasonable to provide all the
information about the data source before wl_data_device.enter. It also
makes Firefox happier.
Relevant discussion upstream: https://gitlab.freedesktop.org/wayland/wayland/-/issues/322
CCBUG: 445661
Window rules code can call maximize(requestedMaximizeMode()), in which
case the Window will emit clientMaximizedStateAboutToChange but the
maximize mode may not actually change.
This change moves the emission of of the clientMaximizedStateAboutToChange
signal to Window::changeMaximize(). The reason for doing so is that
window rules have the final decision what the maximize mode will be.
CCBUG: 459301
The last fix was not complete without registering the shortcut from the
start. It worked after changing it in system settings at runtime though.
Amends 984388dba4.
This may happen when all windows are minimized, and the effect was
started in "Window class on current desktop" mode (Ctrl+F7).
BUG: 459244
FIXED-IN: 5.26
KQuickAddons::ConfigModule sets the translation domain based on the plugin id
That is kcm_kwin_scripts. However the translation domain is kcm-kwin-scripts, which breaks loading translations
Also fix Messages.sh to extract from QML
BUG: 458438
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.
