There are two shapes that the WM needs to be concerned about: the input
shape and normal shape.
If the client window has custom input shape, the window manager should
synchronize it with all parent windows or ensure that its frame window
has an input shape as big as the client's input shape. The input shape
needs to be updated either when the client changes it or when the
X11Window is resized or its borders have changed. updateInputShape()
accomplishes that.
The normal shape is slightly different. If the window is decorated, the
window manager could ignore the shape set by the client. If the window
is not decorated, it's a good idea for the WM to synchronize client's
shape with the frame window's shape (if there's any). The frame window
shape doesn't need to be updated when it's resized, but if the client
window moves inside the frame window, it needs to be updated.
This change removes too generic updateShape() in the
X11Window::moveResize() code path and replaces it with a more targeted
code to update the shape, so updateServerGeometry() does not emit the
shapeChanged signal and it can be reused in the doInteractiveResizeSync()
function. Note that on wayland, it's unnecessary to synchronize the
shapes because the client window never moves in the frame window but it
is done anyway to minimize the differences between X and Wayland sessions
for easier maintenance.
Otherwise the window might still be referenced from the opening animation, which
can lead to the effect wrongly keeping a reference to the window and staying active.
CCBUG: 485425
This avoids doing multiple atomic tests with outdated state for when multiple
outputs change simultaneously, and avoids crashing because outputs get used
before they're fully constructed
(https://crash-reports.kde.org/organizations/kde/issues/40960)
Qt applications use Static window gravity by default. This means that if
a window decoration is created, the client window should remain at the same
position in the global coordinate space. To do that, X11Window needs to
move the frame geometry by (-borderLeft(), -borderTop()).
On the other hand, after making X11Window::framePosToClientPos() round
the window borders, the client window can end up being moved more than
expected when applying the gravity adjustment.
This change makes X11Window also round the gravity adjustment so the math
is consistent there and in the framePosToClientPos() function.
BUG: 489016
don't blindly access m_tileManagers as it can assert
with out of bounds when output is not valid. This can happen
from scripting side as this function is wrapped in the javascript api.
Adds whitespace between documented members of the header file.
Currently the members are all bunched together, making it difficult to
read as one flows directly into the next. This change adds a newline
between each member, making it easier to read.
The internal effects implement some of the core plasma functionality, for
example screenshots, but being an effect is rather an implementation detail.
Also we have pivoted towards unloading the desktop effects kcm and moving
effect configuration in more appropriate places.
BUG: 488988
This ensures that different content on the screen matches with the user configured
reference / SDR luminance, and both simplifies SDR<->HDR mapping by removing the need
for special casing that situation and significantly improves the mapping in some cases.
As we don't get any reference luminance values for HDR content (yet), this commit
assumes that HDR content is prepared for the reference luminance of the preferred
color description.
Brightness is a loose word for how bright we perceive things to be, but the
values we're using are about objective measurements, about luminance instead.
If a context is forward compatible, that means the deprecated functions are not
available, and if the QSurfaceFormat::DeprecatedFunctions option is set, that means
they are available.
Wrongly setting QSurfaceFormat::DeprecatedFunctions thus causes Qt to use OpenGL in
a way the context doesn't actually support.
CCBUG: 486460
If two mouse areas are stacked on top of each other and a button press
event is sent so one of them accepts it, QMouseEvent::isAccepted() will
still return false. It's a QtQuick bug, see the associated upstream bug
report https://bugreports.qt.io/browse/QTBUG-126733.
On the other hand, given that the MenuButton implements its own input
handling, we can port it away from DecorationButton to mitigate the issue.
BUG: 488993
The preedit struct holds values that need to be effectively double
buffered till the preedit string is set. There is no need to store the
text in this struct as it is reset at the end of setPreeditString
It's usefulness is doubtful, the current visuals poorly map to the
wayland abstractions, and it's partially incomplete because surface
previews are only shown for surfaces that have wl_shm buffers attached.
Tree hierarchy changes are also handled very poorly.
There are a couple of reasons why it's worthwhile doing:
The first is that it makes the logic in the updateServerGeometry()
function reusable for the interactive code path. As of now, when the
window is being interactively resized, doInteractiveResizeSync() will
issue some xcb_configure_window() calls but then it also implicitly
assumes that updateServerGeometry() will call updateShape() and
updateInputWindow() but skip m_frame.setGeometry() later. That is
confusing, and error prone. For example, if somebody drops
m_lastFrameGeometry in favor of m_frame.geometry() (which is an
absolutely reasonable thing to do btw!!), a regression will be
introduced: things would appear to work at first, but then eventually
bug reports about input working weirdly would start piling up.
The second is hidpi scaling of wayland clients. toXNative(a + b + c)
is not the same as toXNative(a) + toXNative(b) + toXNative(c). By
switching to the device geometry, we leave less space for making an
error.
The third is that lets us clean up some geometry manipulation code.
When dealing with window hierarchies, it's more convenient to have
m_window.position() rather than a dedicated property in the X11Window
class such as wrapperPos().
If the logical geometry changes, the X11Window still needs to verify
whether the currently applied native geometry differs from it. In order
to do that, the X11Window needs to map the logical geometry to the device
pixels. Given that X11Window already maps the logical pixels to the
device pixels, the Xcb::Window doesn't need to map the geometry again.
Also, the way different coordinate spaces are handled now is inconsistent.
Some things (Xcb::Window) work only with the logical pixels, while other
(e.g. client messages) require the user manually mapping the geometry
between the different coordinate spaces. With this change, it would be
more consistent.
Regarding the porting process, it was performed in a single step because
all the code that changes or reads Xcb::Window geometry is neatly
encapsulated in the X11Window class in a couple of functions.
The mastering display colorimetry describes what part of the colorspace
is actually used, which is important when we're sending desired metadata
about a screen using the rec.2020 container colorspace, or when the client
uses an "infinite" / extended colorspace like scRGB
