Summary:
Toplevel::window() is the actual X11 window. This makes it difficult
to use as the generic identifier for both X11 and Wayland. The Wayland
ShellClient already had a windowId() which is now added to Toplevel as
a virtual method. On X11 (Toplevel default) it returns the window().
The method window() now returns XCB_WINDOW_NONE for classes without
the Toplevel::m_client, such as ShellClient. Thus it allows to properly
check whether we are on Wayland or X11.
The code is adjusted to use windowId where a generic id is needed and
to properly check whether the window is valid before using it where
a window() is used.
This also fixes at least one additional unknown issue in
Workspace::setActiveClient
where the windowId of a Wayland client was passed to X11.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1527
We need to unblock the signals blocked with pthread_sigmask.
This caused kdeinit to block, because it relies on SIGUSR1.
BUG: 356580
FIXED-IN: 5.5.1
REVIEW: 126361
-use qstringliteral only when necessary (i.e. not in concat or comparison)
-use qbytearray instead of qstring when dealing with latin1 input and output (glplatform)
-use qstringref to extract numbers from strings (glplatform)
-define qt_use_qstringbuilder to optimize all string concatenations
-anidata: use ctor init lists, add windowType member initialization
REVIEW: 125933
Workaround, this *seems* a Qt problem.
The grab fails while the button is down - Qt then also seems
to release the keyboard.
Not sending it to the deco didn't help either - nevertheless it seems
(from the Qt code) as if the button is currently grabbed
(the code is a dumb forward to xcb_grab_pointer)
As a workaround, the patch simply ensures a grab on releasing a button when
the popup is visible.
BUG: 351112
FIXED-IN: 5.5
in a way so that each entry has its own
drawback: present mnemonics changed.
they however also change with i18n.
REVIEW: 125434
BUG: 319695
FIXED-IN: 5.5
The problem with KToolInvocation is that it creates a dead lock on
Wayland in case kdeinit is not already running. It starts kdeinit
and does a QProcess::waitForFinished and our kdeinit needs to interact
with the wayland server. So dead lock.
As KRun also calls into the dangerous code path it's no option which
leaves us with QProcess to start the processes.
A nice side-effect is that we no don't need to link KF5::Service any
more from kwin_core. Now once Plasma and Notification don't use it
any more, it will be gone completely.
This is a temporary workaround for bug 349992 which causes freezes
during startup as kwin and kamd dead lock each other on DBus.
To workaround we don't call Activities::create and check in every
usage of Activities::self() whether the pointer is valid.
As a result kwin_wayland now starts pretty fast.
CCBUG: 349992
KGlobalAccel sets the timestamp as a property and we need to set our
x11Time to it otherwise following keyboard grabs might fail.
Requires 61e2a156678eef033b2629f7c72530dc78d7c3ac in kglobalaccel.
Was only used as fallback for older NVIDIA drivers. At the same time
also drop the call to nvidia-settings which was also only used as
a fallback for refresh rate detection.
REVIEW: 122423
The build option got introduced for Plasma Active back in a time
when we did not properly aim for convergence. In a Plasma 5 world
we want to have only one shell and one window manager which adjust
itself. This means we don't want a differently compiled kwin for
plasma active, but the same one. Thus the build option doesn't
make much sense any more. A KWin for touch interface needs to support
screenedges for the case that mouse is plugged in.
CCBUG: 340960
REVIEW: 121200
We are only using the UrgencyHint, InputHint and GroupLeader from
WMHints. Those are provided by NETWinInfo, so we can use the
functionality provided by NETWinInfo instead of calling XGetWMHints.
REVIEW: 120162
NOTE: this is not working completely yet, lots of code is still ifdefed
other parts are still broken.
The main difference for the new decoration API is that it is neither
QWidget nor QWindow based. It's just a QObject which processes input
events and has a paint method to render the decoration. This means all
the workarounds for the QWidget interception are removed. Also the paint
redirector is removed. Instead each compositor has now its own renderer
which can be optimized for the specific case. E.g. the OpenGL compositor
renders to a scratch image which gets copied into the combined texture,
the XRender compositor copies into the XPixmaps.
Input events are also changed. The events are composed into QMouseEvents
and passed through the decoration, which might accept them. If they are
not accpted we assume that it's a press on the decoration area allowing
us to resize/move the window. Input events are not completely working
yet, e.g. wheel events are not yet processed and double click on deco
is not yet working.
Overall KDecoration2 is way more stateful and KWin core needs more
adjustments for it. E.g. borders are allowed to be disabled at any time.
it's not been possible to attach tabs to an (undecorated!)
fullscreen window.
now it's neither possible to attach a fullscreen window to
another tabgroup and fullscreening a window will untab it
CCBUG: 332568
Forward port of abf3d200cfc39fcc27a22224512853a96d947add from kde-workspace
problem is that toggleOnActivity interprets "all" as "none" and
subsequent setting of any activity will move the window to that
activity *only* - what's not suggested by the GUI
-> force the user to "hold it correctly" by unchecking all
individual activities when setting on all - this also matches
the display when the popup is opened w/ "on all" preselected
CCBUG: 330838
Forward port of 31f9e4cf053f59b7013ff006c86290f86adfcdb5 from kde-workspace
Since the KActivities library now keeps an internal cache (and is
non-blocking), there is no point in thread-based information
fetching.
BUG: 335396
REVIEW: 118443
