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
when visualPixels is not 0, this means the titlebar does
not touch an upper/lower border, thus moving that direction
is ok and protection should be sought horizontally
BUG: 322507
FIXED-IN: 4.11
REVIEW: 111573
using the actual delta this casewise causes false
preference for window snapping (less to move)
this restores the pre snap-to-content behavior
in that regard and delta isn't used for anything else.
BUG: 321325
FIXED-IN: 4.11
REVIEW: 111139
similar to maximization blocking
also ensure the user can permit configure requests
for quick tiled and maximized windows
REVIEW: 111186
BUG: 321491
FIXED-IN: 4.11
