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
