Change required to get methods using TabSynchronizer moved to
AbstractClient. Unfortunately we need to cast to Client when calling
updateStates. It's save as if it's not a Client we
a) don't have a tabGroup in the first place
b) the check if (main == only) will hit and the method returns
The changeMaximize method is added as a pure virtual protected method
to AbstractClient. This replaces the previous pure virtual maximize
method. Which is now directly implemented in AbstractClient (reusing
the implementation previously in Client).
* skip all overhead on unrestricted moveResizes
* the titlebar is not guaranteed to be the top border (anymore)
* don't block vertical resize when resizing on a top corner
* reduce QRegion operations by knowledge about the degenerated titlebarregion (rect)
* rename int (sic!) "titleArea" to "requiredPixels"
REVIEW: 125428
1. if a client has oversize, ensure to keep the titlebar in
sight
2. if a maximized client *almost* covers the entire maximization
area, users can easily be trapped to click into the missing
pixels, thus the client below.
Therfore the clients is then stuffed into one corner, with
preference to the titlebar edge and the screen area (ie.
*away* from panels and towards actual screen borders because
of fitt's law)
BUG: 349935
REVIEW: 124286
FIXED-IN: 5.4
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
since the client is currently empty, we'll resort
to client hints, ie. effectively resize windows
when shading them (setGeometry and plainResize have
extra checks on whether this geometry is only the decoration
height to not smear client_size)
REVIEW: 123882
BUG: 348064
A ShellClient can have window type dock. In that case it's considered to
have a strut. That is currently every panel restricts the area. On the
other hand only internal clients can be docks at the moment. For Plasma's
panels a dedicated interface will be needed.
A wrapper class for MotifHints is added to xcbutils. This class manages
the information about the read Motif hints, so that Client doesn't need
to have a copy of the read states.
The class is designed in a way that during Client::manage we get rid of
another roundtrip.
REVIEW: 122378
otherwise the stored geometry would be correct for
maximized borders, thus the unmaximized borders
make the window to small on unmaximizing
BUG: 343691
FIXED-IN: 5.2.1
REVIEW: 122416
otherwise the stored geometry would be correct for
maximized borders, thus the unmaximized borders
make the window to small on unmaximizing
BUG: 343691
FIXED-IN: 5.2.1
REVIEW: 122416
Xcb::GeometryHints is a convenient wrapper around the size hints
as described in ICCCM combined with the sanity checks so far applied
by KWin after reading the property.
Instead of accessing the members of the property structure, we are
now using the convenience methods.
During ::manage no further actions are triggered when reading the
size hints. Only when they are read later on the previous checks
are applied. During ::manage they can be ignored as it had a dedicated
isManaged check.
The method ::resizeWithCheck got a new argument of type xcb_gravity_t
which defaults to 0. This is needed from ::configureRequest which so
far temporarily changed the xSizeHints structure. By passing as an
argument this is no longer needed.
REVIEW: 122185
BUG: 342981
REVIEW: 122118
The geometry of the window when entering QTM is
a technical detail (caused by the maximizing action
of moving the window to the upper edge) and thus
does not qualify as geometry the window should be
restored to (using a deoc button, shortcut etc.)
Mostly a safety check, but fixes a crash with borderless maximized
windows. If that option is set we also do not notify the decoration
at all, as the deco will be destroyed anyway.
BUG: 341675
REVIEW: 121858
checkWorkspacePosition() operates on geom_restore
to preserve window positions on temporary
(without moving/resizing the window by the user)
screen layout/geometry changes.
Therefore, in the multiscreen case the
screenbound check must be done towards
the screen the window *would* be on
according to geom_restore, not the one
it is right now.
CCBUG: 161325
REVIEW: 121320
FIXED-IN: 5.2
If a Client closed during move/resize with the outline being shown
for quick tile/maximize area, the outline never got removed.
BUG: 341673
FIXED-IN: 5.1.2
REVIEW: 121410
It used to get the individual screen geometries from QDesktopWidget.
We don't need to go through QDesktopWidget any more as Screens
contains all the information we need in a more reliable way.
The build option got introduced for Plasma Active back in a time
when we did not properly aim for convergence. In a Plasma 5 world
we want to have only one shell and one window manager which adjust
itself. This means we don't want a differently compiled kwin for
plasma active, but the same one. Thus the build option doesn't
make much sense any more. A KWin for touch interface needs to support
screenedges for the case that mouse is plugged in.
CCBUG: 340960
REVIEW: 121200
NOTE: this is not working completely yet, lots of code is still ifdefed
other parts are still broken.
The main difference for the new decoration API is that it is neither
QWidget nor QWindow based. It's just a QObject which processes input
events and has a paint method to render the decoration. This means all
the workarounds for the QWidget interception are removed. Also the paint
redirector is removed. Instead each compositor has now its own renderer
which can be optimized for the specific case. E.g. the OpenGL compositor
renders to a scratch image which gets copied into the combined texture,
the XRender compositor copies into the XPixmaps.
Input events are also changed. The events are composed into QMouseEvents
and passed through the decoration, which might accept them. If they are
not accpted we assume that it's a press on the decoration area allowing
us to resize/move the window. Input events are not completely working
yet, e.g. wheel events are not yet processed and double click on deco
is not yet working.
Overall KDecoration2 is way more stateful and KWin core needs more
adjustments for it. E.g. borders are allowed to be disabled at any time.
and copy isSpecialWindow() check as rulebook input
to setFullscreen()
Client::isFullScreenable() checks:
* fullscreen rule
* fullscreen_hack (-> for normal windows)
* geometry restrictions
* special window
Client::manage() for fullscreeining checks:
* fullscreen rule (with correct "initial" parameter)
* fullscreen_hack
-> this breaks the fullscreen rule for geometry restricted windows
and causes inconsistent behavior between client requests at runtime
(which do not test ::isFullScreenable()) and on mapping.
Otoh, the specialWindow() protection should apply generally - those
kind of windows should not be fullscreened since the user can not
exit this state via kwin for them - and there's hardly a good reason
for them to be fullscreen, esp. not to enter that state at runtime
REVIEW: 118442
CCBUG: 335617
Cherry-picked from kde-workspace
43229afee9fac4303e3d280ea63f96f034b3ffb5
it's not been possible to attach tabs to an (undecorated!)
fullscreen window.
now it's neither possible to attach a fullscreen window to
another tabgroup and fullscreening a window will untab it
CCBUG: 332568
Forward port of abf3d200cfc39fcc27a22224512853a96d947add from kde-workspace
Only used for the delayedMoveResizeTimer as timeout slot. Code is small
so a lambda makes more sense. At the same time the code is slightly
improved to ensure that startDelayedMoveResize is never called while
the timer is already active.
This means that mousePressEvents are now required to come from the
decoration.
REVIEW: 117843
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
two-fold issue
a) setMaximize implicitly sets QuickTileMaximize; setting it again toggles it off
b) setting quicktile mode needs to happen in keyboard mode and thenn the target
still depends on the current windo position, so the untiled window needs to
be in a sane location (while geom_restore will typically be off-screen when
quick tiling by mouse)
BUG: 330819
FIXED-IN:4.11.7
REVIEW: 115521
Use base_width/base_height if provided by the application and fallback to
min_width/min_height only if not (according to ICCCM 4.1.2.3).
This fixes long standing bug with shrinking gnome-terminal window.
REVIEW: 115396
1. swapping direction would rather toggle tiling
2. the next screen was calculated wrongly (found outmost)
3. the electrictborder geometry was not updated when swapping the mode on screen changes
BUG: 329136
FIXED-IN: 4.11.6
CCBUG: 222921
REVIEW: 114648
Since windows can place the decoration outside the screen
this needs to be still a valid condition when checking
whether we've to keep in area
In addition: calculate tx, ty and perform one move call
(include rule check and XMoveWindow unless there's a geometry
blocker ...)
BUG: 324792
FIXED-IN: 4.11.2
REVIEW: 112805
whether or not a window is maximizable does really not
matter (it's not if the size is locked, so the
maximized size is the only size) but only if the
window can take the fullscreen geometry.
otoh, the size restrictions (maximum size, fixed aspect)
should be honored by default but still ignorable by rule
BUG: 324733
FIXED-IN: 4.11.2
REVIEW: 112654
Because that's where it's placed. Notable esp. when there're panels on opposing sides.
Since snapping keeps max'd windows in position, it should preferably keep it in the proper position ;-)
REVIEW: 112322
