Summary: client requests to toggle those states, to be used by libtaskmanager
Test Plan: setting keep above from the taskbar works
Reviewers: #plasma, hein, graesslin, #plasma_on_wayland
Reviewed By: #plasma, hein
Subscribers: graesslin, hein, plasma-devel, #frameworks
Tags: #frameworks, #plasma
Differential Revision: https://phabricator.kde.org/D5757
Summary: Verified it it send before the initial_state and adjust tests and docs accordingly
Test Plan: All unit tests pass
Reviewers: #plasma, graesslin
Reviewed By: #plasma, graesslin
Subscribers: graesslin, plasma-devel, #frameworks
Tags: #plasma_on_wayland, #frameworks
Differential Revision: https://phabricator.kde.org/D5887
Summary:
This patch adds a pid event to the plasma window management protocol. It
allows the compositor to tell allow a mapping between windows and processes.
Bumps the version number of the interface to 8 to indicate this.
Test Plan: autotest added, passed
Reviewers: #plasma, hein, graesslin
Reviewed By: #plasma, hein, graesslin
Subscribers: apol, davidedmundson, plasma-devel, #frameworks
Tags: #frameworks, #plasma_on_wayland
Differential Revision: https://phabricator.kde.org/D5747
Summary:
It's possible for the surface to be unbound when we send the leave
event; we've called Resource::unbind() of Surface, so the Surface has,
deleteLater called, but it's still a valid object, and the first check
passes.
We get in this situation because when a surface is destroyed, we're
handling text input from the same source event.
Sending a nullpointer is a protocol error, and wayland kindly closes the
connection.
This fixes my constant:
"Did the Wayland server die" error messages when running clients.
Test Plan:
Got errors after setting up qt virtual keyboard.
Had reproducible case.
Restarted kwin after this patch, now doesn't crash.
Reviewers: #plasma, graesslin
Subscribers: apol, graesslin, plasma-devel, #frameworks
Tags: #plasma_on_wayland, #frameworks
Differential Revision: https://phabricator.kde.org/D5712
Summary:
This extends the client side API to support creating popup ShellSurface
windows and the server side API to send out the popup_done request.
This is needed to properly support popup windows (e.g. context menus)
in KWin.
Reviewers: #plasma_on_wayland, #frameworks, #kwin
Subscribers: plasma-devel
Tags: #plasma_on_wayland, #frameworks
Differential Revision: https://phabricator.kde.org/D5174
The setRegion call allows a null region. This means nullptr is an
allowed value which can be passed to ConfinedPointer::setRegion and
LockedPointer::setRegion.
In that case we crash if we try to convert the Region into a wl_region.
Thus add proper nullptr check, just like in
PointerConstraints::lockPointer and ::confinePointer.
Auto test adjusted to cover the condition.
Summary:
The pointer constraints protocol is an unstable protocol and thus
the implementation follows the semantics of unstable protocols.
The protocol allows to create a constraint on the pointer - either a
lock or a confinement on a surface. Those are not activated at once, but
when the compositor actively grants it.
During lock no further pointer motion is emitted, during confinement the
pointer is kept in a certain area.
This implements T4451.
Reviewers: #plasma_on_wayland
Subscribers: plasma-devel
Tags: #plasma_on_wayland
Differential Revision: https://phabricator.kde.org/D3466
Summary:
In SeatInterface we need to get all PointerInterfaces related to a given
Surface (Client) and call a method on it. The implementation we had so
far went through all Pointers and put all PointerInterfaces into a new
temporary QVector. In most cases all we did then was iterating over the
returned vector.
Which means we created a temporary vector for nothing.
This change implements a kind of std::for_each with the constraints of
the previously used pointersForSurface which does the check that Surface
is not null and that the client matches. If a PointerInterface is found
for that, the passed in method is invoked on it.
Reviewers: #plasma_on_wayland
Subscribers: plasma-devel
Tags: #plasma_on_wayland
Differential Revision: https://phabricator.kde.org/D3295
With this change the generator is able to detect whether an interface
follows the unstable semantics. In that case the header file on server
side looks different. An enum needs to be generated containing the
interface version. Each of the generated classes has a new method
interfaceVersion returning that enum. The ctor of the class is protected
instead of private.
So far only the header side is adjusted. The implementation currently
generates not matching code.
* static void fooCallback definitions added to Private class
* static const foo_listener s_lister added to Private class
* Private::setup generates the foo_add_listner call
* implementation of s_listener added
* base implementation with a TODO marker added for the callbacks
Summary:
Pointer gestures are created for a pointer and there are two types of
gestures: swipe and pinch.
At a given time there can only be one active gesture. The implementation
in SeatInterface ensures that there can only be one active gesture.
Each gesture consists of a start event, 0 to multiple update events and
an end event. The end can also be a cancel. To better support this the
implementation doesn't follow the protocol and splits end and cancel
into dedicated methods in the server side and into dedicated signals in
the client side.
Reviewers: #plasma_on_wayland
Subscribers: plasma-devel
Tags: #plasma_on_wayland
Differential Revision: https://phabricator.kde.org/D3169
This is ancient code that is outright wrong most of the time and at best
just incredibly unnecessary.
It is also not present in the great majority of frameworks due to this.
Its wrongness comes from the fact that it hardcodes the installation path,
which breaks relocatability of the KF5 tree as it will always attempt to
find the include dir $PREFIX/KF5 (e.g. /usr/include/KF5), which may or may
not exist given that the tree was relocated.
Worse yet, in a cross-building scenario we maybe for example
build on ARM and install to /usr but for cross building take the entire ARM
tree and shift it into /arm/usr/. If we then crossbuild on that tree the
bogus include list in this framework will make sure that we always search
in /usr/include/KF5 and thus potentially load a !ARM header simply because
the relevant ARM header was not installed etc.. Similarly of course a
build in $HOME can pick up /usr/include/KF5 headers because the home ones
are missing, causing unexpected results.
This happens whenever the KDE_INSTALL_INCLUDEDIR_KF5 var is absolute, which
it usually is.
On top of all that the premise of the code in question is flawed. It seeks
to add $PREFIX/$KF5INCLUDES to the search paths (e.g. /usr/include/KF5).
This is unnecessary because the target itself is properly installed via
cmake's install(TARGETS ... EXPORT ...) function [1]. This function has
smart functionality built in which will add the passed INCLUDES destination
to the INTERFACE_INCLUDE_DIRECTORIES property of the targets (i.e. what
the useless code wants to do) [2].
So what happens is that we install the target to the
KF5 locations, which has "include/KF5" as INCLUDES location,
thus causing the correct path to be added to the includes list of the
Targets.cmake file.
In particular thanks to more internal magic in cmake it will do so with
automatically resolved root paths such that the installed tree is
relocatable and able to relatively find the other KF5/* headers. So it
does what the code in question wants to do, just correctly.
Since cmake automatically takes care of injecting $prefix/include/KF5 we
can simply get rid of the wrong custom inejection code. This makes the
generated cmake file find the correct include/KF5/ directory and stops it
from always expecting a /usr/include/KF5/ directory to be present.
[1] https://cmake.org/cmake/help/v3.0/command/install.html
[2] https://cmake.org/cmake/help/v3.0/command/install.html
> The INCLUDES DESTINATION specifies a list of directories which will be
> added to the INTERFACE_INCLUDE_DIRECTORIES target property of the
> <targets> when exported by the install(EXPORT) command.
REVIEW: 129273
CHANGELOG: Improved relocatability of CMake export
The test destroyed the connection prior to destroying registry and event
queue. Thus causing problems. Hopefully this change fixes the segfault
on build.kde.org.
The test has KWayland::Client objects like Registry as member variables
of the test object. This causes the objects to be destroyed with the
dtor after cleanupTestCase is run which destroys the connection and
Wayland server. At least on the CI system this seems to cause problem.
In general our tests do not keep any state around, especially not
KWayland::Client objects. The normal way is to have a new dedicated
client connection for every test method. This test doesn't follow this
approach at all.
In case that this change does not fix the test and still crashes on
build.kde.org the only option is to drop the test and replace it by a
new variant which follows the approach of other tests.
Reorder the cleanup code. It doesn't make sense to delete the client
side objects after deleting the server side objects. This might be a
reason for the failing tests on build.kde.org.
Summary:
In case the current selection does not have a DataSourceInterface
updating the focused keyboard surface resulted in a crash. The current
selection is sent to the DataDeviceInterface of the newly focused
client and thus a DataOfferInterface would be created for a null
DataSourceInterface.
This is a similar fix as D3148 and D3149.
Test Plan: Test case added which used to crash before
Reviewers: #plasma_on_wayland
Subscribers: plasma-devel
Tags: #plasma_on_wayland
Differential Revision: https://phabricator.kde.org/D3150
Summary:
This is a similar condition as D3148. If a DataDeviceInterface is
created for the currently focused keyboard Surface the current selection
is sent to the new DataDeviceInterface. If the current selection does
not have a DataSourceInterface a DataOfferInterface for a null
DataSourceInterface would be created and result in a crash.
This change verifies that there is a DataSourcInterface on the current
selection prior to sending out the selection.
Test Plan:
A test case is added which simulates the condition by
using two clients.
Reviewers: #plasma_on_wayland
Subscribers: plasma-devel
Tags: #plasma_on_wayland
Differential Revision: https://phabricator.kde.org/D3149
Summary:
SeatInterface provides a way to set the current selection. This method
did not verify whether the new DataDeviceInterface actually has a
DataSourceInterface. If there is no DataSourceInterface on that
DataDeviceInterface the selection should not be sent to the current
selection owner. This results in a crash as DataOfferInterface
(correctly) doesn't expect the passed in DataSourceInterface to be null.
To ensure we don't hit this again the DataOfferInterface ctor gained an
Q_ASSERT to validate the DataSourceInterface.
Reviewers: #plasma_on_wayland
Subscribers: plasma-devel
Tags: #plasma_on_wayland
Differential Revision: https://phabricator.kde.org/D3148
The generator misdetected the destructor Requests by looking at the
arguments instead of the type of the request.
In addition the destructor handling changed in KWayland::Server since
the generator got created. There is now a shared implementation for the
Resource destruction. The generator is adjusted to generate the code for
that and implements the destruction for the Global resource destruction.
Summary:
By default a panel does not take focus. But there are panels which
should get keyboard focus. Examples in a Plasma session are the widget
explorer.
This change adds a new request to PlasmaShell interface to specify
whether a panel should get focus. The compositor can use this request to
decide whether to pass focus to a panel.
Reviewers: #plasma_on_wayland
Subscribers: plasma-devel
Tags: #plasma_on_wayland
Differential Revision: https://phabricator.kde.org/D3035
Summary:
This change adds support for auto-hiding panels. A PlasmaShellSurface
with Role Panel and PanelBehavior AutoHide can request to get
auto-hidden at a screen edge. The compositor will then not show the
surface although it is still mapped and will show it again once the
screen edge gets triggered.
The interface is extended by one new request to allow the client to
request the hiding of the surface. In addition two events are added to
inform the client when the surface got hidden and when it got shown
again.
Reviewers: #plasma_on_wayland
Subscribers: plasma-devel
Tags: #plasma_on_wayland
Differential Revision: https://phabricator.kde.org/D3007
Summary:
Especially for Xwayland windows the compositor might not have a themed
icon name. Resulting in a task manager not having dedicated icons for
Xwayland windows.
This change deprecates the way how a compositor is supposed to set the
window icon. Instead of passing the themed icon name, it is now supposed to
pass the QIcon. In case it's a themed icon the existing way to pass to
the client is used.
Otherwise a new event is used to inform the client that there is an icon
- no data is transmitted at this point. The client can then create a
file descriptor and pass it to the compositor. The compositor serializes
the icon into the file descriptor and the client can read from it. This
all happens transparently on client side there is no api change at all.
The writing and reading of the icon is done in a thread. Due to that
Qt5::Concurrent is now a required dependency instead of an optional
dependency.
Reviewers: #plasma_on_wayland, hein
Subscribers: plasma-devel
Tags: #plasma_on_wayland
Differential Revision: https://phabricator.kde.org/D3049
Summary:
Qt supports setting generic data on a QWindow. This change implements
the callback properly and forwards the property to the surface extension
instance. This allows the compositor to e.g. listen to
DynamicPropertyChangeEvents and get access to all additional set
properties.
Reviewers: #plasma_on_wayland
Subscribers: plasma-devel
Tags: #plasma_on_wayland
Differential Revision: https://phabricator.kde.org/D3045
Summary:
This is similar to what already exists for Surface. With this methods
it's possible to get a ShellSurface from an existing QWindow and to
perform low level native calls directly for the ShellSurface.
Similar calls will also be needed for XdgShellSurface, though the
xdg_shell_surface is not yet available through the native interface.
Test Plan: Used in breeze to trigger window moving
Reviewers: #plasma_on_wayland
Subscribers: plasma-devel
Tags: #plasma_on_wayland
Differential Revision: https://phabricator.kde.org/D3018
Summary:
This is what Weston does. With this change clients can create
multiple wl_pointer instances and thus get events reported to all of them.
This will be needed to e.g. support drag on empty area in Breeze on Wayland.
A similar change was done for wl_keyboard already in 25dbc84d.
Test Plan: Seat auto test still passes
Reviewers: #plasma_on_wayland
Subscribers: plasma-devel
Tags: #plasma_on_wayland
Differential Revision: https://phabricator.kde.org/D3016
Summary:
In the situation that a wl_client gets destroyed while still
wl_resources are around it can happen that one of them calls into the
ClientConnection during the cleanup handling which gets triggered at the
same time. This can then trigger a crash.
This change uses deleteLater for the ClientConnection and sets the hold
wl_client pointer to null instead of deleting directly. So the
ClientConnection is still around while the Resources gets cleaned up.
This is similar to the cleanup of Resource where on unbind the
wl_resource pointer is set to null and the Resource gets delete later.
BUG: 370232
FIXED-IN: 5.28
Reviewers: #plasma, bshah
Subscribers: plasma-devel
Tags: #plasma_on_wayland
Differential Revision: https://phabricator.kde.org/D3004
Summary:
This change implements the zwp_relative_pointer_v1 protocol which allows
to send relative motion events.
The (unstable) protocol consists of a RelativePointerManager which
creates RelativePointers for a given Pointer. This interface currently
only has one event to report the relative motion. It carries the delta,
the non-accelerated-delta and a timestamp in microsends granularity.
On the server side the implementation is mostly internal. Once a
RelativePointerManagerInterface is created one can send relative motion
events through the SeatInterface. The SeatInterface takes care of
sending it to the responding RelativePointerInterface. The protocol does
not restrict the sending of "normal" and relative motion events. Thus it
can be combined in any way one wants. This allows to have a rather
simple implementation. A user of the SeatInterface can just start to
feed the relative motion events (if the information is available) to the
SeatInterface together with the pointer events.
On client side a new RelativePointerManager and RelativePointer class
are added. The RelativePointerManager creates the RelativePointer for a
given Pointer. The event sent to RelativePointer is transformed in a
normal signal.
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma_on_wayland
Differential Revision: https://phabricator.kde.org/D2978