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
Greetings from the "wtf, how could that have ever worked" department.
This fixes the screenedge activation on Qt 5. The last trigger time is
only set after an activation so before activation it is invalid thus the
comparison to any value doesn't make sense.
That's what you get for changing code you cannot properly test. The
calculation was completely messed up. Now reads the correct byte size
for the byte array. In addition the usages in the effects are improved
to cast the data into the proper uint32_t values instead of the more
generic long. After all if the format is 32, the length is 32 and not
a long.
compensated by a QuartOut shape, this keeps the
effect alive while the sheet or similar effects run
without much visual stretch
Covers issue until there's AnimationEffect::determine()
CCBUG: 321897
semi Fixed in 4.11.2
REVIEW: 111798
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
the restack code stacks under all members of an application
this is a problem if the group contains a keep below or desktop
etc. (while the other window is a normal one) what resulted in
restacking the client "invalidly" above the window of the other
layer but below all other memberso of its own group for no reason
REVIEW: 112627
CCBUG: 110543
F(S)UM mean "the focus is where the mouse is"
the mouse is not on the other virtual desktop
(and it was even granted regardless of the actual geometry/position)
The "unreasonable" focus policies expose an issue about
the present linked handling of "allow activation" and
"allow raising" (see https://git.reviewboard.kde.org/r/110919/ )
Activation would match "extreme" (if the window maps on the same
virtual desktop, half a mile away from the mouse, it won't
receive the focus) but not regarding raising (which is actually
an issue entirely different from FSP)
REVIEW: 112585
CCBUG: 80897
also work around broken fbo texture clearing on fglrx
so far supports FBO/glClear and resorts to glTexSubImage2D
if the fbo cannot be created or is (in case of fglrx)
known to break, resort to glTexImage2D loading of an
argb array of zeros
BUG: 323065
FIXED-IN: 4.11.2
REVIEW: 112526
broke on interim Wrapper() constructor change
The Constructor needs to explicitly pass
XCB_WINDOW_NONE to the inherited Constructor to
trigger a request
Thanks to Alex Leach for finding this
CCBUG: 256242
FIXED-IN: 4.11.2
REVIEW: 112595
1. when adding a full damange, that must not replace existing (larger) repaints
2. emit geometryChanged before invoking and to update shadowGeometry through addRepaintFull
BUG: 324560
FIXED-IN: 4.11.2
Behavior seems to have changed in Qt 5. Without doing the move the deco
has a wrong position and all mouse interaction is broken after the first
resize.
And with this change Oxygen windeco in compositing is fully functional!
Qt requests focus on a mouse press event on the QWindow of a QWidget.
This results in our active window losing focus when a mouse press on
the window decoration happens.
Of course we don't need Qt to request focus on the window decoration.
If it's the inactive window we will activate it by ourself. If it's
the active window, well it's already active.
Adding Qt::WindowDoesNotAcceptFocus to the initial window flags
ensures that this behavior in Qt gets disables with the result that
the window no longer loses focus on mouse click on decoration.
I declare this to be the most difficult one line change in my life.
