Prime target is to preserve the in-screen
condition of client AND window.i[1]
Atm. when the client is fully in sight
(but the window is not) - regardless of snapping
or screen change - a workspace update (screen change,
resolution change, adding/removing a strutting panel)
would allow the client to partiall escape screen bounds.
This is changed so that if the client is fully in sight,
it's kept fully in sight (but not the decoration)
If the entire window was fully in sight, it's also kept
(as is right now)
The code handles inner screen edges (if the client was in sight,
the entire window will be if we'd bleed to the other screen)
[1] I'd say that handling the client is more relevant,
but foresee more complaints if the window wasn't handled anymore ;-)
During that, i stumbled across some other issues.
- when a window centered on one screen is moved to a screen smaller
than the window, the window is shrinked to the dimensions of that
screen and now randomly touches eg. left AND right edge. When
moved back, the right and bottom edge were preferred
(to the window was "moved" into the lower right corner).
It's now kept centered.
- geom_restore was saved before keeping the window in the new
screen area (causing accidental drops on screen changes)
BUG: 330968
REVIEW: 122517
FIXED-IN: 5.4
Prime target is to preserve the in-screen condition
of client AND window.[1]
Atm. when the client is fully in sight (but the window is not) -
regardless of snapping or screen change - a workspace update
(screen change, resolution change, adding/removing a strutting
panel) would allow the client to partiall escape screen bounds.
This is changed so that if the client is fully in sight,
it's kept fully in sight (but not the decoration)
If the entire window was fully in sight, it's also kept
(as is right now)
The code handles inner screen edges (if the client was in sight,
the entire window will be if we'd bleed to the other screen)
[1] I'd say that handling the client is more relevant,
but foresee more complaints if the window wasn't handled anymore ;-)
During that, i stumbled across some other issues.
- when a window centered on one screen is moved to a screen
smaller than the window, the window is shrinked to the dimensions
of that screen and now randomly touches eg. left AND right edge.
When moved back, the right and bottom edge were preferred
(to the window was "moved" into the lower right corner).
It's now kept centered.
- geom_restore was saved before keeping the window in the new
screen area (causing accidental drops on screen changes)
BUG: 330968
REVIEW: 116029
FIXED-IN: 5.3
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 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.
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.
