The dialog only had a "Close" button but the text was only transfered in accepted()
Also fix the position of the QDialogButtonBox which is swapped and so the buttons appear at the top.
BUG: 360521
FIXED-IN: 5.6.1
Differential Revision: https://phabricator.kde.org/D1173
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
Summary:
Mostly intended for plugins loaded into KWin and wanting to use
KWayland::Client::ConnectionThread::roundtrip(). By providing this
function we can ensure that KWin does not block and nevertheless
perform the required roundtrip.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1153
On special request by sebas. It's not really dangerous as by default
the xkb layout doesn't have it enabled. So if a user actually enables
it, we can also support it.
And now I'm going to reconfigure my layout again to not hit it by chance.
Reviewed-By: sebas
This patch implements read access to the outputmanagement interface in
kwin_wayland's drm backend.
- outputdevices are created in DrmOutput, just like the wl_outputs
- wayland_server implements the outputmanagement interface and
- passes the changesets down into the backend
This means that the interface is announced, independently of the DRM
backend, but the actual outputs are currently only there if the DRM
backend is used.
The changes are not applied (passed into the kernel's drm interface
yet). This is obviously work-in-progress, so it's incomplete. Since it
allows us to run kwin[master] with the libkscreen KWayland backend, it's
a significant step allowing testing and further development.
Reviewed-by: Martin Gräßlin
Qt has problems initializing everything correctly if there is no screen
at startup. E.g. the breeze widget style tries to initialize some pixmaps
and this fails. In worst case hitting asserts in Qt (debug build).
This change creates a dummy screen which gets destroyed as soon as there
is a real screen.
Reviewed-By: notmart and sebas
using stack adresses makes it possible (even tough not frequent)
for two animations (onle just killed, one just created) to have
the same id, causing scripts to be potentially really confused.
this replaces the id with a global counter, and the
"flying tooltips" bug is gone.
REVIEW:127276
BUG:360068
CCBUG:352254
The damage event of the Surface does not consider the offset through
the server side decoration. Due to that we need to have a different
repaint and damage area. As Toplevel::addDamage(QRegion) is only used
in the Wayland case the repaint adjustment is removed from the generic
implementation and moved into the specific implementations. While it
wouldn't hurt to have the repaint adjustment in Toplevel, it would
trigger a repaint of an unchanged area.
For Client I'm not sure whether it's correct without considering the
clientPos. My testing shows it's working, but that might also just be
do to Xwayland using OpenGL buffers. Needs further testing.
We want TabBox to operate on key press, not on key release. So far
it only operated on release as the press was filtered out by the
global shortcuts filter. To prevent that the tab box filter is moved
before the global shortcuts filter.
Note: first usage of TabBox has current window selected instead of
next. This problem is also visible on X11.
The TabBox implements methods for those events and performs same
logic as on X11. Click outside of TabBox closes. If the event is on
the TabBox we don't filter the event out and let the internal filter
forward the event.
A QEvent* is passed around, this could also be a QWheelEvent. Only
present windows static casted, all other effects verified.
Documentation is not existing, so we don't know what was intended.
By using QWindow we can also find the TabBox window on Wayland where
the winId is not really helpful.
This also changes the elevation from Unamanged to Toplevel, so that
it is no longer X11 specific.
Result: TabBox stays on top of all windows also on Wayland.
This method is able to match a QWindow created by KWin to a Toplevel.
On X11 by matching winId against Unmanaged, on Wayland by matching
to internal window of ShellClient.
Finding the internal window is a commonly needed feature to e.g.
elevate the TabBox window.
A transient window should always be visible on the current screen.
This change ensures that a transient is always placed in a way that
the transient window is visible on the screen ignoring the transient
offset hint if it has to be.
Unfortunately QtWayland doesn't set the transient hint correctly:
a sub menu is a transient to the main window and not to the parent
menu resulting in quite off positioned menus, see:
https://bugreports.qt.io/browse/QTBUG-51640
Need to add client pos to the transient's position. The offset is
relative to the parent surface, but the client doesn't know about the
size of the decoration, thus KWin needs to add it.
Test creates windows and transients for it and verifies the position.
For decorated windows the position is currently broken as it does not
consider the adjusted client position.
