Summary:
In order to properly implement xdg_surface.set_window_geometry we need
two kinds of geometry - frame and buffer. The frame geometry specifies
visible bounds of the client on the screen, excluding client-side drop
shadows. The buffer geometry specifies rectangle on the screen that the
attached buffer or x11 pixmap occupies on the screen.
This change renames the geometry property to frameGeometry in order to
reflect the new meaning assigned to it as well to make it easier to
differentiate between frame geometry and buffer geometry in the future.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24334
Summary:
EffectQuickView/Scene is a convenient class to render a QtQuick
scenegraph into an effect.
Current methods (such as present windows) involve creating an underlying
platform window which is expensive, causes a headache to filter out
again in the rest of the code, and only works as an overlay.
The new class exposes things more natively to an effect where we don't
mess with real windows, we can perform the painting anywhere in the view
and we don't have issues with hiding/closing.
QtQuick has both software and hardware accelerated modes, and kwin also
has 3 render backends. Every combination is supported.
* When used in OpenGL mode for both, we render into an FBO export the
texture ID then it's up to the effect to render that into a scene.
* When using software QtQuick rendering we blit into an image, upload
that into a KWinGLTexture which serves as an abstraction layer and
render that into the scene.
* When using GL for QtQuick and XRender/QPainter in kwin everything is
rendered into the internal FBO, blit and exported as an image.
* When using software rendering for both an image gets passed directly.
Mouse and keyboard events can be forwarded, only if the effect
intercepts them.
The class is meant to be generic enough that we can remove all the
QtQuick code from Aurorae.
The intention is also to replace EffectFrameImpl using this backend and
we can kill all of the EffectFrame code throughout the scenes.
The close button in present windows will also be ported to this,
simplifiying that code base.
Classes that handle the rendering and handling QML are intentionally
split so that in the future we can have a declarative effects API create
overlays from within the same context. Similar to how one can
instantiate windows from a typical QML scene.
Notes:
I don't like how I pass the kwin GL context from the backends into the
effect, but I need something that works with the library separation. It
also currently has wayland problem if I create a QOpenGLContext before
the QPA is set up with a scene - but I don't have anything better?
I know for the EffectFrame we need an API to push things through the
effects stack to handle blur/invert etc. Will deal with that when we
port the EffectFrame.
Test Plan: Used in an effect
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24215
Summary:
Currently each managed X11 client is represented with an instance of
Client class, however the name of that class is very generic and the
only reason why it's called that way is because historically kwin
was created as an x11 window manager, so "Client" was a sensible choice.
With introduction of wayland support, things had changed and therefore
Client needs to be renamed to X11Client in order to better reflect what
that class stands for.
Renaming of Client to X11Client was agreed upon during the last KWin
sprint.
Test Plan: Compiles, the test suite is still green.
Reviewers: #kwin, romangg
Reviewed By: #kwin, romangg
Subscribers: romangg, davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24184
Summary:
Rename ShellClient to XdgShellClient in order to reflect that it
represents only xdg-shell clients.
Test Plan: Compiles, tests still pass.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D23589
Summary:
So far wayland was used by internal clients to submit raster buffers
and position themselves on the screen. While we didn't have issues with
submitting raster buffers, there were some problems with positioning
task switchers. Mostly, because we had effectively two paths that may
alter geometry.
A better approach to deal with internal clients is to let our QPA use
kwin core api directly. This way we can eliminate unnecessary roundtrips
as well make geometry handling much easier and comprehensible.
The last missing piece is shadows. Both Plasma::Dialog and Breeze widget
style use platform-specific APIs to set and unset shadows. We need to
add shadows API to KWindowSystem. Even though some internal clients lack
drop-shadows at the moment, I don't consider it to be a blocker. We can
add shadows back later on.
CCBUG: 386304
Reviewers: #kwin, davidedmundson, romangg
Reviewed By: #kwin, romangg
Subscribers: romangg, kwin
Tags: #kwin
Maniphest Tasks: T9600
Differential Revision: https://phabricator.kde.org/D22810
Summary:
Because KWin is a very old project, we use three kinds of null pointer
literals: 0, NULL, and nullptr. Since C++11, it's recommended to use
nullptr keyword.
This change converts all usages of 0 and NULL literal to nullptr. Even
though it breaks git history, we need to do it in order to have consistent
code as well to ease code reviews (it's very tempting for some people to
add unrelated changes to their patches, e.g. converting NULL to nullptr).
Test Plan: Compiles.
Reviewers: #kwin, davidedmundson, romangg
Reviewed By: #kwin, davidedmundson, romangg
Subscribers: romangg, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D23618
Summary:
This has been commented out since 2014, I doubt it will come back.
This is a big amount of code, maintenance will be easier without it.
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: romangg, graesslin, kwin
Tags: #kwin, #documentation
Differential Revision: https://phabricator.kde.org/D23069
Summary:
Switch to Q_ASSERT in order to make code a bit more consistent. We have
places where both assert and Q_ASSERT are used next to each other. Also,
distributions like Ubuntu don't strip away assert(), let's hope that
things are a bit different with Q_ASSERT.
Test Plan: Compiles.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: romangg, davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D23605
Summary:
There is no point in using quint32 and casting back and forth in numerous places.
Fix a bunch of compiler warnings that we implicitly cast between signed and unsigned.
This makes things consistent with what we get from libinput.
Reviewers: #kwin, romangg
Reviewed By: #kwin, romangg
Subscribers: zzag, romangg, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D23086
Summary:
This usage of QWeakPointer has been deprecated since Qt 5.0, since it
leads to really confusing API - usually you must never dereference a
QWeakPointer directly, but always go through QSharedPointer, except in
this one case, where it's permissible.
The thumbnails are only referenced in one place, this change is straight-forward.
Reviewers: #kwin, romangg
Reviewed By: #kwin, romangg
Subscribers: romangg, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D23070
Summary:
Use #else, otherwise there are two return statements after each other
which doesn't make sense.
Reviewers: #kwin, romangg
Reviewed By: #kwin, romangg
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D23068
Summary:
The screenlock fails on X11 if it can't grab the keyboard.
We can't nicely solve the generic case. We can solve the common case of
a kwin effect being active.
It's not critical, arguably not even desirable to have these effects
persist after the screen is locked through an external trigger. We can
just close the effect early.
Key grabs have to be relased early before the close animation completes
so that the locker doesn't have a race based on animation times.
It's not ideal, but no worse than the current state for not much work.
BUG: 234153
Test Plan:
locked screen on a timer
opened various effects
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: ngraham, zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D20890
Summary:
Window open/close animation effects should not animate the outline
because the end result is a bit awkward.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D19886
Summary:
So far the ThumbnailItem in TabBox mode used the window id for finding
the window it should render a thumbnail on. In the Wayland world this is
not unique. The window id could be either an X11 window or a wayland
window. We don't guarantee that there are no conflicting ids.
With the internal id we have a way to properly identify the windows, so
this element should use them.
To support this the property changed the type to QUuid and the
clientmodel also provides the QUuid. As in TabBox the way to get the
window is through the model this should be compatible for all themes.
It's tested and verified with the Breeze switcher.
For declarative KWin scripts the ThumbnailItem also provides the
AbstractClient as a property, so there should not be any script which
uses wid. If it does, this could break, but well the script should use
the intended API.
Test Plan: ctest passes, manual testing of Breeze alt-tab switcher
Reviewers: #kwin
Differential Revision: https://phabricator.kde.org/D18405
Summary:
KWindowSystem provides a plugin interface to have platform specific
implementations. So far KWin relied on the implementation in
KWayland-integration repository.
This is something I find unsuited, for the following reasons:
* any test in KWin for functionality set through the plugin would fail
* it's not clear what's going on where
* in worst case some code could deadlock
* KWin shouldn't use KWindowSystem and only a small subset is allowed
to be used
The last point needs some further explanation. KWin internally does not
and cannot use KWindowSystem. KWindowSystem (especially KWindowInfo) is
exposing information which KWin sets. It's more than weird if KWin asks
KWindowSystem for the state of a window it set itself. On X11 it's just
slow, on Wayland it can result in roundtrips to KWin itself which is
dangerous.
But due to using Plasma components we have a few areas where we use
KWindowSystem. E.g. a Plasma::Dialog sets a window type, the slide in
direction, blur and background contrast. This we want to support and
need to support. Other API elements we do not want, like for examples
the available windows. KWin internal windows either have direct access
to KWin or a scripting interface exposed providing (limited) access -
there is just no need to have this in KWindowSystem.
To make it more clear what KWin supports as API of KWindowSystem for
internal windows this change implements a stripped down version of the
kwayland-integration plugin. The main difference is that it does not use
KWayland at all, but a QWindow internal side channel.
To support this EffectWindow provides an accessor for internalWindow and
the three already mentioned effects are adjusted to read from the
internal QWindow and it's dynamic properties.
This change is a first step for a further refactoring. I plan to split
the internal window out of ShellClient into a dedicated class. I think
there are nowadays too many special cases. If it moves out there is the
question whether we really want to use Wayland for the internal windows
or whether this is just historic ballast (after all we used to use
qwayland for that in the beginning).
As the change could introduce regressions I'm targetting 5.16.
Test Plan:
new test case for window type, manual testing using Alt+Tab
for the effects integration. Sliding popups, blur and contrast worked fine.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18228
Summary:
7834bec52a missed to port minimize and
unminimize to dynamic dispatch. In addition to that, we don't benefit
from QMetaObject::invokeMethod so port addRepaint and addLayerRepaint
to dynamic dispatch as well.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18049
Summary:
Some effects may release the current context when they tear down, so we
have to make the current context per each unloaded effect.
BUG: 396830
FIXED-IN: 5.15.0
Test Plan: No longer able to reproduce bug 396830.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D17716
Summary:
qobject_cast has several advantages over dynamic_cast:
* it works without RTTI;
* it's usually faster.
Also, when it comes to casting QObjects, qobject_cast is de facto
standard.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D17427
Summary:
We use a function template, so static_cast in getMainWindows looks out
of place. Also, it's not good idea to do static_cast based on output of
isDeleted().
Test Plan: The Dialog Parent effect works.
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D17426
Summary:
Compositing is suspended/finished in a very hard way fashion, effect
windows are destroyed without notifying effects about it.
AnimationEffect tries gracefully release deleted windows, but because
in some cases(like when suspending compositing) a deleted window can
be already destroyed, a segmentation fault can happen.
This change adjusts the order in which effect windows and effects are
destroyed, so AnimationEffect (and other effects) cannot access dangling
pointers.
BUG: 400788
FIXED-IN: 5.15.0
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: graesslin, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D17311
Summary:
EffectsHandlerImpl::unloadAllEffects can be very useful when writing
tests, e.g.:
auto effectsImpl = qobect_cast<EffectsHandlerImpl *>(effects);
QVERIFY(effectsImpl);
effectsImpl->unloadAllEffects();
QVERIFY(effectsImpl->loadEffect(QStringLiteral("kwin5_effect_foobar")));
but because unloadAllEffects doesn't clean up effect_order, the old
effects can be re-added back into loaded_effects when a new effect is
loaded. Such behavior can result in a segfault.
Test Plan: Existing tests pass.
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D17283
Summary:
EffectWindow proxies its properties from the client/deleted's
properties.
QObject::property(char*) is a slow string search. It's a loop
of string comparisons not a hash lookup!
QML's use of properties is different, there's a property cache.
It's fetched multiple times for every window in every paint of some
effects (such as blur). Hotspot shows this as a significant amount of
the render pass (X11) with nothing in kwin animating.
This patch replaces the macro that does
parent()->property("propertyName")
with a macro calling the relevant function directly without metaobjects.
This also improves type safety for future changes.
Test Plan:
Existing unit tests
Ran it for a bit
Reviewers: #kwin, graesslin
Subscribers: graesslin, zzag, broulik, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16602
Summary:
As setDesktop was changed to "move" this left unSetDesktop non-symetric.
This replaces it with explicit API to enter/leave.
This also moves new API to the new object based API rather than still
using ints.
Where numbers are used it has been tidied up so that desktop IDs are
uint, which should be used when we have a list of desktops.
int is used only when we have either a desktop ID or NET::OnAllDesktops
(-1)
Effects API cleared up to use this and use a set of x11 IDs, which
avoids any potential complications of handling add and removes any
ambiguity with what happens if you leave all desktops and such.
Test Plan:
testVirtualDesktops passes (with pending kwayland patch)
Moving a window in the desktop grid on X11 behaves
Moving a window in the desktop grid on wayland behaves
Reviewers: #kwin, zzag
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16704
Summary:
implement virtual desktop support for Wayland.
use the new virtual desktop protocol from D12820
The VirtualDesktopManager class needed some big change in order
to accomodate it, which is where most changes are.
Other than that, it's mostly connections to wire up
VirtualDesktopsManager and VirtualDesktopsManagement(the wayland protocol impl)
Depends on D12820
Other notable detail, is the client visibility updated to reflect the presence
of the client in the plasmavirtualdesktop.
(and the unSetDesktop concept)
Test Plan: used a bit a plasma session together with D12820, D13748 and D13746
Reviewers: #plasma, #kwin, graesslin, davidedmundson
Reviewed By: #plasma, #kwin, davidedmundson
Subscribers: hein, zzag, davidedmundson, kwin
Tags: #kwin
Maniphest Tasks: T4457
Differential Revision: https://phabricator.kde.org/D13887
Summary:
If the animation speed was changed, then EffectsHandler will be destroyed
and created again.
Because we don't create connections to monitor state of Wayland clients
in EffectsHandler constructor, effects like the Magic lamp won't work
after changing compositor settings.
BUG: 400240
Test Plan:
* Changed animation speed;
* Minimized a Wayland client.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16401
Summary:
In some cases, the out transition is false-triggered because we don't
react to changes in the keep-above and the full screen state.
Test Plan:
* Set the keep-above state on a window;
* Click on the desktop;
* (the window didn't "flicker")
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, abetts, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16270
Summary:
Getter is exposed as a property on scripted effect in a way that hides
pointers from the scripting side.
Setter is implicitly handled as a property of newly created animations
and holds the activeFullScreenEffect whilst any of them are active. Like
existing effects it remains up to the effect author to avoid the
problems of multiple full screen effects. The RAII lock pattern is
somewhat overkill currently, but it's the direction I hope we can take
EffectsHandler in next API break.
BUG: 396790
--
This patch is against the QJSEngine port, though it's not conceptually a
requirement.
Test Plan: Unit test
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D14688
Summary: These two should have been in D13821 but I missed them somehow.
Test Plan:
* Ran `qdbus org.kde.KWin /Effects loadedEffects`
* Ran the following Python script
```lang=python
import dbus
bus = dbus.SessionBus()
effects_object = bus.get_object('org.kde.KWin', '/Effects')
effects_iface = dbus.Interface(
effects_object,
dbus_interface='org.kde.kwin.Effects'
)
names = (
'slide',
'pizza',
'cube'
)
supported_statuses = effects_iface.areEffectsSupported(names)
for name, supported in zip(names, supported_statuses):
print("%s: %s" % (name, supported))
```
Got the following output:
```
slide: 1
pizza: 0
cube: 1
```
Reviewers: #kwin, mart
Reviewed By: #kwin, mart
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D14002
Summary: Don't use raw loop, use an algorithm from STL to copy effect pairs.
Test Plan: Effects are still working.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D14004
Summary:
Don't use raw loops. Use appropriate algorithm from STL to find out
whether effect with the given name is loaded.
(also, this change deletes duplicated logic)
Reviewers: #kwin, broulik, romangg
Reviewed By: #kwin, broulik, romangg
Subscribers: broulik, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D13836
Summary:
The `role` hash key is hashed twice:
* first, when calling `contains` method;
* second, when using `operator[]`.
We can do better by using [QHash::value](http://doc.qt.io/qt-5/qhash.html#value).
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: pino, davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D13820
Summary:
Don't use raw loops, instead, use appropriate algorithm from STL to map
a list of toplevels to a list of EffectWindow.
Test Plan:
Tested Cover switch, Flip switch, Dialog parent, and Dim inactive effect.
They all still work.
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: graesslin, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D13821
Summary:
Behaviour of some effects depends on presence of active fullscreen effect.
For example, Dim Inactive effect brightens windows if there is an active
fullscreen effect. If active fullscreen effect has been changed, these effects
might need to do some setup work, e.g. schedule repainting, toggle direction
of a timeline, etc.
For what it's worth, because the Dim Inactive effect doesn't schedule
repainting after leaving Desktop Grid, windows aren't dimmed back. One
need to move mouse to trigger dimming.
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D13701
Summary:
The Platform API is extended by a call to create the EffectsHandler. In
X11 standalone Platform a new EffectsHandlerImplX11 is added which
contains the X11 only parts of the EffectsHandler, such as grabbing the
X keyboard and the X11 mouse interception window.
The EffectsHandlerImpl gains some virtual methods for the parts which
are now done in the X11 specific implementation. In return we get rid of
lots of if-else structures checking for the operation mode.
Test Plan: Only compile tested.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7955
Summary:
If an Effect has replaced the TabBox and wants to react on mouse events
the EffectsHandlerImpl also has an X11Filter, so we only need to make
sure the events go to that filter.
Motion: TabBox did not filter out, so events will go to the Effects
filter.
Press/Release: TabBox should not operate if Effects take the events.
The events are filtered out by Effects if there is a grab, so just
check for that and go out. Effects will take care.
Test Plan: Compiles
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7846
Summary:
So far both Workspace and Toplevel emitted signals for every property
notify event on the root window and the respective Toplevel windows. The
signals were only used in EffectsHandlerImpl to forward to the effect
system in case the property which changed is registered by an effect.
This change introduces a dedicated event filter for this which is only
created in EffectsHandlerImpl in case an X11 connection is available. It
supports a restart of the X11 system.
The signals used so far are removed from Workspace and Toplevel.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7853
Summary:
Should be when there is no more an effect which overrides the cursor,
not unconditionally.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7845
Summary:
This change introduces a dedicated X11EventFilter for the mouse
interception on X11. The filter gets created together with the start
of mouse interception and destroyed again when the mouse interception
ends. Thus we don't need to check for each event like it was the case
so far.
Unfortunately the existing methods cannot be removed (yet) as they are
still used by TabBox. Needs investigation whether this is actually
needed.
Test Plan: Xephyr+kwin_x11+Present Windows
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7842
Summary:
Several effects announce a support property atom on the root window. This
change forwards the KWin::Application's signal that the xcbConnection
changed to the EffectsHandler so that the effects can respond to it.
All effects which announce a support property connect to this new signal
and re-announce the property. In case the xcb connection died (future
XWayland crashing case) it is set to XCB_ATOM_NONE by that. In case the
xcb connection got created (future delayed XWayland startup) the atom is
set to the proper value.
In addition all usages of the support properties are guarded, so that no
nonesense actions are performed if the support property is XCB_ATOM_NONE.
Test Plan: Only compile tested as we don't have XFree KWin yet
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7761
Summary:
Read(Window)Property and deleteProperty should only operate if there is
an X11 connection available.
In addition the methods are changed to the x11 wrappers provided on the
KWin::Application as that one can support restarting XWayland in opposite
to the global methods.
Test Plan: Compiles
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7651
Summary:
KWin::displayWidth and KWin::displayHeight are bound to X11 which
doesn't make much sense on X11. In addition KWin internally knows
the overall display dimensions through the Screens singleton class.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D1798
Summary:
announceSupportProperty is called from the effects on startup. It
registers the property on the X11 root window. If we would start
kwin_wayland without XWayland support this would result in a crash.
This change refactors the code so that it still registers the property,
but does not try to interact with X11. Once X11 support is available it
does the actual registering.
But this means that the effects get an incorrect atom returned. This
needs additional changes. E.g. they could also react to the
x11ConnectionChanged and register again, then they would get the proper
atom. This would also support restart of XWayland.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7475
Summary:
So far EffectsHandlerImpl directly accessed SceneQPainter::painter
through a dynamic cast. If in future the QPainter based compositor should
be moved into a plugin we cannot access it through a dynamic cast.
To solve this problem the painter method is moved into Scene as
a virtual method returning a sane default value.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D7214
Summary:
So far EffectsHandlerImpl directly accessed SceneXrender::bufferPicture
through a dynamic cast. If in future the XRender based compositor should
be moved into a plugin we cannot access it through a dynamic cast.
To solve this problem the bufferPicture method is moved into Scene as
a virtual method returning a sane default value.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7207
Summary:
With qtbase 2b34aefcf02f09253473b096eb4faffd3e62b5f4 we do no longer get
events reported for the X11 root window. Our keyboard handling in effects
like PresentWindows and DesktopGrid relied on that.
This change works around the regression by calling winId() on
qApp->desktop() as suggested in the change. This is a short term solution
for the 5.10 branch.
This needs to be addressed properly by no longer relying on Qt in this
area. KWin already does not rely on Qt for Wayland in that area and is
able to compose the QKeyEvents. This should also be done on X11. It just
needs some more hook up code for xkb, but that's needed anyway to improve
modifier only shortcuts and friends.
BUG: 360841
FIXED-IN: 5.10.3
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D6258
Vlad Zahorodnii
David Edmundson
Kai Uwe Broulik
Frederik Gladhorn
Martin Flöser