Summary:
For some windows we don't want to create a PlasmaWindow. Not all
ShellClients are something the outside world should see. This change
introduces the first restrictions:
* KWin internal windows are hidden
* transients not accepting focus are hidden
The latter case doesn't work though if the Surface is mapped prior
to creating the shell surface. In such a situation it's racy as KWin
handles the create surface request before we get the setTransient
request. This is difficult to handle as we do want to react quickly.
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1759
OpenGL/EGL doesn't work on build.kde.org. Because of that the
kscreenlocker_greet aborts on startup and we cannot really test whether
it works on build.kde.org. E.g. we never actually see the window.
This change just makes sure that QMLSCENE_DEVICE=softwarecontext is
passed to the greeter in the LockScreenTest. Hopefully that fixes it
on build.kde.org.
The new added test case verifies a few cases in which a PlasmaWindow
should or should not be created or destroyed.
Some cases are clearly wrong and are marked with expect_fail.
Summary:
Device is created from Connection::processEvents which is run in the
main gui thread, while Connection itself is in a different thread. Thus
passing *this* as parent is wrong.
This change removes the parent, moves the created Device into the
Connection thread and also deletes properly by using deleteLater.
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1746
This test mocks part of KWin::Udev, udev and libinput. The test itself
is still rather limited and only verifies whether libinput is valid or
not and that assignSeat works. Most of the interaction is not yet tested,
though to a large degree doesn't make sense and should be rather tested
in the context of LibInput::Connection.
We didn't check whether creating the QPlatfromInputContext worked and
accessed the m_inputContext unconditionally which obviously crashed.
Now the connects related to QInputMethods are not setup if we failed
to create the QPlatfromInputContext.
Reviewed-By: bshah
Summary:
The idea is to have KWin provide a virtual keyboard. To support this
KWin uses the QT_IM_MODULE qtvirtualkeyboard and makes sure that the
QPA plugin loads it.
KWin has a new class VirtualKeyboard which acts as the focus object and
the "proxy" for input methods. The QPA plugin ensures that this is the
focusObject, so that all input method related events are sent to this
class. From there it will be possible to delegate to other applications
through the Wayland interfaces.
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1638
The test case sets up apol's screen setup and the panel as described
in the attachements in bug 363804. As the test shows the panel's strut
is incorrectly ignored.
CCBUG: 363804
A signal is added to the VirtualBackend to change all screen geometries.
This can be used from auto tests to change the screens. But it's not yet
correctly reflected in other areas. E.g. not forwarded to Wayland Output,
etc.
It's currently failing on build.kde.org. I'm not able to reproduce the
failure localy so I can only interpret the failure. The failure looks
like a window is still present in the next executed test case thus
breaking the positioning.
This change ensures that the window is properly gone before going into
the next test case.
When KWin goes down the DecorationBridge might be destroyed before the
last AbstractClient is destroyed. Thus we should destroy the Decoration
when the DecorationBridge gets destroyed.
If we get a compositingToggled because the Compositor is going down we
don't need to recreate the Renderer as KWin as a whole is going down.
Thus we disconnect the compositingToggled connection when the Compositor
is about to be destroyed.
KWayland was changed: the ShellSurfaceInterface does no longer get
destroyed when the parent SurfaceInterface gets destroyed. For the
wl_shell_surface there is no dtor request in the interface so the
resource sticks around and also the ShellClient is kept.
This change ensures that the ShellClient also gets destroyed when
the Surface is destroyed. This should fix some broken tests.
Cherry-picked from master to fix failing tests on build.kde.org.
This new test includes everything used in events.cpp to the mocked
functionality of libinput. Only key event is implemented so far, the
referenced pointer and touch functions are mocked with default values.
The test verifies that a KeyEvent gets created and the key press/release
works as expected.
Summary:
Now that we have access to the actual LibInput Device from the event
handler, let's also print out which device received an event.
Test Plan: Manual testing whether the correct device is shown
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1668
Summary:
The signals emitted by LibInput::Connection carry the Device for which
the input event was received. This Device is passed to the input handlers.
Custom event classes are added which extend QMouseEvent, QKeyEvent and
QWheelEvent respectively and expose the Device. The Device is only passed
around as a forward declared pointer, so even if compiled without libinput
support, it should still compile.
Event handlers which need to get access to the Device can now just cast
the event pointer to the custom class and access it. This can be used in
future to handle device specific key codes, etc.
As we don't have a proper event classes for touch events the event
handlers do not yet have access to the Device. Here the internal API
needs to be adjusted in future.
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1667
Summary:
The Event class now holds a pointer to the Device and not only to the
native libinput_device.
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1666
This reverts commit abe582c27d.
To explain: the test uses a mocked implementation of libinput. Because
of that it must not link against libinput. The whole idea is to not link
libinput.
So I'm reverting the addition of libinput to linkage. I don't know the
build error, if it gets presented to me, I'll fix it properly without
having to add a linkage to libinput.
Summary:
When the pointer device gets plugged off the cursor is hidden, when
a pointer device gets plugged in the cursor is shown again.
This allows to easily turn a tablet into a proper system by showing
the cursor only when it makes sense.
Test Plan: Tested on exopc with external mouse
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1682
Summary:
Just because we have a power button, doesn't mean we have a keyboard.
So let's bind the seat keyboard to whether we have a proper keyboard.
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1681
Summary:
Device has a static QVector<Device*> into which each created Device
is added and provides a static method to match a libinput_device* to
the already created Device.
This can be used by the the libinput Event class wrapper to properly
reference the Device the event is for.
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1665
Summary: Similar to the already existing hasKeyboard, hasTouch and hasPointer.
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1671
Summary:
Qt's touch event API is rather difficult and complex to implement.
As none of KWin's internal windows supports multi-touch gestures yet,
this is going the easy route and just simulates a left mouse button
press. If in future need arises for touch gesture support on KWin's
internal windows, this can be added.
Test Plan: Tested on exopc with DebugConsole and auto test
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1661
It's currently failing on build.kde.org. I'm not able to reproduce the
failure localy so I can only interpret the failure. The failure looks
like a window is still present in the next executed test case thus
breaking the positioning.
This change ensures that the window is properly gone before going into
the next test case.
When KWin goes down the DecorationBridge might be destroyed before the
last AbstractClient is destroyed. Thus we should destroy the Decoration
when the DecorationBridge gets destroyed.
If we get a compositingToggled because the Compositor is going down we
don't need to recreate the Renderer as KWin as a whole is going down.
Thus we disconnect the compositingToggled connection when the Compositor
is about to be destroyed.
KWayland was changed: the ShellSurfaceInterface does no longer get
destroyed when the parent SurfaceInterface gets destroyed. For the
wl_shell_surface there is no dtor request in the interface so the
resource sticks around and also the ShellClient is kept.
This change ensures that the ShellClient also gets destroyed when
the Surface is destroyed. This should fix some broken tests.
Summary:
The usage of libinput is completely mocked. The test covers all the
constant properties read by Device.
There are some features which are not yet tested:
* alphaNumericKeyboard
* supportedButtons
* enabled
The setters for leftHanded and pointerAcceleration are also covered
including the variants where it can fail.
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1648
Summary:
Most likely the window is in the process of getting destroyed. In that
case the following destroy of the Surface is also going to destroy the
decoration.
This was causing an interesting effect with the QQuickRenderControl used
by Aurorae. When getting destroyed it ensures that all posted events get
processed. This includes the destroy of the Surface which entered
ShellClient::destroyClient which again destroyed the decoration. In other
words a recursive destroy which ended with wonderful crashers due to
double deletions.
If the window is not unmapped this might still cause problems: more
testing needed.
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1641
