Summary:
implement virtual desktop support for Wayland.
use the new virtual desktop protocol from D12820
The VirtualDesktopManager class needed some big change in order
to accomodate it, which is where most changes are.
Other than that, it's mostly connections to wire up
VirtualDesktopsManager and VirtualDesktopsManagement(the wayland protocol impl)
Depends on D12820
Other notable detail, is the client visibility updated to reflect the presence
of the client in the plasmavirtualdesktop.
(and the unSetDesktop concept)
Test Plan: used a bit a plasma session together with D12820, D13748 and D13746
Reviewers: #plasma, #kwin, graesslin, davidedmundson
Reviewed By: #plasma, #kwin, davidedmundson
Subscribers: hein, zzag, davidedmundson, kwin
Tags: #kwin
Maniphest Tasks: T4457
Differential Revision: https://phabricator.kde.org/D13887
Summary:
This call is added for the window rules kcm which has a detect
functionality. As that detect functionality cannot query any Wayland
windows we need to have some functionality in KWin core. Furthermore
this allows to simplify the code in the kcm as all the custom X11
interaction can be removed. KWin internally has the functionality to
find a window at a given position.
From a security perspective adding this dbus method is fine as the user
stays in control of the functionality. It requires active click to
select a window.
The new dbus call is already used in the rules kcm replacing the
X11 based detect functionality. That a detect is now able to get
information for both X11 and Wayland windows. So far only X11 windows
on X11 were supported. So this fills an important gap in the Wayland
offerings. It should now be possible to create rules for Wayland
windows (though may not be fully functional).
Test Plan: Run the kwin_rules_dialog and it detected the window correctly
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D10490
Summary:
On Wayland compositing is required. It doesn't make any sense to offer
the user to disable the compositor or to allow windows to block
compositing.
The Compositor DBus interface gains a new property whether the platform
requires compositing. This is queried by the compositing kcm and based
on that the two mentioned options get hidden and not stored to config
file.
Test Plan: Opened the KCM on Wayland
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2586
Summary:
The idea behind the debugging console is to have a feature comparable
to xprop and xwininfo just for Wayland. We cannot have command line
utils as that violates the security restrictions, thus it needs to be
exposed directly in KWin.
The debugging console is invoked through DBus:
qdbus org.kde.KWin /KWin showDebugConsole
This opens a window with a tree view. The DebugConsoleModel which is
used by the tree view groups all windows into four categories:
* x11 clients (that is Workspace::clientList() and Workspace::desktopList())
* x11 unmanaged (Workspace::unmanagedList())
* wayland shell clients (WaylandServer::clients())
* wayland internal clients (KWin's own QWindows - WaylandServer::internalClients())
Each window is a child to one of the four categories. Each window itself
has all it's QProperties exposed as children.
This allows to properly inspect KWin's internal knowledge for windows and
should make it easier to investigate problems. E.g. what's a window's
geometry, what's it's window type and so on.
The debugging console is intended as a developer tool and not expected to
be used by users. That's why it's invokation is rather hidden. Due to
the fact that it's internal to KWin it results in:
* no window decoration
* stealing keyboard focus
* no way to resize, close, move from KWin side
* rendered above all other windows
There is a dedicated close button to get rid of it again. While the
console is shown it's hardly possible to interact with the system in
a normal way anymore. This is something which might be improved in
future.
At the moment the model is able to update when windows are added/removed,
but not yet when a property changes. Due to the lack of interaction with
the existing system, that's not a high priority at the moment, but can
be added in future.
Reviewers: #plasma
Differential Revision: https://phabricator.kde.org/D1146
KWin sets a _ORG_KDE_KWIN_DBUS_SERVICE property on the root window
with the name of the DBus service it registered. The type of the
property is UTF8_STRING.
REVIEW: 122215
Similar to the already existing DBusInterface wrapper for the
org.kde.KWin interface a new CompositorDBusInterface is introduced for
org.kde.kwin.Compositing.
That way the DBus interface is split from the implementation and DBus
specific methods are no longer required in the Compositor class.
The deprecated DBus methods
* toggleCompositing(bool)
* setCompositing(bool)
are removed.
REVIEW: 118463
The hack used to be used to hide windows before they get embedded into
another window. This has been wrong on multiple levels:
1. it does not belong into a window manager - the window should take care
of this by itself
2. Window title is not a proper way to identify windows
3. Using D-Bus to inform an X11 window manager about windows which should
not get managed is rather strange
4. The hack only works with KWin, but not with any other X Window Manager
5. Windows identified with this hack still appear in Alt+Tab, that is
they are managed after all. Only a flicker is suppressed
6. Such windows are shown in the taskbar which nicely illustrates how
wrong a D-Bus call to the window manager is
That the hack has been introduced for Java Applets in KHTML also shows
that this is wrong. Why does Gecko and WebKit not need such a hack? Why
is KHTML tied so closely to X11 and KWin? Having a hack for a technology
which is obsoleted (Java Applets) and shouldn't be used due to security
issues is another reason to no longer support this hack. This usage has
been removed from KHTML as of 67939b1 of kdelibs git repo.
REVIEW: 109450
It is not used anywhere inside KWin at all and the DBus method is not
used anywhere inside KDE's repositories (according to lxr). Because of
that marked as deprecated and going to die with Qt 5.
REVIEW: 107406
Two new interfaces are introduced:
* org.kde.kwin.Compositing
* org.kde.kwin.Effects
The Compositing interface is generated from scriptable elements on the
KWin::Compositor class and the Compositor is exported as /Compositor.
It provides the general Compositing related D-Bus methods like whether
the compositor is active and toggling and so on.
The Effects interface is generated from scriptable elements on the
KWin::EffectsHandlerImpl class and the instance is exported as /Effects.
It provides all the effects related D-Bus methods like loading an effect
or the list of all effects.
This removes the need to have all these methods provided on the global
org.kde.KWin interface. For backwards compatibility they are kept, but
no longer provided by the Workspace class. Instead a new DBusInterface
is generated which wrapps the calls and delegates it to one of our three
related Singleton objects:
* Workspace
* Compositor
* EffectsHandlerImpl
