KWin merge requestshttps://invent.kde.org/plasma/kwin/-/merge_requests2024-02-19T12:08:17Zhttps://invent.kde.org/plasma/kwin/-/merge_requests/5035Draft: tabbox: Unset pointer focus when grabbing input2024-02-19T12:08:17ZVlad ZahorodniiDraft: tabbox: Unset pointer focus when grabbing inputWhen the tabbox is active, it grabs all pointer input, no new pointer
position is going to be reported to SeatInterface. But the tabbox also
doesn't reset the pointer focus. So from the client perspective, it looks
like nothing has occur...When the tabbox is active, it grabs all pointer input, no new pointer
position is going to be reported to SeatInterface. But the tabbox also
doesn't reset the pointer focus. So from the client perspective, it looks
like nothing has occurred.
The tabbox needs to send a wl_pointer.leave event when it's activated
and wl_pointer.enter event when it's deactivated to report the new
position of the pointer.
As a short-term solution, this change makes the tabbox call setFocus()
and update() directly, but such focus handling indicates that we need
proper abstractions for grabs. Input event filters have their place in
the input event pipeline but they are not the replacement for grabs.
BUG: 4800996.1Vlad ZahorodniiVlad Zahorodniihttps://invent.kde.org/plasma/kwin/-/merge_requests/4708Enable spare keyboard layouts in Wayland2024-03-12T07:45:34ZMihail MilevEnable spare keyboard layouts in WaylandThis MR enables the spare layouts functionality in Wayland as we know it from X11. Enabling this functionality was previously discussed [in the following MR](https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1722) and is thus...This MR enables the spare layouts functionality in Wayland as we know it from X11. Enabling this functionality was previously discussed [in the following MR](https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1722) and is thus the next step of what was discussed there.
The spare layout functionality in short: when enabled the user has a set of main layouts, which can be toggled with the normal keyboard shortcuts (the XKB one and the alternative one). Then there is a set of one or more additional layouts, which can only be activated either by a dedicated shortcut, or by clicking on the layout in the tray icon. Once a spare layout is chosen, it replaces the last layout from the main set.
Example:
Main layouts: EN, DE, ES
Spare layouts: BG, JP
Usually the toggled layouts will be: EN -> DE -> ES -> EN -> DE -> ES -> EN, etc.
If JP gets selected the toggle will be: EN -> DE -> JP -> EN -> DE -> JP -> EN, etc.
If then BG gets selected the toggle will be: EN -> DE -> BG -> EN -> DE -> BG -> EN, etc.6.1https://invent.kde.org/plasma/kwin/-/merge_requests/4646Do not set gamma if the lut size is zero2023-12-20T05:56:50ZChaojiang LuoDo not set gamma if the lut size is zerodrmModeCrtcSetGamma get failed for lut size is 0. So do not
need to set gamma if lut size is 0.drmModeCrtcSetGamma get failed for lut size is 0. So do not
need to set gamma if lut size is 0.https://invent.kde.org/plasma/kwin/-/merge_requests/4619Use fadingpopups for when tooltips change geometry. Retain morphingpopups for...2023-11-09T19:39:36ZBharadwaj RajuUse fadingpopups for when tooltips change geometry. Retain morphingpopups for notifications.There are a lot of bugs and glitches with using Morphing Popups with
tooltips, especially on Wayland. (Several of: https://bugs.kde.org/buglist.cgi?quicksearch=morphing&list_id=2510435)
Disabling Morphing Popups would solve those glitch...There are a lot of bugs and glitches with using Morphing Popups with
tooltips, especially on Wayland. (Several of: https://bugs.kde.org/buglist.cgi?quicksearch=morphing&list_id=2510435)
Disabling Morphing Popups would solve those glitches, but cause tooltip switching to become jumpy and abrupt. This change makes it look smooth even without Morphing Popups.
Morphing Popups is still retained for use with notifications, as it looks good
there and I don't think there are any glitches with it like with tooltips.https://invent.kde.org/plasma/kwin/-/merge_requests/4349workspace: Don't activate desktop window when it gets added2023-11-16T13:19:23ZKai Uwe Broulikworkspace: Don't activate desktop window when it gets addedUnless there is no focus window. Matches X11 behavior.
Otherwise (re)starting plasmashell would pull focus away from
whatever window is currently focussed.
---
Restarted plasmashell, my terminal didn’t lose focus anymore.
The `X11Win...Unless there is no focus window. Matches X11 behavior.
Otherwise (re)starting plasmashell would pull focus away from
whatever window is currently focussed.
---
Restarted plasmashell, my terminal didn’t lose focus anymore.
The `X11Window` code actuallly does:
```
if (activeWindow() == nullptr && should_get_focus.count() == 0) {
activateWindow(findDesktop(true, VirtualDesktopManager::self()->currentDesktop()));
}
```https://invent.kde.org/plasma/kwin/-/merge_requests/4065decoration: Delay notifying of active state until window submits a new frame2023-10-26T07:16:07ZDavid Redondodecoration: Delay notifying of active state until window submits a new frameThis enables us to have matching colour changes of decoration and client.
BUG:433569
before at 10% speed:
![broken](/uploads/c65040f509e5aa9b6a6c276628cd6fdd/broken.webm)
after at 10% speed:
![fixed](/uploads/baa220d48e8e036c8cb7cd4...This enables us to have matching colour changes of decoration and client.
BUG:433569
before at 10% speed:
![broken](/uploads/c65040f509e5aa9b6a6c276628cd6fdd/broken.webm)
after at 10% speed:
![fixed](/uploads/baa220d48e8e036c8cb7cd4343d592a8/fixed.webm)https://invent.kde.org/plasma/kwin/-/merge_requests/3794Custom Tiling: Check interactiveMoveResizeGravity state before unsnapping win...2024-02-06T00:09:48ZBlazer SilvingCustom Tiling: Check interactiveMoveResizeGravity state before unsnapping window from gridFixes BUG: 466451
Client-side Decorations in Chromium/Chrome windows cause them to lose snapping when interacting with their headers. This occurs with both quick and custom tiling, after the changes for the new feature were released.
H...Fixes BUG: 466451
Client-side Decorations in Chromium/Chrome windows cause them to lose snapping when interacting with their headers. This occurs with both quick and custom tiling, after the changes for the new feature were released.
Have only been able to replicate the issue in Chromium, Firefox windows with similar decorations do not encounter the issue. Other applications that use client-side window decorations (CSD) may be affected as well, does anyone know of any to test with?
After running the fix with two weeks of normal desktop usage, I haven't found it to adversely affect tiling for other windows, everything snaps and unsnaps to quick and custom grids as expected.https://invent.kde.org/plasma/kwin/-/merge_requests/3581Fixes #465600 - TypeError: Cannot read property 'skipTaskbar' of undefined2023-10-30T20:37:49ZArchi NaxFixes #465600 - TypeError: Cannot read property 'skipTaskbar' of undefinedFixes a Javascript TypeError when hovering over and off (showing / hiding) a taskbar
BUG: 465600Fixes a Javascript TypeError when hovering over and off (showing / hiding) a taskbar
BUG: 465600https://invent.kde.org/plasma/kwin/-/merge_requests/3248x11window: Allow unmaximizing fixed size maximized windows.2022-11-30T10:50:31ZZhiyi Zhangx11window: Allow unmaximizing fixed size maximized windows.For example, when Wine unmaximizes a window without resize borders, it sets the window size hints to
indicate that the window is a fixed size window. Then Wine will send a ClientMessage asking KWin to
remove _NET_WM_STATE_MAXIMIZED_VERT/...For example, when Wine unmaximizes a window without resize borders, it sets the window size hints to
indicate that the window is a fixed size window. Then Wine will send a ClientMessage asking KWin to
remove _NET_WM_STATE_MAXIMIZED_VERT/HORZ. If KWin rejects the unmaximization because the window is
fixed size, then _NET_WM_STATE_MAXIMIZED_VERT/HORZ are not removed and Wine will read _NET_WM_STATE
upon receiving events and then maximize the same window it tried to unmaximize.
Although Wine can work around this issue by removing the size hints before sending the ClientMessage
to remove _NET_WM_STATE_MAXIMIZED_VERT/HORZ, it's not robust because of the cross-process nature of
ClientMessage handling. By the time the ClientMessage is handled, the window can still be fixed size.https://invent.kde.org/plasma/kwin/-/merge_requests/3233backends/wayland: Fix running with a different scale than the host compositor2023-01-13T12:01:19ZArjen Hiemstrabackends/wayland: Fix running with a different scale than the host compositorWe want the surface sent to the host to have a size that matches our
local device size, not something that's different, otherwise we end up
with incorrect window sizes.
The second commit ensures the mouse position sent from the host is ...We want the surface sent to the host to have a size that matches our
local device size, not something that's different, otherwise we end up
with incorrect window sizes.
The second commit ensures the mouse position sent from the host is properly converted to logical coordinates so mouse positions are handled correctly.Arjen HiemstraArjen Hiemstrahttps://invent.kde.org/plasma/kwin/-/merge_requests/3186input: fix touch input getting borked on internal window close when touched2022-11-21T08:19:47ZAmphetamine Weiinput: fix touch input getting borked on internal window close when touchedIf the internal window close but still touch, internalPressId will never be reset.
So we reset internalPressId if the id of new touch sequence is same as internalPressId.
I don't know if doing this is a better option:
```C++
bool Inter...If the internal window close but still touch, internalPressId will never be reset.
So we reset internalPressId if the id of new touch sequence is same as internalPressId.
I don't know if doing this is a better option:
```C++
bool InternalWindowEventFilter::touchUp(qint32 id, const QPointF &pos, quint32 time)
{
...
if (!input()->touch()->focus() || !input()->touch()->focus()->isInternal()) {
// reset InternalPressId if focus() close or focus() is no longer internal
m_lastGlobalTouchPos = QPointF();
m_lastLocalTouchPos = QPointF();
input()->touch()->setInternalPressId(-1);
return removed;
}
...
}
```https://invent.kde.org/plasma/kwin/-/merge_requests/3161Xorg: Swipe + Pinch Gestures2022-11-04T11:34:41ZNekobitme@ow.nekobit.netXorg: Swipe + Pinch GesturesThis is a (temporary) implementation for gestures, which are well seen in the Wayland session. It is done because Wayland still has issues on certain devices, specifically my own.
Bare in mind that it appears that the Xorg components ne...This is a (temporary) implementation for gestures, which are well seen in the Wayland session. It is done because Wayland still has issues on certain devices, specifically my own.
Bare in mind that it appears that the Xorg components need a refactor for the new InputDevice class, which use a class instead of a plain QObject. So I consider this a "hack" just to get Swipe gestures working.
Bugs:
- GTK applications (possibly others?) seem to eat Gesture inputs, I'm at a stump for this one as it's late
- Pinches do not work, but events are recognized and run-through. Results from XInput2 structs seem large but correct, but I'm not all too familiar with the API or the results that work under the hood are expecting.
I would appreciate any help on these issues.https://invent.kde.org/plasma/kwin/-/merge_requests/3108MinimizeAll - Restore Focus2022-11-15T21:46:00ZJoshua WeinerMinimizeAll - Restore FocusMinimizeAll
Restored focus upon undo minimize-all windows
```js
for (var i = 0; i < relevantClients.length; ++i) {
var wasMinimizedByScript = relevantClients[i].minimizedByScript;
delete relevantClients[i].minimizedByScript;
...MinimizeAll
Restored focus upon undo minimize-all windows
```js
for (var i = 0; i < relevantClients.length; ++i) {
var wasMinimizedByScript = relevantClients[i].minimizedByScript;
delete relevantClients[i].minimizedByScript;
var wasActiveWindow = relevantClients[i].isActiveWindow;
delete relevantClients[i].isActiveWindow;
if (minimize) {
if (relevantClients[i].minimized) {
continue;
}
relevantClients[i].isActiveWindow = Boolean(relevantClients[i].active);
relevantClients[i].minimized = true;
relevantClients[i].minimizedByScript = true;
} else {
if (!wasMinimizedByScript) {
continue;
}
relevantClients[i].minimized = false;
if (wasActiveWindow) {
workspace.activeClient = relevantClients[i];
}
}
}
```
The previous attempt (22b7ac02b4b1cefde6c8bc544c9012c520a233de) to create this feature is unstable.
@teams/usability
@teams/qa5.26ivan tkachenkoivan tkachenkohttps://invent.kde.org/plasma/kwin/-/merge_requests/3065Draft: By default, allow dragging windows between desktops using screen edges2024-02-17T20:04:48ZNate GrahamDraft: By default, allow dragging windows between desktops using screen edgesKWin has a feature to let you drag windows between virtual desktops
when you drag them to a screen edge, but it's disabled by default. In
my testing, this works really well, and it's a nice intuitive usability
feature, so I think it make...KWin has a feature to let you drag windows between virtual desktops
when you drag them to a screen edge, but it's disabled by default. In
my testing, this works really well, and it's a nice intuitive usability
feature, so I think it makes sense to turn it on by default.
@teams/usability6.1https://invent.kde.org/plasma/kwin/-/merge_requests/3032[libinput] Improve touchscreen->output mapping heuristic2022-11-21T12:31:27ZNicolas Fella[libinput] Improve touchscreen->output mapping heuristicOur heuristic relies on knowing the physical sizes of the touchscreen and monitor.
However, not all monitors report a physical size, which makes it hard to map the touchscreen correctly.
Given a setup where we have one internal screen ...Our heuristic relies on knowing the physical sizes of the touchscreen and monitor.
However, not all monitors report a physical size, which makes it hard to map the touchscreen correctly.
Given a setup where we have one internal screen with known size, and an external display/touchscreen combination with unknown size we currently wrongly map the external touchscreen to the internal display.
However, in this case we know that this mapping is wrong since the size of the internal monitor and the touchscreen doesn't match. By then assigning the touchscreen to the other remaining display we can get the correct result
CCBUG: 411877https://invent.kde.org/plasma/kwin/-/merge_requests/2786focus chain/scripting: Make list of most recently used windows public, and ex...2024-02-14T12:36:19ZNatalie Clariusnatalie_clarius@yahoo.defocus chain/scripting: Make list of most recently used windows public, and expose recently used and stacking order client lists in scripting APIIt would be useful to have the list of windows in the order of recent usage available in the scripting API, rather than just `allClientList`. This would make it possible to e.g. in the minimize-all widget more reliably restore the window...It would be useful to have the list of windows in the order of recent usage available in the scripting API, rather than just `allClientList`. This would make it possible to e.g. in the minimize-all widget more reliably restore the windows in the correct order. I also have a use case for this in my [Window Overlap Prevention](https://github.com/nclarius/floating-tiles) script, where I want to reactivate the most recently used window after restoring some minimized ones.
Make the focus chain's list of recently used windows public, and use this as the `clientList` in the scripting workspace wrapper.
- I am unsure if there is some architectural reason why making the focus chain's recently used windows list as a whole accessible from outside was not done in the first place, and piecing it together from the provided `nextMostRecentlyUsed` like tabbox does it is the way to go?
- Would it be better to keep the scripting's current `clientList`, and instead add the list of windows in most recently used order (and while at it, another one in stacking order) as separate functions? I can't really think of a scenario where changing the client list to be ordered by recent usage would break existing scripts' functionality, and if I understand correctly, introducing it as a new feature would make it factually unusable for a long time if script developers want to ensure that their script works with older Plasma versions.
BUG: 4098896.1https://invent.kde.org/plasma/kwin/-/merge_requests/2760effects: Better fix for keeping dragged things on top and hiding highlight2022-08-23T09:45:14Zivan tkachenkoeffects: Better fix for keeping dragged things on top and hiding highlightNow there is an explicit hierarchy of properties for bubbling up and
down the current shared state of "whether there is something being
dragged on a scene right now?"
Ideally we could have a special QML type like ButtonGroup which would...Now there is an explicit hierarchy of properties for bubbling up and
down the current shared state of "whether there is something being
dragged on a scene right now?"
Ideally we could have a special QML type like ButtonGroup which would
keep track of a value equivalent to an expression:
any(a.active for a in attachedObjects)
which could then be chained up and the final result passed down. But for
(to the best of my knowledge) now no such component exist, so it much be
done manually and dirty.5.26ivan tkachenkoivan tkachenkohttps://invent.kde.org/plasma/kwin/-/merge_requests/2237Support using LayerShell as input panel client2022-05-17T12:00:29ZArjen HiemstraSupport using LayerShell as input panel clientInputPanelV1Client is unfortunately rather limited. Most importantly,
it does not provide any way to control the positioning of the client
other than "overlay" or "toplevel". This creates issues when we need
to do things like moving the ...InputPanelV1Client is unfortunately rather limited. Most importantly,
it does not provide any way to control the positioning of the client
other than "overlay" or "toplevel". This creates issues when we need
to do things like moving the input panel so it doesn't overlap plasma
panels. Fortunately, the layer-shell protocol does provide all that
and it seems more suitable for the "toplevel" type of keyboard in
general.
This changes InputMethod so it does not care too much about which
type of client we use. It also changes layer shell client to
interpret clients with the scope set to "input-panel" as
actual input panels.
Unfortunately, just switching to layer-shell doesn't fix all our problems. The second commit makes InputMethod reposition and resize the input client when it's using layer-shell to account for Plasma panels. To me this seems the most reasonable short-term solution, as I can see no way to make layer-shell clients handle that information without introducing a circular dependency and porting Plasma itself to use layer-shell for panels is also a lot of work.Arjen HiemstraArjen Hiemstrahttps://invent.kde.org/plasma/kwin/-/merge_requests/2219[wayland] initial cursor pos on primary screen2023-11-09T12:05:09ZMartin Seher[wayland] initial cursor pos on primary screenNow that primary output exists it seems to be a better choice for
initial cursor position instead of the screen containing the workspace
center.Now that primary output exists it seems to be a better choice for
initial cursor position instead of the screen containing the workspace
center.https://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.26