Bug 438788

Summary:	Coordinated resize for adjacent/tiled windows
Product:	[Plasma] kwin	Reporter:	pat_h
Component:	general	Assignee:	KWin default assignee <kwin-bugs-null>
Status:	RESOLVED FIXED
Severity:	wishlist	CC:	alumni_leap_0d, justin.zobel, nate, postix
Priority:	NOR
Version:	5.21.5
Target Milestone:	---
Platform:	Other
OS:	Linux
See Also:	https://bugs.kde.org/show_bug.cgi?id=422938
Latest Commit:	https://invent.kde.org/plasma/kwin/commit/e4507861f7b5ba563ae7cd5ce036a42a09f9edf8	Version Fixed In:	5.27

Description pat_h 2021-06-17 04:21:48 UTC

SUMMARY
When to windows are placed directly next to each other (some time after snapping to each other), it would be cool to have a tiling-on-demand-like resizing of both windows at the same time

STEPS TO REPRODUCE
1. Place one window e.g. on the left side of the screen
2. Place one window on the right side of the screen
3. Move you cursor into the screen's center to get the "resize to the left or right" cursor
4. Try to resize both windows at the same time by clicking the mouse button and dragging to the left or the right

OBSERVED RESULT
• When holding the left mouse button: Only one window gets resized, but not the other. Often (but not always) the other window must be resized, too, leading to some additional work.
• When holding the middle mouse button: Nothing happens.

EXPECTED RESULT
• When holding the left mouse button: The behavior should stay as it is now, as sometimes you only want to resize one window.
• When holding the middle mouse button: Resize both windows at the same time implementing a stateless tiling behavior.

SOFTWARE/OS VERSIONS
Windows:
macOS:
Linux/KDE Plasma:
(available in About System)
KDE Plasma Version:
KDE Frameworks Version:
Qt Version:

ADDITIONAL INFORMATION
Although the first thought might be, that the window selection for the middle mouse button behavior is ambiguous, I think it is a well-determined problem. Selecting the first window is probably trivial, as the same logic can be used as with the left mouse button.

To find the second window, loop through all windows and check whether they end (or start, depending on being on the left or right side of the first window) with exactly an offset of one pixel and span the same coordinate in the other dimension (depending on resizing to the left/right or to the top/bottom). If there are multiple windows in question, just use the top-most in the stack.

I think this would be a sane default, as the middle mouse click drag and drop in this situation is not used as far as I know. However, it would probably make sense to limit the new behavior to the 3 top-most options selectable in window management → Window Behavior → Titlebar Actions → Titlebar and Frame Actions → Middle click (Active).

Without maintaining a tiling state, the implementation should limit the additional complexity a lot.

Comment 1 Nate Graham 2021-06-17 18:27:36 UTC


*** This bug has been marked as a duplicate of bug 422938 ***

Comment 2 pat_h 2021-06-18 02:28:06 UTC

Hi Nate,

thanks for taking the time to read this feature request and pointing to #422938. However, in #422938 the only suggestion is to do it as in Windows 10, where the tiled resizing is quite annoying IMHO and follows a totally different concept than suggested here:
   This suggestion            <->  Windows 10
   All adjacent windows       <->  Side snapped windows only
   Stateless (dynamic choice) <->  Stateful (snap state dependent)       
   Middle click               <->  Left click
   Normal behavior available  <->  Normal behavior no longer available

Maybe #422938 does not want to have Windows 10 behavior, but it's impossible to tell, because there is hardly any information included probably due to only referring to a non-available demonstration video.

