KWin merge requestshttps://invent.kde.org/plasma/kwin/-/merge_requests2022-08-19T12:18:49Zhttps://invent.kde.org/plasma/kwin/-/merge_requests/2184Draft: Contextual Behavior System2022-08-19T12:18:49ZEric Edlundericedlund2017@gmail.comDraft: Contextual Behavior SystemThis MR is being split up to make review easier.
**New System for Contextual Behavior**
Any place the user can be (overview effect, desktop grid, etc) registers a `Context` object with the system. These contexts are centrally managed a...This MR is being split up to make review easier.
**New System for Contextual Behavior**
Any place the user can be (overview effect, desktop grid, etc) registers a `Context` object with the system. These contexts are centrally managed and will later have a KCM dedicated to them. In different contexts, different Gestures can be bound. This allows us to have to have swipe up open overview in the `DEFAULT_CONTEXT` but swipe down close it in the overview context.
There can be multiple `ContextInstances` for one `Context`, each with different bindings and behaviors.
`Context` objects have callbacks that tell them when to activate and drive their animation. By driving the animations centrally, we can force Contexts to animate synchronously, creating awesome transitions with uniform easing curves and speed. This also makes effect code simpler. The `Context` object also provides the animation direction so that theoretically effects could trigger differently depending on what gesture opens them.
This system also makes it possible for us to behave like Gnome does, where you can swipe down once to do something, then swipe down again and have an app drawer.
The new `Action` object is like a QAction that supports gestures. The VirtualDeskotpManager registers two Actions to switch desktops, one to switch respecting the 2d nature of the grid, and one to go next/previous. Those two actions can be bound in different contexts; we can switch respecting the grid in the `DEFAULT_CONTEXT` but also respect how Overview presents the desktops in the overview context. Later, we can create an `Action` to trigger the clear desktop effect. All this will be completely configurable once the KCM is finished.
****
**Overview of changes:**
- In globalshortcuts.h/cpp all the Context stuff is handled.
- Slide and desktop fade effect don't capture activeFullscreenEffect anymore.
- In gesture.h/cpp and globalshortcuts.h/cpp I've merged a lot of enums/structs
- Changes in gesture.h/cpp from taking a range of finger counts to a list of ints.
-
- Adapt Overview, Desktopgrid and WindowView to this system. This included:
- Making all animations driven by the `EffectContext` object
- Closing/Opening the effect only in response to calls from the `EffectContext` object
- Routing activation requests to the `EffectContext` object instead of acting on them directly
- Using the state() in `EffectContext` instead of their own status variable
- Removing touchscreen border activation code because touchscreen borders are now centrally handled
- `activeFullscreenEffect` is only captured after an `EffectContext` is `activated()` and released immediately after being `deactivated()`
- I've moved a lot of stuff into the common base kwinquickeffect.h/cpp from these effects
Specific concerns I have for code review:
- My personal inadequacy in memory management
- In reworking the effects to this new system, it's very possible I've broken something
Related to #59
BUG: 4542465.26https://invent.kde.org/plasma/kwin/-/merge_requests/2435effects/screenedge: Port to OffscreenQuickScene2022-10-28T07:10:53ZKai Uwe Broulikeffects/screenedge: Port to OffscreenQuickSceneThis makes the painting code simpler and more declarative.
More importantly, it allows to remove the build-time dependency
on plasma-framework from KWin effects.
The only remaining user of Plasma-Framework C++ API in KWin is now
the scr...This makes the painting code simpler and more declarative.
More importantly, it allows to remove the build-time dependency
on plasma-framework from KWin effects.
The only remaining user of Plasma-Framework C++ API in KWin is now
the screenedges KCM for its monitor graphic.
---
All eight screen edges have been verified to render virtually identical as before.
There is an unrelated issue where `edgeApproaching` isn't emitted on X11 before the edge is actually hit with the mouse, breaking the fade-in. This is unrelated to this change, however.
Kai Uwe Broulik <kai_uwe.broulik@mbition.io> on behalf of MBition GmbH
https://github.com/mercedes-benz/foss/blob/master/PROVIDER_INFORMATION.mdhttps://invent.kde.org/plasma/kwin/-/merge_requests/2558Introduce RenderOutput2024-02-14T13:31:35ZXaver HuglIntroduce RenderOutputRenderOutput replaces Output for rendering matters, to support tiled displays and cloning better.
Split out of !1174 to make rebasing and reviewing less cumbersome
also related: #78. With this merged + a few additional bits, the drm ba...RenderOutput replaces Output for rendering matters, to support tiled displays and cloning better.
Split out of !1174 to make rebasing and reviewing less cumbersome
also related: #78. With this merged + a few additional bits, the drm backend could create a single `RenderOutput` for multiple real outputs, increasing efficiency6.1Xaver HuglXaver Huglhttps://invent.kde.org/plasma/kwin/-/merge_requests/3047wayland: convert most manual or QObject memory management to std::unique_ptr2024-02-14T13:38:01ZXaver Huglwayland: convert most manual or QObject memory management to std::unique_ptrIn a few places it was not obvious who is supposed to own the created objects or in which order they need to be destroyed. That's not completely fixed yet, but `Display` is now at least more explicitly destroyed before interface extensio...In a few places it was not obvious who is supposed to own the created objects or in which order they need to be destroyed. That's not completely fixed yet, but `Display` is now at least more explicitly destroyed before interface extensions.
There also were some places where manual management could be very easily replaced 1:1 with `std::unique_ptr`, and there were a lot of `CLEANUP` macros in the autotests that did what `std::unique_ptr` is for.6.1https://invent.kde.org/plasma/kwin/-/merge_requests/3056wayland: split some interface and private lifetimes2024-02-14T13:39:36ZXaver Huglwayland: split some interface and private lifetimesMakes things a bit simpler. Deleting the interface removes the global, and the private part lives on until the global gets deleted.Makes things a bit simpler. Deleting the interface removes the global, and the private part lives on until the global gets deleted.6.1https://invent.kde.org/plasma/kwin/-/merge_requests/3204xwayland, session management: use more modern C++2024-02-14T13:44:48ZXaver Huglxwayland, session management: use more modern C++6.1https://invent.kde.org/plasma/kwin/-/merge_requests/3310Remove m_quickTileMode and base only on tiles2024-03-25T17:04:31ZMarco MartinRemove m_quickTileMode and base only on tilesThis removes the tracking member and uses the tile information,
removing a duplication of data and source of truthThis removes the tracking member and uses the tile information,
removing a duplication of data and source of truth6.1https://invent.kde.org/plasma/kwin/-/merge_requests/3897backends, workspace: make backends exclusively own outputs again2024-02-14T12:52:41ZXaver Huglbackends, workspace: make backends exclusively own outputs again6.1https://invent.kde.org/plasma/kwin/-/merge_requests/4304libkwineffects: refactor GLFramebuffer2024-02-14T13:03:21ZXaver Hugllibkwineffects: refactor GLFramebufferSee the commits for the exact changes, but this mostly aligns `GLFramebuffer` to how `GLTexture` works. It also allows `GLFramebuffer` to directly keep a `GLTexture` internally - so the code keeping both around as a pair doesn't have to ...See the commits for the exact changes, but this mostly aligns `GLFramebuffer` to how `GLTexture` works. It also allows `GLFramebuffer` to directly keep a `GLTexture` internally - so the code keeping both around as a pair doesn't have to be duplicated everywhere across the code base6.1https://invent.kde.org/plasma/kwin/-/merge_requests/4815Move some output stuff to more fitting places2024-01-25T08:48:05ZXaver HuglMove some output stuff to more fitting placesTaken out of !4800. See the individual commits for detailsTaken out of !4800. See the individual commits for details6.1https://invent.kde.org/plasma/kwin/-/merge_requests/5052Draft: Introduce input grabs2024-03-03T10:38:00ZVlad ZahorodniiDraft: Introduce input grabsThere are certain things with exclusive input models, for example
forwarding input events vs tabbox vs xdg-popup grabs, etc. In order to
implement such things, input event filters are used. But their main
disadvantage is that they don't ...There are certain things with exclusive input models, for example
forwarding input events vs tabbox vs xdg-popup grabs, etc. In order to
implement such things, input event filters are used. But their main
disadvantage is that they don't abstract the exclusive nature of such
input models well. The input filters are riddled with brittle focus
handling code. In case of keyboard input, it's even worse.
The input grabs intend to fill in this gap. An input grab is responsible
for handling input. This can be used to forward input to the client, or
properly handle input in the task switcher, or implement different focus
handling strategies in dnd initiated by xwayland and wayland clients, etc.
The input grabs don't replace the event filters.
---
Draft: There are still a few things left to finish:
- [ ] `startGrab()`/`endGrab()` functions, and provide some functions to notify when a grab is replaced by another
- [ ] drop `DecorationEventFilter` and `InternalWindowEventFilter`
- [ ] some generic way to forward input events to windows and decorations so one doesn't need to write a lot of code in every grab. At the moment, it's a mess. To make things worse, we have `Decoration::DecoratedClientImpl`, `InternalWindow`, and `SurfaceInterface` that can accept input. All have different types. It would be nice to have a common denominator. I think `Item` is the best candidate. It also makes sense to reroute input through the scene so it's consistent with the visuals.6.1https://invent.kde.org/plasma/kwin/-/merge_requests/5242Draft: utils/edid: port to higher level libdisplayinfo API for colorimetry in...2024-02-20T15:40:57ZXaver HuglDraft: utils/edid: port to higher level libdisplayinfo API for colorimetry informationDepends on https://gitlab.freedesktop.org/emersion/libdisplay-info/-/merge_requests/167Depends on https://gitlab.freedesktop.org/emersion/libdisplay-info/-/merge_requests/167https://invent.kde.org/plasma/kwin/-/merge_requests/5268remove modifier only shortcuts and migrate config2024-03-28T18:59:17ZYifan Zhuremove modifier only shortcuts and migrate configThis is now implemented in kglobalacceld
BUG: 371560
~~The config migration script is still pending.~~
Depends on https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/4166 for migration of default shortcut.This is now implemented in kglobalacceld
BUG: 371560
~~The config migration script is still pending.~~
Depends on https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/4166 for migration of default shortcut.6.1Yifan ZhuYifan Zhuhttps://invent.kde.org/plasma/kwin/-/merge_requests/5296window: reimplement restriction in moveResize2024-03-21T16:44:45ZYifan Zhuwindow: reimplement restriction in moveResizeIn restricted moveResize, try to guarantee at least a 100px contiguous
block of the titlebar is visible. Previously this was implemented by
shifting the geometry by 1px increments, trying to find a suitable
position. This is inefficient ...In restricted moveResize, try to guarantee at least a 100px contiguous
block of the titlebar is visible. Previously this was implemented by
shifting the geometry by 1px increments, trying to find a suitable
position. This is inefficient and error-prone.
Replace this with an efficient algorithm that finds the closest
candidate position. Consolidate the restriction code and add tests.
BUG: 481610
One remaining issues is that in multi-monitor setups, `workspace()->restrictedMoveArea()` does not include the invisible area caused by the misalignment of the screens.6.1Yifan ZhuYifan Zhuhttps://invent.kde.org/plasma/kwin/-/merge_requests/5306xwayland, session management: port trivial stuff to std::unique_ptr2024-02-26T18:06:56ZXaver Huglxwayland, session management: port trivial stuff to std::unique_ptr6.1https://invent.kde.org/plasma/kwin/-/merge_requests/5334Move render time queries into OutputFrame2024-03-08T17:40:52ZXaver HuglMove render time queries into OutputFrameThis way, there can be multiple `OutputFrame`s pending at the same time, without interfering in each other's queries, and without stalling to complete previous frames first. This is a requirement for !4833, and depends on https://invent....This way, there can be multiple `OutputFrame`s pending at the same time, without interfering in each other's queries, and without stalling to complete previous frames first. This is a requirement for !4833, and depends on https://invent.kde.org/plasma/kwin/-/merge_requests/53256.1