The event filtering on Qt level does not work any more. The information
is not updated properly. Grabbing the mouse through QWidget resets the
cursor shape to the default shape, so it cannot be used.
As we don't want Qt to ever see the events it's a good idea to use a
native event filter to filter the events away before they are delivered
to Qt.
To simplify the handling the grabber widget is put into a QScopedPointer.
Screenedges KCM is adjusted to build against Qt5. Most notable
changes:
* no longer links kworkspace as ScreenPreviewWidget got moved into
the KCM
* ui file is adjusted to not crash (see git log of kcmdesktop)
Removes the functionality for Plasma::Wallpapers as that doesn't exist
any more and is not needed by the Screenedges KCM. The KCM still has
way too many functionality, but that can stay for the moment as it's
probably best to reimplement the monitor and the actions in QML.
The ScreenPreviewWidget doesn't make much sense any more for the general
useage as it's not QML based and thus not suited for any usage in Plasma.
This means that features like previewing the Plasma wallpaper cannot
work any more.
The Widget is only used in a few KCMs (KDM, Screensavers, Screenedges).
Currently we expect that KDM and legacy X Screensavers won't make it into
the next release, it makes sense to just move the widget to screenedges
where it's still useful.
This change has been discussed with notmart.
Note to people compiling from source: it's only the default of the
cmake variable which got changed. You have to delete the variable
from the cache to get this change.
with 4 instead of just altering the default value
It seems the value is actually written for some ppl.
Worse: former patch didn't actually work as expected
anymore
CCBUG: 321897
With QtQuick2 KWin is no longer the only one having an OpenGL context
thus we need to ensure that our context is current. If not it results in
highly interesting crashes when our code is executed on the QtQuick
context.
The context is made current before we swap and before we start to render
a frame. During rendering a frame it's not made current again based on
the assumption that while we render there is no interference. If this
assumption doesn't hold, we need a more sophisticated solution at the
moment it seems to fix the crashes.
Our back shortcut is registered as Alt+Shift+Backtab but our converted
Qt key coming into the test method is Alt+Shift+Tab. The logic so far
made this always fire for the normal Alt+Tab shortcut as at some point
the Shift modifier gets removed to do the test.
To handle it properly we first have to extract all the modifiers to just
get the key. If the key is Tab, we replace it with Backtab, combine it
with the extracted mods so it will be Alt+Shift+Backtab which matches
the registered shortcut.
The existing backtab solution can probably be removed and is clearly
wrong as it uses the keys as flags which they aren't.
The variable is set not from config nor anywhere else when kwin is
started through ksmserver by startkde.
In addition the KGlobal implementation is twisted compared to the kcminit
config behavior (the config value defaults to true, not false - ie. if the
variable isn't set (by kcm init) it's reasonable to assume true either.
Therefore and in alignment with PW/2, the environment is read directly and
on absence resolved to "true".
To control the behavior, please export KDE_MULTIHEAD=true/false before starting KWin
(eg. in /usr/bin/startkde)
This reverts commit ab6d5c048a25bcb2f5bdb822ba3eda64019c61bc.
REVIEW: 112579
CCBUG: 256242
repaints caused by effects so far polluted the timing calculations
since they started the timer on the old vsync offset
This (together with undercut timing) lead to multiple frames in
the buffer queue, and ultimately to a blocking swap
For unsynced painting, it simply caused wrong timings - leading to
"well, kinda around 60Hz - could be 75 as just well".
REVIEW: 112368
CCBUG: 322060
that part is fixed in 4.11.2
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
