Summary:
Because KWin is a very old project, we use three kinds of null pointer
literals: 0, NULL, and nullptr. Since C++11, it's recommended to use
nullptr keyword.
This change converts all usages of 0 and NULL literal to nullptr. Even
though it breaks git history, we need to do it in order to have consistent
code as well to ease code reviews (it's very tempting for some people to
add unrelated changes to their patches, e.g. converting NULL to nullptr).
Test Plan: Compiles.
Reviewers: #kwin, davidedmundson, romangg
Reviewed By: #kwin, davidedmundson, romangg
Subscribers: romangg, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D23618
Summary:
This has been commented out since 2014, I doubt it will come back.
This is a big amount of code, maintenance will be easier without it.
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: romangg, graesslin, kwin
Tags: #kwin, #documentation
Differential Revision: https://phabricator.kde.org/D23069
Summary:
Switch to Q_ASSERT in order to make code a bit more consistent. We have
places where both assert and Q_ASSERT are used next to each other. Also,
distributions like Ubuntu don't strip away assert(), let's hope that
things are a bit different with Q_ASSERT.
Test Plan: Compiles.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: romangg, davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D23605
Summary:
So far we were following a bit unique and rare doxygen comment style:
/**
* Contents of the comment.
**/
Doxygen comments with this style look balanced and neat, but many people
that contribute to KWin don't follow this style. Instead, they prefer
more traditional doxygen comment style, i.e.
/**
* Contents of the comment.
*/
Reviewing such changes has been a bit frustrating for me (so selfish!)
and for other contributors.
This change switches doxygen comment style in KWin to a more traditional
style. The main reason for doing this is to make code review process easier
for new contributors as well us.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D22812
Summary:
This is used by GTK clients to know whether to draw as though they have
focus or not. Whilst it's most visible for CSDs headers, use of the
active/inactive palette (or backdrop class in GTK terms) applies
everywhere.
Rationale of the flag is to allow the WM to hint visual states without
giving input, i.e so you can hint that the parent of a modal dialog
should be shown as active. Though kwin only sets it on the truly active
window to match the behaviour our other windows follow.
BUG: 398832
I expect this to be potentially controversial as it's new code in X11,
so in advance:
* Unlike GTK_FRAME_EXTENTS, it is part of the specificiation (albeit
1.4) even i3 supports it.
* It does fix a real world issue
* It's only 2 lines (plus trivial boiler plate in kwindowsystem)
* It's in code path that we rely on for our existing code
* If there's a situation where this does break, the worst that will
happen is a client gets a visual hint to have focus incorrectly, which
ultimately is the same as the current state
Test Plan:
Used my CSS for breeze-gtk
moved between windows
Reviewers: #kwin, rooty, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, ognarb, ngraham, rooty, graesslin, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D19613
Summary:
We have a mix of different doxygen comment styles, e.g.
/*!
Foo bar.
*/
/**
* Foo bar.
*/
/** Foo bar.
*/
/**
* Foo bar.
*/
/**
* Foo bar.
**/
To make the code more consistent, this change updates the style of all
doxygen comments to the last one.
Test Plan: Compiles.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18683
Summary:
Commit 5d9027b110 introduced a regression in TabBox by using the generic
framework inside KWin to test for same application. What I did not
consider was that the code in TabBox was "broken by design". It didn't
use the generic check as that is too strict and considers windows from
different processes as not belonging to the same application. But this
is not wanted in the case of TabBox.
On the other hand the change itself is an improvement to also support
Wayland in a better way and not have special handling situations. Thus
just reverting would not help.
Instead this change addresses the problem by extending the internal API
and to allow more adjustements. So far there was already an
"active_hack" boolean flag. This is extended to proper flags with an
additional flag to allow cross application checks.
The checks in Client which would filter out different applications check
for this flag and are skipped if set. In addition ShellClient also adds
support for this flag and compares for the desktop file name.
Thus we get in TabBox the same behavior as before with the advantage of
having a better shared code base working on both X11 and Wayland.
BUG: 386043
FIXED-IN: 5.11.4
Test Plan:
Started two kwrite processes on X11, clicked new in one of them,
used Alt+` and verified that there are three windows shown.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8661
Summary:
So far KWin always updated the active window property even if the actual
window id hasn't changed. E.g. if a Wayland window was active and another
Wayland window gets activated the window id was and stays 0.
Nevertheless KWin updated the property causing wakeups in X server and
any application listening to property changes on the root window.
Futhermore this situation is an information leak: we leak when a Wayland
window gets activated to X11.
To solve this problem RootInfo caches the active window id and only
updates if it changes.
Test Plan:
Verified with xev -root that the active window does not get
updated needlessly.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7096
Summary:
Currently only done for X11 clients, should also be done for Wayland
client.s
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D6892
Summary:
Preparation for X free KWin. Code is called for both X11 and Wayland
windows. So make it not crash if we would not have an X server.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D6908
Summary:
On X11 one needs to force activate a panel to pass it focus. This change
implements something similar for Wayland but a little bit more stateful
by using a request on the PlasmaShellSurface. If set KWin will activate
the panel.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3037
QDialog or at least QMessageBox does this and I doubt Lubos' idea was to
"allow focus stealing if the client nags enough" - switching the VD is a
major interrupt and prevented when a new window shows up.
It should not be possible to stomp on ground and then receive
focus - notably not on the other desktop.
I assume the original idea was to let clients distribute focus *inside*
across virtual desktops, maybe also permit when no client was active,
but hardly otherwise.
BUG: 359683
FIXED-IN: 5.6
REVIEW: 127153
This allows to pin the focus on certain window as well
as to more easily give it away on others (typically launchers)
BUG: 185060
CCBUG: 337798
FIXED-IN: 5.5
REVIEW: 126059
AbstractClient now also supports mainClients, so we can do the
fullscreen window check on setActive in a general way. This ensures
that we do get proper stacking changes for activating fullscreen
shell clients.
This fixes yet another regression from the transient refactoring.
The passed in client might be null, so we need a nullptr check. There
are several already in that code.
Was tricky given that I removed a cast there.
AbstractClient::mainClients is virtual and overriden in Client,
allMainClients has only a common implementation in AbstractClient.
In activation.cpp we still need one case where a temporary ClientList
needs to be constructed. Once transients are fully migrated that should
be removable again.
othrwise closing a keepabove or desktop group
window would activate some random window and break
the state as a side-effect
REVIEW: 123783
CCBUG: 346837
CCBUG: 346933
CCBUG: 347212
instead of "just" the direct transient.
Reason is that many windows set dialogs transient
for an entire group (eg. all their document windows)
If there's only one window, that is equivalent to choosing
the direct transient leader.
Originally I wanted to allow this for any amount of
leaders and picked the first one, but that means if
you open 2 kwrite windows (from one PID!) and an
open dialog for kwrite #2 and close the latter,
the focus would be passed to kwrite #1
-> The focus chain is the better choice here.
(One could look up all leaders in the focus chain
OR the stack and use the most recent/top one,
but that's probably voodoo)
REVIEW: 123691
CCBUG: 347437
Moves the implmentation to AbstractClient. Methods are no longer virtual,
setActive calls a virtual protected method which is implemented in Client
for Client specific activation code.
The change is mostly straight forward. Effects are straight forward
adjusted. Client::findModal is moved up, this causes still a few
dynamic_casts to Client. Mostly because Workspace::activateClient still
operates on Client.
apparently some clients (randomly?) set
_NET_WM_USER_TIME to 0 (recorded for libreoffice,
audacity and perhaps firefox), so we allow to
forcefully have them accept the focus here
CCBUG: 340915
REVIEW: 122195
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
Use the timestamp from the xcb event which triggers the update whenever
possible. If we don't have access to the latest event, let's at least
update our own xTime prior to using it.
Slightly unrelated change included: Group switches the userTime from
XLib datatype to xcb datatype.
BUG: 335637
REVIEW: 118456
The Xcb::Property can wrap the xcb_get_property call and provides
convenient access methods to read the value of the reply with checks
applied. For this it provides a templated ::value method for reading a
single value or reading an array. There's also a ::toBool and
::toByteArray which performs the conversion directly with default values
for the type and format checks.
Xcb::TransientFor is changed to be derived from Property instead of
Wrapper directly, so that the reading of the property value can be
shared.
Xcb::StringProperty is a convenient wrapper derived from Property to
handle the reading of a string property providing a cast to QByteArray
operator. This replaces the ::getStringProperty from utils. Though the
separator functionality from ::getStringProperty is not provided as that
is only used in one function and handled there.
All the custom usages of xcb_get_property or getStringProperty are
replaced to use this new wrapper. That simplifies the code and ensures
that all properties are read in the same way.
REVIEW: 117574
Only delegated to Cursor::pos() anyway, so let's just use that directly.
Fixes the annoyances of having to mock it in the unit tests which include
utils.cpp.
REVIEW: 116900
