Currently the only way for a uuser to invoke corner-tiling is to
manually set shortcuts for them. This patch adds another option: invoke
the existing shortcuts for edge tiling in a combined manner in quick
succession.
For example, hitting Meta+Left and then Meta+Up within a one-second
period will tile the active window into the top left corner. In practice
you hold down the Meta key and then press Left then Up (or Up and then
Left), and I think it feels very natural. Linux Mint's window manager
has this feature and I always missed it when I left Mint for the KDE
world.
Autotests for existing tiling shortcuts are adjusted to not break, and
additional tests for the new tiling options are added.
Summary:
This change splits the XdgShellClient class to better match existing
abstractions in the xdg-shell protocol and fix a few issues related to
sending configure events.
In the new client classes, configure events are handled differently.
Instead of blocking configure events, we try to send them as late as
possible. Delaying configure events will let us merge changeMaximize()
for X11 clients and Wayland clients and it also fixes the bug where
we don't send the final configure event when user has finished resizing
a window.
Given that configure events are not sent immediately, XdgSurfaceClient
keeps the last requested frame geometry and the last requested client
geometry.
This patch doesn't intend to fix all issues in kwin's implementation of
the xdg-shell protocol. For example, we still handle surface unmapping
very poorly.
Test Plan: Tests pass.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D27861
Summary:
A common user complains is that our OSDs--particularly the volume OSD--are too intrusive
and get in the way of the screen content. For example when adjusting the volume while
watching a full-screen video, the volume change OSD will typically appear right in the
middle of an actor's face.
D20569 was an attempt to use a horizontal OSD to alleviate this issue. It mostly worked,
but IMO it was still positioned too high up.
This patch moved the placement down a little bit to make the OSD appear even farther from
the center of the screen to make it less likely to
I tried not to move it down too far or else it would interfere with subtitles in videos.
Test Plan:
With D20569:
{F8269172}
{F8269164}
{F8269163}
Reviewers: #kwin, #vdg, broulik, ndavis, zzag
Reviewed By: #kwin, #vdg, ndavis, zzag
Subscribers: meven, ndavis, niccolove, baberts, davidedmundson, filipf, zzag, kori, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D29263
Summary:
As is KWin only had 1 Cursor which was a singleton. This made it impossible for
us to properly implement the tablet (as in drawing tablets) support and show where
we're drawing.
This patch makes it possible to have different Cursors in KWin, it makes all the
current code still follow the mouse but the tablet can still render a cursor.
Test Plan: Tests pass, been using it and works as well as before but with beautiful tablet cursors.
Reviewers: #kwin, cblack, davidedmundson
Reviewed By: #kwin, cblack, davidedmundson
Subscribers: davidedmundson, cblack, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D28155
Summary:
Currently, there are a couple of issues with sizeForClientSize(). First
of all, we have a method called clientSizeToFrameSize() which does similar
thing except applying geometry constraints and checking window rules. The
other issue is that sizeForClientSize() is doing a bit too much, it checks
window rules, it applies a bunch of geometry constrains. Sometimes it
does not perform conversion between client sizes and frame sizes!
This change attempts to address those issues by replacing sizeForClientSize
with two similar methods and changing semantics of some methods of the
X11Client class.
The most significant difference between sizeForClientSize() and the new
methods is that neither constrainClientSize() nor constrainFrameSize()
check window rules. This is up to users of those methods. In many places,
we don't have to check window rules because we check isResizable(),
which returns false if the frame size is enforced by a window rule.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, romangg, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D26828
Summary:
Qt has its own thing where a type might also have corresponding list
alias, e.g. QObject and QObjectList, QWidget and QWidgetList. I don't
know why Qt does that, maybe for some historical reasons, but what
matters is that we copy this pattern here in KWin. While this pattern
might be useful with some long list types, for example
QList<QWeakPointer<TabBoxClient>> TabBoxClientList
in general, it causes more harm than good. For example, we've got two
new client types, do we need corresponding list typedefs for them? If
no, why do we have ClientList and so on?
Another problem with these typedefs is that you need to include utils.h
header in order to use them. A better way to handle such things is to
just forward declare a client class (if that's possible) and use it
directly with QList or QVector. This way translation units don't get
"bloated" with utils.h stuff for no apparent reason.
So, in order to make code more consistent and easier to follow, this
change drops some of our custom typedefs. Namely ConstClientList,
ClientList, DeletedList, UnmanagedList, ToplevelList, and GroupList.
Test Plan: Compiles.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24950
Summary:
In order to properly implement xdg_surface.set_window_geometry we need
two kinds of geometry - frame and buffer. The frame geometry specifies
visible bounds of the client on the screen, excluding client-side drop
shadows. The buffer geometry specifies rectangle on the screen that the
attached buffer or x11 pixmap occupies on the screen.
This change renames the geometry property to frameGeometry in order to
reflect the new meaning assigned to it as well to make it easier to
differentiate between frame geometry and buffer geometry in the future.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24334
Summary:
AbstractClient has a method that exposes frame margins. Use that instead
to make code simpler and ready for upcoming xdg-shell changes.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24188
Summary:
Currently each managed X11 client is represented with an instance of
Client class, however the name of that class is very generic and the
only reason why it's called that way is because historically kwin
was created as an x11 window manager, so "Client" was a sensible choice.
With introduction of wayland support, things had changed and therefore
Client needs to be renamed to X11Client in order to better reflect what
that class stands for.
Renaming of Client to X11Client was agreed upon during the last KWin
sprint.
Test Plan: Compiles, the test suite is still green.
Reviewers: #kwin, romangg
Reviewed By: #kwin, romangg
Subscribers: romangg, davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24184
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:
So far some placement policies were handling special case when area is
a null rectangle. However, there is no good reason to do that. We can
just pass a valid area rectangle and remove pointless checkArea helper.
Doing so will make the code simpler and more comprehensible.
Reviewers: #kwin, gladhorn
Reviewed By: #kwin, gladhorn
Subscribers: gladhorn, romangg, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D23923
Summary: We have to provide placement area for the screen on which the client is.
Reviewers: #kwin, romangg
Reviewed By: #kwin, romangg
Subscribers: romangg, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D23921
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:
To do so can in some situations lock up as the loop goes through
different positions incrementing by client->width/height.
If this is zero we can get into a stuck state.
This became a more common issue due to my earlier patch that places windows
in ShellClient::finishInit to allow the maximize placement strategy to
set the first configure size.
BUG: 408754
Reviewers: #kwin, broulik
Reviewed By: broulik
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D21997
Summary:
Currently popups get positioned once at the initial configure, to set
the correct size and again when they are mapped.
Toplevels are currently only positioned when they are mapped. This works
for all cases where the the toplevel defines its own size, but not if
the window should have an initial size set by the placement strategy or
window rules. Most notably the maximised placement strategy used on
plasma mobile.
Being out of sync and resizing later currently causes a positioning bug
when plasma mobile is used with XdgShell.
This patch repositions all top levels that don't have a position set
through the plasma interface.
Test Plan: Relevant unit test
Reviewers: #kwin, bshah
Reviewed By: bshah
Subscribers: zzag, bshah, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D20241
Summary:
placeIn did not handle the case for a popup not having had the size
already set and only being available via
m_xdgShellPopup->initialSize(). This is needed if we want to call placeIn
at the correct time, before the window is mapped.
There was also a logic bug when sliding popups. We called the
confusingly named setX thinking it would be move the popup keeping the
width the same. In practice it moves the left edge keeping the right
position the same. This wasn't an issue as the size was
discarded.
Handling the resize constraint is not yet done, but it should now be
even more trivial.
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18956
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:
So far transients were placed anywhere on the screen. This behavior was
inspired from X11 where context menus were able to overlap any other
window and use the complete screen area. On X11 context menus and
similar windows are override redirect and thus above all windows managed
by KWin.
On Wayland, though, context menus and similar and windows just like any
other window and thus follow stacking constraints like the parent
window. A context menu is stacked just above it's parent and is
(normally) below any panels. This resulted in problems that context menu
are stacked behind the panel with unreachable options.
This change changes the placement for transients to use the
PlacementArea instead of a screen geometry. Thus the transient does not
render behind the panel. Only in case of a fullscreen the struts are
ignored.
BUG: 389222
FIXED-IN: 5.15
Test Plan: New test case
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D17826
Summary:
XDG Popups will have a transient parent and positional information.
XDG Toplevels can have a transient parent without having positional
information.
Currently we set that we have a transient placement hint of 0,0 which
means the newly opened children go to the top left of the parent.
This new code paths treat child top levels as dialogs centering them to
the parent.
BUG: 393167
Test Plan:
Dolphin help->about
Appeared where it does on X
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16293
Summary:
Support XDGShell Positioning. This gives a client a lot more control
over where the popup will be placed as well as control over how to
handle constraints. i.e what to do if the popup doesn't fit.
trasientOffset was replaced with a method on the client as semantically
it's the role of the client to handle constraints.
Both slide and flip constraint adjustments are implemented. Resize
constraint adjustment will be handled in a future patch.
WlShell is handled by treating it as 1x1 sized anchor with slide
constraint adjustment.
Test Plan:
Manual test of a client implementing xdgpopup exists in kwayland
Extensive unit test here
Existing WlShell test passes (after D16314 which fixes the original)
XdgPopup has a new unit test suite against manually calculated values
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16325
Summary:
If a window flows off the left, we move left of the popup to the left
edge of the screen.
Currently if a window flows off the right, we move the window back by
it's own width, leaving it floating at a random point.
For consistency we should be setting it so the right edge of the popup is on the right
edge of the screen.
So in the auto test for the "right border" case:
The screen is 1280 wide, and we open a 10px popup at 1279 the final X
should be 1270.
Test Plan: Unit test
Reviewers: #kwin, zzag, graesslin
Reviewed By: #kwin, zzag, graesslin
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16314
Summary:
Thanks to std::bind we don't need that many different slots to setup the
global shortcut connections. Instead we can have one shared
implementation which takes the argument and passes it to the window.
To support std::bind arguments in kwinbindings the initShortcut method
and dependencies are adjusted as well as a new macro is added.
As I don't want to include abstract_client.h in workspace.h a new enum
is created for the quick tiling flags used in Workspace. This caused a
larger refactoring as the change to an enum class also caused quite some
changes.
Test Plan: Affected test cases still pass
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D6783
Summary:
There were a few places where we still used Client instead of
AbstractClient. By changing this the placement also works for
Wayland windows in those cases.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D6274
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.
Methods are no longer virtual. The only x11 specific usage in these
methods (resizeInc) is replaced by a virtual method. Default resize
increments is QSize(1,1) for AbstractClient.
Method no longer virtual and only implemented in AbstractClient.
The implementaton works in a generic way nowadyas.
Added an autotest for the basic packTo behavior for packing against
a screen border. Packing towards other clients still needs adjustments
in the Placement code.
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.
A transient ShellClient has an offset position to the parent surface.
Use this to position the ShellClient properly.
This fixes the random placement of menus.
