If the platform does not support configuring outputs, applying a config
must fail. However, almost all output backends support output
configuring except, perhaps, the x11 backend, but that case doesn't
matter.
Since both output-management-v2 protocol implementation and the rest of
kwin live in the same place and the fact that kde-output-management-v2
is very plasma specific, we can move Platform::requestOutputsChange() to
the implementation of kde-output-management-v2 protocol, it simplifies
the code a bit and improve code encapsulation.
In order to further simplify kde-output-management-v2 protocol, this
change alters the behavior of the protocol so an output configuration
can be applied only once, which is a very reasonable behavior.
It can happen that the window is resized after makeCurrent() and before
swapBuffers(). In that case, context()->makeCurrent() will re-create the
fbo and qpa will present an uninitialize fbo.
Assume that there's current context when swapBuffers() is called. Other
QPA already do this, for example, QtWayland. This would make the
behavior of our qpa consistent with QtWayland and fix resizing the fbo
in swapBuffers().
In general, kwin should be able to handle size mismatch between the fbo
and QWindow, but as an extra hardening measure, we could forbid resizing
windows during rendering, this can be done later though.
It implicitly already is not copyable, due to the unique_ptr member.
However, Qt6 moc code isn't realizing that and fails to compile the
DrmPlane Q_GADGET sub-class of this.
Buffers with implicit modifiers from another GPU must not be imported, as
the layouts may not be compatible.
For buffers with incompatible modifiers, direct scanout can also be rejected
early, saving some computational power.
BUG: 457851
This makes the behavior of virtual and x11 backend consistent
with the drm and the wayland backend and reduces the number of users of
the Platform::outputEnabled signal.
This allows it to be used from QML KWin Script or via property() C++
call.
This is useful to be able to use client area function with pointers
API without falling back to VirtualDesktop X11 ids from scripts.
We don't need to wait until the window is ready for painting in order to
create a plasma window, in fact, quite the opposite is desired. It's
better if the plasma window is created in manage() so the task manager
displays the corresponding item even if the window is not showing up for
whatever reason.
Accept drop events correctly and use returned value (action) of
Drag.drop() to guard against the situation where the delegate is about
to be destroyed.
This does not fix any bugs per se, except suppressing a warning about
undefined targetScreen being printed to a console on every window dropped
onto a different virtual desktop.
This commit doubles the animation durations for WindowHeap-based effects
(Overview, Present Windows, and Desktop Grid) and uses the OutCubic easing
curve for their opening and closing animations. This makes them feel smoother
and more comfortable.
BUG: 455521
BUG: 448538
FIXED-IN: 5.26
Due to this bug color picker used to not only select one pixel higher
than it should (which is quite negligible), but also returned garbage
value for the topmost row of pixels (when you push the cursor against
the top edge of the screen).
FIXED-IN: 5.24.7, 5.25.5, 5.26
Conky monitor's floating popup is of type desktop, too, and when it
gets picked over Plasma's desktop window, visual artifacts can be
observed behind e.g. the overview effect.
At the moment, an Xwayland window can be marked ready for painting even
though the corresponding wl_surface is missing. If that happens,
Window::setupWindowManagement() will fail to create a plasma window and
the task manager won't display the corresponding item.
As a short-term solution, remove the surface() check. It's not really
needed after all. For example, if it takes too long to start an app or
it doesn't show up at all, we still want to see a task manager item.
In long-term, kwin probably needs to take into account both xsync and
whether wl_surface has been associated, which is more complex.
BUG: 444325
We animated from 1.0 to 0.0, however this does not take into account
that a previous effect may also have adjusted the opacity.
We should multiply accordingly.