Therefore, I reopened the current report (#438788) and suggest to either mark #422938 as a duplicate of #438788 if anyone still knows what the bug reporter's intend was or request more information in #422938.

Comment 3 Nate Graham 2022-07-21 16:29:54 UTC

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

Comment 4 Nate Graham 2022-07-21 16:29:59 UTC

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

Comment 5 Marco Martin 2022-12-01 14:39:34 UTC

Git commit e4507861f7b5ba563ae7cd5ce036a42a09f9edf8 by Marco Martin.
Committed on 01/12/2022 at 14:39.
Pushed by mart into branch 'master'.

Custom quick tiling with configuration ui

* Allow to do quick tiling to custom tile geometries, windows will be snapped to tiles when dragged with the shift modifier pressed.
* Tile geometries are screen specific.
* The global shortcut Meta+T will trigger a fullscreen configuration ui as a QML effect for the tiles which allows to add, remove and resize tiles
* UI and behavior is a bit similar to the Windows Fancy Zones addon: https://docs.microsoft.com/en-us/windows/powertoys/fancyzones
* Its main scope is to help the workflow with very big monitors, especially ultra wide ones, where most application don't make sense maximized to the full screen (eventually also support games to be full screened to a given tile instead of the whole screen)
* it should get also some bindings for scripting, as its ain goal is not to replicate other popular tiling window managers, but should give the popular kwin tiling scripts to have a more robust infrastructure
* it will eventually get support for a set of predefined layouts, but this is for a second phase

M  +1    -0    autotests/integration/CMakeLists.txt
A  +416  -0    autotests/integration/tiles_test.cpp     [License: GPL(v2.0+)]
M  +5    -0    src/CMakeLists.txt
M  +1    -0    src/effects/CMakeLists.txt
A  +26   -0    src/effects/tileseditor/CMakeLists.txt
A  +16   -0    src/effects/tileseditor/kcm/CMakeLists.txt
A  +71   -0    src/effects/tileseditor/kcm/tileseditoreffectkcm.cpp     [License: GPL(v2.0+)]
A  +32   -0    src/effects/tileseditor/kcm/tileseditoreffectkcm.h     [License: GPL(v2.0+)]
A  +36   -0    src/effects/tileseditor/kcm/tileseditoreffectkcm.ui
A  +18   -0    src/effects/tileseditor/main.cpp     [License: GPL(v2.0+)]
A  +11   -0    src/effects/tileseditor/metadata.json
A  +95   -0    src/effects/tileseditor/qml/ResizeCorner.qml     [License: GPL(v2.0+)]
A  +73   -0    src/effects/tileseditor/qml/ResizeHandle.qml     [License: GPL(v2.0+)]
A  +218  -0    src/effects/tileseditor/qml/TileDelegate.qml     [License: GPL(v2.0+)]
A  +133  -0    src/effects/tileseditor/qml/layouts.svg
A  +276  -0    src/effects/tileseditor/qml/main.qml     [License: GPL(v2.0+)]
A  +109  -0    src/effects/tileseditor/tileseditoreffect.cpp     [License: GPL(v2.0+)]
A  +50   -0    src/effects/tileseditor/tileseditoreffect.h     [License: GPL(v2.0+)]
M  +5    -0    src/scripting/scripting.cpp
A  +161  -0    src/scripting/tilemodel.cpp     [License: GPL(v2.0+)]
A  +70   -0    src/scripting/tilemodel.h     [License: GPL(v2.0+)]
M  +20   -0    src/scripting/workspace_wrapper.cpp
M  +4    -0    src/scripting/workspace_wrapper.h
A  +395  -0    src/tiles/customtile.cpp     [License: GPL(v2.0+)]
A  +63   -0    src/tiles/customtile.h     [License: GPL(v2.0+)]
A  +253  -0    src/tiles/quicktile.cpp     [License: GPL(v2.0+)]
A  +65   -0    src/tiles/quicktile.h     [License: GPL(v2.0+)]
A  +409  -0    src/tiles/tile.cpp     [License: GPL(v2.0+)]
A  +162  -0    src/tiles/tile.h     [License: GPL(v2.0+)]
A  +318  -0    src/tiles/tilemanager.cpp     [License: GPL(v2.0+)]
A  +77   -0    src/tiles/tilemanager.h     [License: GPL(v2.0+)]
M  +2    -0    src/utils/common.h
M  +93   -23   src/window.cpp
M  +16   -0    src/window.h
M  +16   -1    src/workspace.cpp
M  +7    -0    src/workspace.h

https://invent.kde.org/plasma/kwin/commit/e4507861f7b5ba563ae7cd5ce036a42a09f9edf8