GitLab

Differential Revision: https://phabricator.kde.org/D3987

REVIEW: 129748

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.

Missed to install the header file.

Regression with 1c6c2ee2 which removed a
needed source code line.

Thanks build.kde.org!

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

REVIEW: 129460

REVIEW: 129358

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.

We pass a qreal to the wl_fixed and for that need to wrap it in
wl_fixed_from_double.

Like in the factored method case, just for generic requests.

The code needed in a client global to create a client resource is pretty
much the same in all interfaces. Thus we can generate it.

* 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

Experience showed that in most cases we need the q pointer in the
resource private class on the client side.

Experience showed that most generated classes need a dedicated setup
method in the Private in order to add a listener.

Change was prepared prior to project name change. Sorry about breaking.

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

Summary:
/wrkdirs/usr/ports/x11/kf5-kwayland/work/kwayland-5.28.0/src/client/plasmawindowmanagement.cpp:489:25: error: use of undeclared identifier 'errno'
        if (n == -1 && (errno == EAGAIN) && ++retryCount < 1000) {
                        ^
/wrkdirs/usr/ports/x11/kf5-kwayland/work/kwayland-5.28.0/src/client/plasmawindowmanagement.cpp:489:34: error: use of undeclared identifier 'EAGAIN'
        if (n == -1 && (errno == EAGAIN) && ++retryCount < 1000) {
                                 ^

Reviewers: graesslin, bshah

Reviewed By: bshah

Subscribers: plasma-devel

Tags: #plasma_on_wayland

Differential Revision: https://phabricator.kde.org/D3289

project() sets more variables than I remembered

Fix-up for 1e6b20e3

kapidox makes use of that name, also is now consistent with other KF libs

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

Same as e2be6200 for the next test
method.

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.