Summary:
So far a not-active fullscreen X11 window was kept in the active layer if
the newly activated window is in the same group (that is same client
leader). For example a fullscreen X11 kwrite window is in the active layer
if another kwrite window is active. The two kwrite windows obviously
don't have anything to do with each other, but are in the same group.
This creates problems as it's not possible to raise other windows above
the active not-fullscreen kwrite window. E.g. the panel is stacked below.
The idea behind the check makes sense: if a fullscreen window opens
another window (e.g. a configuration dialog) it should not be put back
to normal layer. Thus the check is adjusted whether the new active
window is a transient to the fullscreen window. Thus the intention is
still the same, but does not cause the problems.
As the code now does not need to differentiate between X11 and Wayland
windows (group only on X11) the Client specific implementation is
removed and the method unvirtual'ed.
BUG: 388310
FIXED-IN: 5.12.0
Test Plan: Test passes
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D9699
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 only updated the Clients, now also ShellClient.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8095
Summary:
In a bug report there was a reference that on multi-screen KSplash is
not placed correctly. I investigated and noticed that it is an OSD which
sets an own position. In KWin the events were processed correctly but
the position was off.
The problem is that KWin has code to correct the position of an OSD when
it's size changes. This happens also on first damage and then the window
gets incorrectly placed when the position is set. So honor that the
position is set.
Test Plan: Restarted the session, ksplash positioned correctly now.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8268
Summary:
So far window rule specific functionality was only implemented in Client
and in ShellClient there was only a dummy implementation. This change
moves the client_rules member variable from Client to AbstractClient.
Areas which would not compile anymore are adjusted.
This is a first step to get window rule support for Wayland windows.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8090
Summary:
With the latest refactoring AbstractClient::captionNormal is the same as
AbstractClient::caption(false) used to be. As there were only two usages
of the false parameter, let's remove this boolean trap and use proper
API calls.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7427
Summary:
The implementation can now be shared, it doesn't differ anymore between
X11 (Client) and Wayland (ShellClient). So instead of code duplication a
shared implementation in AbstractClient.
Test Plan: X11 and ShellClient tests still pass
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7426
Summary:
Bringing another caption feature from X11 to Wayland. If we have
multiple windows with the same caption, starting from the second window
a suffix <number> is added.
E.g. if we have three windows with caption "foo", the naming is:
* foo
* foo <2>
* foo <3>
The change tries to use as much shared code between the X11 and Wayland
implementation. Unfortunately it's not possible to share completely as
the X11 implementation does X11 specific things like editing the visible
name.
By sharing the code the numbering also works cross windowing system.
That is if a window is called "foo" on X11, a new window on Wayland with
caption "foo" will get adjusted to "foo <2>" and vice versa.
The change also eliminates a duplicated signal for captionChanged in
ShellClient (found by test case).
By using the shared implementation on X11 side a bug gets fixed which
got introduced with the support of "unresponsive", this is no longer
considered and the numbering still works even if there is a window which
is unresponsive.
Test Plan: New test case and manual testing
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7425
Summary:
The generation of the shortcut caption part is moved from Client to
AbstractClient. The ShellClient also has a captionSuffix and implements
the full part in caption.
Overall this needs more refactoring to support more sharing between the
two implementations. But one step at a time.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D7093
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:
resourceClass is the more useful half of WM_CLASS. It's what modern X
clients are supposed to set to a .desktop file name, which is closer to
the semantics of appId than resourceName.
Reviewers: #plasma, graesslin
Subscribers: kwin, plasma-devel, #kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D5815
When an application is not responding, its window is desaturated to communicate this.
Also "(Not Responding)" is added to the title bar.
Differential Revision: https://phabricator.kde.org/D5245
Summary:
update m_visibleRectBeforeGeometryUpdate when the padding
change signal gets emitted: aurorae updates its shadow
and postentially shadow size asynchronously after repainting.
that would make the first addRepaintDuringGeometryUpdates
when the winow is moved *for the first time* have a wrong
m_visibleRectBeforeGeometryUpdate that doesn't take into
account the shadow, leaving some leftover shadow on screen
BUG:377670
Test Plan:
shadow leftover not reproducible anymore with maui's kwinrc
replaces D4989
tested both on master and together D4990, which should go in as well
Reviewers: #plasma, davidedmundson, graesslin
Reviewed By: #plasma, graesslin
Subscribers: plasma-devel, kwin, #kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D5078
This brings back global menu support in KWin.
The DBusMenu infrastructure is different that we just read the DBus service name and
menu object path from the windows rather than passing around window IDs on DBus which
won't work on Wayland.
Differential Revision: https://phabricator.kde.org/D3089
Summary:
6383f83047 introduced a regression hitting
an assert on X11 when an osd window is added.
This change tries to address this by adding a GeometryUpdateBlocker
around the change. The hit assertion is:
pendingGeometryUpdate() == PendingGeometryNone ||
areGeometryUpdatesBlocked()
By using a GeometryUpdateBlocker the second condition becomes true
and we no longer hit the condition.
BUG: 374038
Test Plan:
Manual tested both on X11 and Wayland, Wayland autotest
still passes
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D3808
Summary:
The position of an OSD is based on the size of the window. If the
size of the OSD changed, it would not be positioned correctly any more.
With this change the OSD window gets placed again if the size changes.
Thus it's also placed correctly even if the window changed it's size.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D3720
Summary:
The method is supposed to return the AbstractClient's size for a given
client size. That is the size including the window decoration.
The default implementation returned the passed in client size without
adjusting for the decoration. This resulted in ShellClient getting a
wrong size especially when AbstractClient::adjustedClientSize (which
calls sizeForClientSize) was called.
The result of the incorrect size was for example a shrinking of the
window when starting to resize a window.
BUG: 370345
FIXED-IN: 5.8.4
Reviewers: #kwin, #plasma_on_wayland, broulik, subdiff
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3414
Summary:
KWindowSystem provides a KDE specific property for the desktop file
name. This allows KWin to take the icon from the desktop file. The
advantage from the desktop file is that KWin normally gets higher
resolution icons than provided through the xproperty based icons used
previously. If the desktop file does not provide an icon name, KWin
falls back to the previous implementation.
As on Wayland the icon is taken from the desktop file name already the
code for X11 and Wayland is merged in AbstractClient. Also to the
PlasmaWindowInterface the appId is taken from the new desktop file
instead of the resourceName. Due to that for Xwayland windows where KWin
knows the desktop file name it can be passed to PlasmaWindowInterface.
This allows e.g. the task manager to better map the windows to
applications and provide better icons. Also it means that icons do not
need to be passed as bitmap data to the clients.
Test Plan:
Verified that icon is taking from desktop file if provided and
from X property if not provided and that Wayland windows still have icon.
Reviewers: #kwin, #plasma_on_wayland, hein
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3177
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
Summary: This allows to pass also Xwayland icons to the task manager.
Reviewers: #kwin, #plasma_on_wayland, hein
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3050
Summary:
This change adds support for resizing outside the window decoration
(e.g. setting borders to NoSide or None).
To support this a new Toplevel::inputGeometry() -> QRect method is
added which exposes the geometry adjusted by the margins provided by
the decoration. This is checked in InputRedirection when finding a
Toplevel at a given position. The logic for figuring out whether the
event should go to the decoration or the window already handled the
situation correctly, so no further changes are needed.
BUG: 364607
FIXED-IN: 5.8.1
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2787
Summary:
This allows Client to use the Wayland-specific implementation if there
is no icon geometry set through the X11 way. That way Xwayland windows
have an icon geometry even if Plasma is using Wayland and setting the
icon geometry in the Wayland way. Which is expected as Plasma is
ignorant about the windowing system a PlasmaWindow uses.
In order to move the code from ShellClient to AbstractClient
WaylandServer gained a new findAbstractClient(Surface*) method which
is just like findClient(Surface*) with the difference that it returns
an AbstractClient instead of a ShellClient*.
Test Plan:
minimized/unminimized an X client on Wayland, verified
animation is correct (though broken in general for minimize)
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2530
Summary: Needed for e.g. the pager.
Test Plan: Test case for PlasmaWindow verifies the geometry
Reviewers: #kwin, #plasma_on_wayland, hein
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2200
When KWin goes down the DecorationBridge might be destroyed before the
last AbstractClient is destroyed. Thus we should destroy the Decoration
when the DecorationBridge gets destroyed.
Summary:
Mouse actions like wheel and double click were restricted to the titleBar
area. This made the top most pixel non-interactive as it's not part of the
titleBarArea.
This change makes the complete titlebarPosition interactive. That is it
includes for a "normal" (top) setup also the TopLeft/Top/Right section.
Thus the top most pixel can be double clicked, mouse wheeled, etc.
For the Wayland case the test case is adjusted.
BUG: 362860
FIXED-IN: 5.7.0
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1596
Summary:
The window will be cleaned up automatically once all bound resources
are destroyed. A manual delete though might cause protocol errors on
client side as the unmap and resource destroy happen together and we
are in a race condition.
To ensure that we don't leak the interface is set as the parent, so
on tear-down remaining resources will be destroyed eventually, even
if it triggers a protocol error on the client.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1595
Summary:
Sets movable and resizable states on the Wayland window.
kwin doesn't have state change signals for this, so it's a one-time thing.
Depends on D1432.
Reviewers: graesslin
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1434
Summary:
Makes use of new API in kwayland to expose shade state.
Depends on D1417.
Reviewers: graesslin
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1418
General handling for mouse driven focus and auto raise should and can
be shared between Client and ShellClient. Thus the code is moved to
AbstractClient and invoked from Client::enterNotifyEvent.
Replacement for calls to info->input() which is only valid for the Client
sub class, but not for ShellClient.
In ShellClient the implementation is swapped with wantsInput() and
wantsInput() has a new implementation which properly delegates to rules()
just like Client does.
This includes the methods:
* decoration()
* decoration() const
* isDecorated() const
In addition new protected methods are added to destroy the Decoration
and to set it.
Usage of m_decoration in Client code is adjusted.
Properly handle the mouse press/release events in InputRedirection
while we move windows. If it's the last mouse release event we end
the move resize of the window. For that we reuse the code written
in Client.
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.
Sync related code is split out into dedicated virtual methods so that
Client can provide the X11 specific implementation. General handling,
though is completely in AbstractClient.
Implementation is moved to abstract_client.cpp as so far events.cpp
does not have any code from AbstractClient.
This includes moving the electricMaximizingDelay from Client to
AbstractClient.
The implementation of positionGeometryTip is X specific, we need to
figure out whether that one makes sense for Wayland. Given that, let's
have it virtual to ease the transition of code which calls it.
The implementation calls a virtual doStartMoveResize() which allows
Client to do it's X11 specific tasks (creating moveResizeWindow, grabbing
input).
The base implementation is no longer virtual.
Includes moving the m_cursor and Qt::CursorShape cursor() method to
AbstractClient. In addition AbstractClient now emits a signal whenever
the shape changes allowing Client to react on it (update the low level
cursor) and also hopefully the Wayland Backends to react to it, so that
we have the cursor.
Implementation goes to AbstractClient, method is no longer virtual.
The X11 specific code is moved to a new virtual protected doMove
method implemented in Client.
Method added so that we can call into TabGroup::updateStates from code
in AbstractClient. Default implementation does nothing, implementation
in Client performs the actuall call.
As a first case added to Client::move in order to be able to move the
implementation to AbstractClient.
The usage was always to trigger repaints on the old and the new
visibleRect. And store the new visibleRect as the future old one.
This is now encapsulated in a dedicated method called
addRepaintDuringGeometryUpdates().
At some future point we will also need it in ShellClient and it allows us
to better share geometry related implementations.
Base implementation returns 0, that is no border.
Base implementation always returns QuickTileNone. Implementation in
Client overrides. Long term solution: provide functionality directly
in AbstractClient.
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.
Whenever we set a transient we must register it with the parent and
remove it again. Also if a parent gets destroyed we must inform the
transients.
This fixes a crash in Deleted::copyToDeleted when connecting the main
clients. The crash condition was hit if the parent got destroyed
before the transient.
Reviewed-By: Marco Martin
Merges together the code from ShellClient and Client and removes the
starting differences. Long term it's better to have only one
implementation to prevent diversions in the implementation.
As it doesn't match exactly protected virtual methods are called
which allow more specific implementations for a certain aspect of the
layer resolving.
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.
