A ShellClient can have window type dock. In that case it's considered to
have a strut. That is currently every panel restricts the area. On the
other hand only internal clients can be docks at the moment. For Plasma's
panels a dedicated interface will be needed.
At the same time the functionality for the "original_skip_taskbar" is
splitted out. This removes the weird API with two boolean arguments to
the set method. Instead there is a dedicated method for the orignal
skip taskbar state which delegates to regular skipTaksbar.
If there is a visible internal window it gets the pointer events.
The assumption is that the last created internal window is the top
most in stacking order.
We don't need to queue the method invokation any more to ensure the
Wayland server connection is flushed since we have the dispatch method
in waylandServer().
So far input events were sent through Xwayland which is not needed as
we have all information available. Even more it had the pointer surface
on the wrong window when interacting with decorations as it was on the
window and not on the decoration.
We need XCB 1.10 for sync to work. Sync was optional with a version check
to make it work on build.kde.org. The CI system supports XCB 1.10 now, so
it's better to have it as a mandatory requirement.
When switching virtual terminals,
suspending to ram and resizing the
screen (GL viewport) at least the
nvidia driver moves VBO data between
the video RAM and the system heap -
and something about this isn't reliable:
An often perceived resulted are scattered
windows but it may also be the cause for
entirely black screens reported for same
occasions.
As a workaround, we hook into the GL debug
messages and filter them for the suspicious
message, then re-init VBOs
TODO:
figure whether that's our fault or nvidias
REVIEW: 123936
CCBUG: 344326
Patch applies to KWin 5.4
which is invoked "in place" of the detect button
when calling the kcm as special window/application
setting from the Alt+F3 menu
BUG: 348472
REVIEW: 123953
this probably makes sense since it won't
have major impact on the workspace like
switching the VD or entering
presentwindows/desktopgrid would
REVIEW: 123904
a) close to pointless
b) the target resolution texture is invalid if the resize effect is enabled (as the window was not actually resized)
REVIEW: 123901
KActivities API is not synchronous anymore. If we want to retrieve
the activities, we should do it when we actually get the data.
We are listening to the service status changes and activity list changes.
REVIEW: 123869
BUG: 347732
When minimizing an Xwayland client the Xwayland server destroys the
Surface causing our next access to the Surface to crash KWin. So for
safety we connect to the destroyed signal and reset the pointer.
The disadvantage is that a minimized Xwayland window doesn't have a
preview any more.
We need to set the depth in order to properly determine whether the
Surface has an alpha channel and whether blending needs to be enabled
for rendering.
For this a new method is introduced in Toplevel to set the depth. If
the depth changed in a way that the Toplevel gained or lost the alpha
channel a signal is emitted which implies that the hasAlpha property of
Toplevel is no longer constant.
When creating a new xkb keymap we need to pass it to the Wayland server's
seat. As the Wayland protocol expects the keymap as a file descriptor, a
temporary file is created, mmapped and the keymap written into it. As
the Wayland protocol doesn't restrict how long the file descriptor needs
to be valid we keep any created temporary file around till the
InputRedirection gets destroyed.
Fixes regression introduced with 90a6814: we may not queue a signal
taking a pointer to a ShellClient as the ShellClient might be destroyed
before the queued signal is delivered.
The idea for the queued signal was to ensure that the size is set when
windowShown is emitted - this can also be achieved by first updating the
size.
When a ShellClient is added and it's not internal, it get placed just
like any other Client. This needs to happen after the initial size is
determined.
Please note: this breaks the positioning of popup windows (e.g. menus)
as they are placed like any other Client. This needs proper popup support
which right now does not yet exist and thus is not much difference to
before.
Martin Gräßlin