After !5532 existing behavior in public scripting API was changed for maximized Windows.
Maximized Windows didn't have a tile on purpose.
This behaviour was changed, as after refactoring separate members for storing QuickTileMode in Window and tile itself were unified
Previously QuickTileMode::Maximize was only set in the Window itself in m_quickTileMode, while tile itself was removed (by setTile(nullptr)).
Current QuickTileMod for current Window isn't part of public scripting API, so it's okay to break it.
This restores compatability with scripts created for KWin 6.0.5 and earlier
BUG: 489463
Signed-off-by: Alik Aslanyan <inline0@pm.me>
This matches what we do without color management, and is more what users and app
developers expect. Going with linear blending before was mostly from it being more
"correct" / how physical blending of light works, but that doesn't really matter
when existing software expects it to behave differently.
BUG: 476868
CCBUG: 479755
Poll the screen cast scale from the source rather have code on top of
ScreenCastStream and ScreenCastSource that figures out by itself how the
cursor should be scaled. It ensures that the cursor size will be
consistent and it makes the ScreenCastStream initialization code simpler.
when creating a QDataStream object, if the file has not been successfully opened
before (file.open() fails), the created QDataStream object 'ds' may not function
properly. If you continue to perform the operation 'ds << icon;' in this case,
it may cause kwin to crash. Therefore, it is essential to ensure that the file
has been successfully opened before creating the QDataStream object.
Signed-off-by: likai <likai@kylinos.cn>
This makes direct scanout of SDR content on an HDR screen and vice versa possible,
as well as direct scanout while night color is active or the brightness isn't 100%.
This exposes the degamma->ctm->gamma pipeline as a drm color op, which can
be set to a generic color pipeline. The same code can later be adapted to
program the upcoming per-plane color pipeline properties.
This allows encapsulating color operations in a generic way, which can then be used in KMS or shaders.
The class automatically optimizes out unnecessary color operations like identity matrices, and
combines consecutive operations like
- matrix + matrix
- multiplier + multiplier
- matrix + multiplier
- EOTF + inverse EOTF
- relative EOTF + multiplier
to improve efficiency and make KMS offloading easier
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.
