We need to register data types such as QVector<KWin::VirtualDesktop *>
both for QML and JavaScript scripts.
If you have no JavaScript scripts enabled, those container types won't
be registered and QML will fail to read properties such as
Window.desktops, which can result in already visible windows animating
opacity from 0 to 1 when opening overview effect.
To fix that, register all accessible data types in scripting apis in
Scripting::init().
We want floating tiles to be activatable, but also dismiss the effect by
clicking on the whitespace.
The current solution doesn't work as a floating tile that is in turn
split will pull focus from the children meaning those tiles can't be deleted.
Rather than special casing and z-manipulation we can simplify everything
by moving tile dismissal to the root of the effect and appropariately
propagating the event.
BUG: 465740
there is no practical reason I can see for why this should be limited to
stderr only. we are not reading or otherwise consuming stdout, we should
just pass it on.
Context: If a display is removed, the corresponding TileManager is removed with it. This in turn removes every one of its Tiles with it, and when a Tile's destructor is called, it attempts to find a new replacement tile for any windows it was previously managing.
However, if the Tile is removed because its corresponding TileManager has been removed, this has the potential to cause a segfault in KWin, causing it to crash (I suspect a possible race condition? but not sure).
This MR correctly evacuates custom tiled windows & migrates quick tiled windows upon output removal.
BUG: 465522
Use input device specific apis to change the position of the cursor. The
main reason to do so is to break the assumption that Cursor position is
the same as pointer position, which I would like to rely on later to
merge tablet and pointer cursors.
dmabuf buffers have the origin in the top left corner, so a texture with
attached dmabuf must have y inverted.
By correctly specifying the y inverted flag, we could leverage existing
infrastructure in kwin to handle vertically mirrored textures and make
simpler some projection matrix code in screencasting.
Even though the names seem to match, QtWayland maps button values
to enum values in ascendung order (as it does on X11). The wrong
mapping is usually not a problem because we send the native button
events to clients. However when the Qt names or values are used
for communication between KWin and a client this leads to
misunderstandings.
BUG:465463
FIXED-IN:5.27.1
This isn't necessary with atomic modesetting, as moving and setting are
the same thing. With legacy though, if the cursor was hidden, moving it
with the layer visible does not automatically show it again, so that needs
to be done explicitly
BUG: 461181
This has the benefit of providing a saner default for the values
of `opacityActive` and `opacityInactive` rule properties, both
in the UI and when reading the config.
The side effect is the same we have when changing default values:
if someone would have set a rule with some opacity to 0%, it will
be read as 100% next time kwin starts.
In this case it is a small price, as it is always easier to change
it back when the windows are visible that restoring it when they're
not, specially if it wasn't voluntary.
Once upon a time, in a moment of acute stupidity, I accidentally created a window rule making all windows completely transparent. I meant to go for 0% transparency when really the slider said 0% opacity. And once you've made the very window to change this setting invisible, the only way to fix that mistake is to log into a TTY or different DE and find the config file to edit manually. Since I've since seen several KRedditors fall into the same trap:
Show a warning when active or inactive opacity is set to ~~<= 15%~~ < 25%.
PointerInterface is a "Server-managed multicasting resource". As in we
have one QObject, managed by the server, but internally it represents
multiple resources from various clients.
We cannot control the lifespan of those resources, they may persist long
after we stop having these capabilities on the seat.
If we delete our pointer object when we stop advertising a pointer
capability we have race conditions with clients calling release, or
potentially even having a seat_get_pointer in flight.
It's easier and safer just to have PointerInterface last as long as the
Seat. If we don't have a mouse no-one should try to bind, and even if
they did or remained bound long after we stop having a mouse it won't do
any harm as there are no mouse events to broadcast.
