Summary:
Currently setDesktop and unsetDesktop were out of sync, with the latter
missing several important signals and updating of transients.
By using a a shared implementation we avoid that, it also allows for an
atomic move of a window between desktops.
setDesktop is changed back to be a moval of desktop as it currently
broke several unit tests as well as changing the behaviour of the move
to desktop shortcut on wayland.
Test Plan:
testBindings now passes
Moved windows with the context menu on X11
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: graesslin, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16703
Summary:
If you resize a decorated client by using the resize user action(press
Alt + F3 > More Actions > Resize), then KWin will crash because it gets
stuck in an infinite loop (AbstractClient::performMoveResize <->
ShellClient::setGeometry).
Here's how KWin gets stuck in that loop:
* when you finish resizing the client, AbstractClient::keyPressEvent
will call AbstractClient::finishMoveResize;
* the first thing that finishMoveResize does is block geometry updates,
then it does some clean up (e.g. reset the value of isMoveResize(), etc),
updates the geometry of the client and when it's done, it will emit
clientFinishUserMoveResized signal;
* when PointerInputRedirection notices that signal, it will call
processDecorationMove on the client, which in its turn will indirectly
call AbstractClient::startMoveResize;
* when it's time to go back to AbstractClient::keyPressEvent, geometry
updates are unblocked and if there are any pending geometry updates,
then ShellClient::setGeometry will be called;
* ShellClient::setGeometry will eventually call ShellClient::doSetGeometry;
* ShellClient::doSetGeometry will call AbstractClient::performMoveResize
because AbstractClient::processDecorationMove indirectly called
AbstractClient::startMoveResize;
* AbstractClient::performMoveResize calls ShellClient::setGeometry;
* (at this point, KWin got stuck in the infinite loop)
This change swaps setMoveResizePointerButtonDown and finishMoveResize,
so processDecorationMove won't indirectly call startMoveResize.
BUG: 397577
FIXED-IN: 5.14.4
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16846
Summary:
Doesn't have any meaningful impact. It's the same performance when T is a pointer,
but it'll bring it consistent with VirtualDesktopManager::desktops
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16736
Summary:
implement virtual desktop support for Wayland.
use the new virtual desktop protocol from D12820
The VirtualDesktopManager class needed some big change in order
to accomodate it, which is where most changes are.
Other than that, it's mostly connections to wire up
VirtualDesktopsManager and VirtualDesktopsManagement(the wayland protocol impl)
Depends on D12820
Other notable detail, is the client visibility updated to reflect the presence
of the client in the plasmavirtualdesktop.
(and the unSetDesktop concept)
Test Plan: used a bit a plasma session together with D12820, D13748 and D13746
Reviewers: #plasma, #kwin, graesslin, davidedmundson
Reviewed By: #plasma, #kwin, davidedmundson
Subscribers: hein, zzag, davidedmundson, kwin
Tags: #kwin
Maniphest Tasks: T4457
Differential Revision: https://phabricator.kde.org/D13887
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:
This exposes colorScheme as a property which is then usable by kwin
scripts.
Wanted by T9769.
Test Plan:
Michail to test in a script.
Reviewers: #kwin, zzag, graesslin
Reviewed By: #kwin, zzag, graesslin
Subscribers: mvourlakos, zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D15913
Summary:
The change to make maximize mode asynchronous featured the comment
>Things are a bit complex with borders. Technically we
>shouldn't update them till we get a response, but we also need to have
>the correct geometry of the full size window in our request. For now
>they behave as before, updating when we request the change.
We call setNoBorder when we request the geometry but decoratedClient
also checks the maximise mode, in order to follow the scheme above we
need this to operate on the requested state not current state.
X is unaffected.
This fixes the borders being restored correct after maximize/restore.
Test Plan:
Chose a theme with visible borders
Maximised a window and back
They restored
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D15991
Summary:
Instead of seeing the cursor <--> on the left edge you now see an icon
that looks like |<- .
This brings kwin decorations in line with GTK CSD icons.
In theory this is also useful to tell which window will resize in the
case of side-by-side windows (regardless of whether borders are on or
not). In practice with the adwaita icon theme I tested with it's not
very intuitive to realise which is which till you learn the icon.
Change is more involved than it should be as Qt::CursorShape doesn't
have these entries, and I don't want to shadow that enum internally or
have
to change kwin effect code.
Specifics depend on cursor icon theme if they are not present it will
fallback to the <--> icon. (Breeze does not have them currently)
Test Plan:
Resized some windows (on X and on Wayland)
Correct icon appeared on Adwaita
Existing icon appeared on Breeze
Reviewers: #plasma
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D13396
This reverts commit 8a2a00a4ca.
It was likely wrongly pushed before the KWayland changes, so it won't
compile.
Feel free to reinstate it once the dependent changes (KWayland) are in.
CCMAIL: bundito@gmail.com
CCMAIL: kwin@kde.org
Summary:
Adding "SkipSwitcher" to the API, following discussion in
BUG 375921
Depends on / related to D11925 and D11924
Reviewers: hein, #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: davidedmundson, #plasma, ngraham, kwin, #kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D11926
Summary:
This allows to override the desktop file name.
CCBUG: 351055
Test Plan: Created a window rule for telegram-desktop to fix the icon
Reviewers: #kwin, #plasma
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D11266
Summary:
There's a call to a virtual doSetSkipPager for performing this call and
Client implements it with the code which now is removed.
This fixes a crash when using setSkipPager for a Wayland window.
Test Plan:
Crash which happens with a new test case (see dependent phab
request) is fixed.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D9865
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.
For the appId we use:
* wl_shell windowClass for Wayland clients
* resourceName from window class for X11 clients
This is implemented by sharing the window class implementation in
Toplevel.
CCMAIL: hein@kde.org
The creation of PlasmaWindowInterface is moved from WaylandServer into
AbstractClient. This allows the sub classes to better control when to
create/destroy the Client.
For creation it's bound to becoming visible - that is Windows which are
only created but never shown are not announced at all.
For Client it's destroyed with the normal tear-down of a Client, for
ShellClient it's destroyed on unmapped (which also means a new one
will be created again in case of another mapping of the surface).
As a side effect, this works around the problem that ShellClients do not
yet get destroyed for QtWayland's menus (needs further investigation).
At the same time the functionality for the "original_skip_taskbar" is
splitted out. This removes the weird API with two boolean arguments to
the set method. Instead there is a dedicated method for the orignal
skip taskbar state which delegates to regular skipTaksbar.
* properties defined in AbstractClient
* implementation of isShade moved to AbstractClient
* implementation of setShade(bool) moved to AbstractClient
* default implementation for isShadeable added to AbstractClient
* default implementation for shadeMode returning ShadeNone
* default implementation fo setShade which does nothing
Moves the properties and the base implementation into AbstractClient.
Methods invoke a new protected virtual method which is implemented in
Client to update the TabGroup.
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.
A virtual base implementation is provided which does nothing. Needed
in AbstractClient to get Workspace::slotWindowGrow* to work with
active_client becoming an AbstractCliet.
The idea for this base class is to provide access to all elements which
make up a managed "Client" being it X11 or Wayland. They share a lot,
like they have a caption, they can be minimized, etc. etc.
Of course it would have also been possible to derive a new class from
Client, but that looks like the more difficult task as Client is very
X11 specific.
So far only a very small interface is extracted with pure-virtual
methods. This is going to change by moving the functionality up into
the AbstractClient.
The interface extracted so far is inspired by the usage of FocusChain
and users of FocusChain.
