othrwise closing a keepabove or desktop group
window would activate some random window and break
the state as a side-effect
REVIEW: 123783
CCBUG: 346837
CCBUG: 346933
CCBUG: 347212
... not them becoming visible.
Latter doesn't work for most cases (unminimizing)
for obvious reasons (they're not minimized) and
when a new window is mapped, the focus stealing
prevention seems a good filter
(if it's not good enough to gain the focus,
it's not good enough to break the state either)
REVIEW: 123783
CCBUG: 346837
CCBUG: 346933
CCBUG: 347212
Windows that "belong" to the desktop are
kept visible and do no break the state on
activation/mapping
REVIEW: 123783
CCBUG: 346837
CCBUG: 346933
CCBUG: 347212
If the ShellClient got created for a Qt internal window, we try to
find the QWindow and if we get one, we use the geometry directly as
it got set by KWin in the first place.
Also a windowId() is added to ShellClient which can be used by the
effect system to find an EffectWindow. If it's an internal QWindow
we just use that window id. For other clients we still need some
smart solution.
QtWayland and mesa might dead lock KWin if we start rendering a QWindow
before Qt/Mesa got the last frame callback. They perform blocking wayland
event reading on the main gui thread which makes it impossible for KWin
to do the compositing and send the callback.
To workaround this problem we fake a frameRendered directly after each
damage event for a Qt internal window. Unfortunately this is not yet
completely sufficient, thus we also need to ensure that the wayland
events are processed before any events are processed which would cause
a repaint and block. Thus we first flush QtWayland's wl_display and then
our Server connection. If there were any damage events we can be sure
that the frameRendered is sent before Qt attempts to render.
QtWayland only creates popup windows if they have a parent QWindow or
if there is any window which had input. It's not enough to fake an
enter, it needs to be either a pointer button press or key press.
As KWin's useraction menu doesn't have a parent and we most likely
never send a pointer press to any QWindow it doesn't get shown. To
circumvent this we create a dummy window and fake a button press/release
on the window. After that Qt is tricked into believing there's a parent
window and shows the popup.
Faking the input is only done with at least Qt 5.5 as QtWayland crashes
on pointer event without a keymap being installed. As KWin does not yet
send keymaps we better disable the dangerous code path. With Qt 5.5 the
crash condition is fixed.
KWin used the wrong event dispatcher: QEventDispatcherUNIX insted of
QUnixEventDispatcherQPA. This caused QWindow related events never to
be send to their destination. Which is one of the reasons why KWin's
own windows are not shown at all.
As we cannot easily use QUnixEventDispatcherQPA we do the same as
that class. Inherit from QEventDispatcherUNIX and call into
QWindowSystemInterface::sendWindowSystemEvents.
The signal might be emited by Workspace just before a Client gets
destroyed. In that case the argument carried by the queued event is no
longer valid and causes problems. In EffectsHandlerImpl we can queue
it without problems as the EffectWindow also stays valid if the Client
gets destroyed. The referenced Deleted gets destroyed with a deleteLater,
thus will be after the signal is emitted.
BUG: 347490
REVIEW: 123729
only return early if we cannot create a
selectionwatcher, otherwise the claiming
code turns unreachable after the creation
of cm_selection
BUG: 347813
REVIEW: 123826
just a wild guess - the crashes showed up
somewhen after the early setting of the property/
X11Info access - if this indeed is the cause, they
should disappear or only appear after actually using
the detect button. We'll see.
CCBUG: 346748
REVIEW: 123777
transformed screens prevent hardware clipping
leading through filtering subquads
This requires to subquad in the painting pass
what is not supported for non rectangular
qauds ands presently aborts (in debug builds)
if any quad is transformed (as by eg. the wobbling)
REVIEW: 123733
BUG: 338972
ScreenInfo::rate is reporting 50Hz (on at least nvidia)
... AGAIN! * sigh*
In addition we check for __GL_SYNC_DISPLAY_DEVICE to pick
the rate of the screen that the driver will actually sync to
(hopefully...)
The patch is limited to nvidia systems for 5.3, applied everywhere
in master (ie. will be in 5.4 unless there's some problem)
BUG: 347360
REVIEW: 123693
Same issue as with present windows closers: qml is slow
Interestingly "hide" means "hide" here and there're also
no visual artifacts.
BUG: 347339
REVIEW: 123668
# The first commit's message is:
do not switch desktop on resizing windows
REVIEW: 123599
# The 2nd commit message will be skipped:
# fix screenedge flipping merge
instead of "just" the direct transient.
Reason is that many windows set dialogs transient
for an entire group (eg. all their document windows)
If there's only one window, that is equivalent to choosing
the direct transient leader.
Originally I wanted to allow this for any amount of
leaders and picked the first one, but that means if
you open 2 kwrite windows (from one PID!) and an
open dialog for kwrite #2 and close the latter,
the focus would be passed to kwrite #1
-> The focus chain is the better choice here.
(One could look up all leaders in the focus chain
OR the stack and use the most recent/top one,
but that's probably voodoo)
REVIEW: 123691
CCBUG: 347437
just a wild guess - the crashes showed up
somewhen after the early setting of the property/
X11Info access - if this indeed is the cause, they
should disappear or only appear after actually using
the detect button. We'll see.
CCBUG: 346748
REVIEW: 123777
transformed screens prevent hardware clipping
leading through filtering subquads
This requires to subquad in the painting pass
what is not supported for non rectangular
qauds ands presently aborts (in debug builds)
if any quad is transformed (as by eg. the wobbling)
REVIEW: 123733
BUG: 338972
ScreenInfo::rate is reporting 50Hz (on at least nvidia)
... AGAIN! * sigh*
In addition we check for __GL_SYNC_DISPLAY_DEVICE to pick
the rate of the screen that the driver will actually sync to
(hopefully...)
The patch is limited to nvidia systems for 5.3, applied everywhere
in master (ie. will be in 5.4 unless there's some problem)
BUG: 347360
REVIEW: 123693
