Bug 466269

Summary:	Allow configuring the modifier key that must be held down to trigger Custom Tiling
Product:	[Plasma] kwin	Reporter:	alex
Component:	Custom Tiling	Assignee:	KWin default assignee <kwin-bugs-null>
Status:	CONFIRMED ---
Severity:	wishlist	CC:	admin, ajbtz74o, antti.savo, bg_22, fanzhuyifan, miranda, nate, notmart, polak.sidneypolak
Priority:	NOR
Version First Reported In:	5.27.0
Target Milestone:	---
Platform:	openSUSE
OS:	Linux
See Also:	https://bugs.kde.org/show_bug.cgi?id=485152
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description alex 2023-02-22 21:39:14 UTC

SUMMARY
The new Custom Tiling is excellent!  
As a user who uses ALT-drag to move my windows, it could be improved by enabling ALT+SHIFT-drag or [configurable modifier key]-drag.

STEPS TO REPRODUCE
1. Configure as default with Alt as Modifier Key for Move (in Window Behavior>Window Actions)
2. Hold ALT+SHIFT (ALT to move, SHIFT to tile)
3. Click and Drag to move window to tiled position

OBSERVED RESULT
Tiling of the window being moved does not occur if the SHIFT key is pressed prior to beginning the drag.

EXPECTED RESULT
The window should drag to the tiled position if the shift key is pressed down at any stage in the gesture.
It would be more  intuitive for users of default config if it worked this way, rather than requiring ALT > drag > SHIFT > release in that very specific order.
It would also be great if the Window Behaviour>Window Actions settings provided more configuration, like setting the  modifier key or key combo for Move+Tile explicitly : eg Default might be ALT+SHIFT-drag, but user could set to   META-drag.



SOFTWARE/OS VERSIONS

Linux/KDE Plasma: 5.27.0
KDE Plasma Version: 5.27.0
KDE Frameworks Version: 5.103.0
Qt Version: 5.15.8

ADDITIONAL INFORMATION

Comment 1 Sidney 2023-02-25 10:48:56 UTC Comment hidden (spam)

Hi, really appreciate work but to enhance new tiling feature, have some ideas inspired by other systems:
ACTUAL BEHAVIOR:
Generally, window managers allow moving windows by Alt/Meta + LMB (Linux axiom). Modifier isn't needed to end up action (you don't need to hold modifier to move the window, but only trigger moving).

ENHANCEMENT:
Using KZones script, it is possible to set Alt/Meta key as a tiling trigger. 
When both those modifiers are set same (system settings and KZones), usage is so convenient: the same key activates moving and tiling. No combinations with Shift or other. If moving is in progress, holding the modifier triggers tiling.
Especially convenient if such a modifier is remapped to mouse buttons (e.g. MB4 or MB5), so pressing:
MB5 + LMB to drag window, 
MB5 + RMB to resize,
MB5 + MMB to close.
The Shift key as a secondary hard-coded modifier gives another step of complication in such a setup. 

Wrapping up, IMO would be nice: when move window is needed, modifier + LMB triggers moving, but during moving, modifier activates tiling if held.

Comment 2 Nate Graham 2023-02-25 17:10:15 UTC Comment hidden (spam)

Hello, please submit a new bug report for each specific feature request. See https://community.kde.org/Get_Involved/Issue_Reporting#Multiple_issues_in_a_single_Bugzilla_ticket for why. :)

Comment 3 alex 2023-02-26 01:08:52 UTC

Thanks Nate: not sure if the direction to add separate bug reports was directed at my original report, or Sidney's comment, or both?
If you could clarify I'm happy to comply to help?
From my original, would the split be a/ default behaviour with alt-drag, then b/configurable modifier keys as a separate request?

On a first read of Sidney's comment I thought it was tangential, but now I think that it is actually much the same as the (b) part of mine about configuring modifier keys.

Comment 4 Nate Graham 2023-02-27 15:08:58 UTC

It was directed at Sidney. :)

Comment 5 fanzhuyifan 2024-08-14 07:08:58 UTC

*** Bug 491702 has been marked as a duplicate of this bug. ***

Comment 6 Nate Graham 2024-08-22 13:06:18 UTC

*** Bug 485152 has been marked as a duplicate of this bug. ***

Comment 7 Nate Graham 2025-12-08 17:45:27 UTC

*** Bug 513081 has been marked as a duplicate of this bug. ***

Comment 8 Doc 2025-12-09 01:01:31 UTC

+1 for this feature request.

ADDITIONAL USE CASE
Conflict with Third-Party Tiling Solutions

I'd like to add another perspective on why this feature is important: the hardcoded Shift modifier creates conflicts with third-party tiling scripts/extensions like KZones, Bismuth, and Polonium.

Many users (myself included) prefer these third-party solutions for their additional features, configurability, or workflow preferences. However, because KWin's built-in tiling hardcodes Shift+drag, we're forced to either:
1. Configure third-party extensions to use a less intuitive modifier (Alt/Ctrl instead of Shift)
2. Accept that both systems will fight for control when using Shift+drag
3. Compile a custom KWin build to modify the hardcoded behaviour

This goes against KDE's core philosophy of user choice and configurability. Users should be able to choose their preferred tiling solution without the system forcing a specific modifier key that conflicts with their choice.

IMPACT:
- Prevents users from fully utilising third-party tiling extensions with their preferred keybindings
- Forces awkward workarounds that make window management less intuitive
- Creates confusion when two tiling systems respond to the same modifier

SOLUTION:
A simple config option (in Settings, tile editor GUI, or kwinrc) to either:
- Disable the Shift+drag behaviour entirely
- Rebind it to a different modifier

This would allow users to choose their tiling solution without system-level conflicts while maintaining backward compatibility (default: Shift, as it is now).