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.
*** This bug has been marked as a duplicate of bug 422938 ***
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.
*** Bug 452601 has been marked as a duplicate of this bug. ***
*** Bug 444134 has been marked as a duplicate of this bug. ***
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
omg this is fantastic. the existing tiling that works with bismouth doesn't work so well with how I want to arrange my windows on a vertical 4K. i.e. there's no way to get an arrangement like this: |---+---| | | |---+---| | | | |---+---| or like this: |---+---| | | | |---+---| | | |---+---| | | | |---+---|
Hi, how do I turn this off? It breaks my quarter tiling something fierce; I use a layout like: |------+-------| | | | |------+ | | +-------| |------+-------| And after a recent update to kwin-5.27 I can't resize the windows in that right-hand column without it pulling the ones on the left with it - even pulling stuff into the corner which _should_ resize it to a quarter screen gets broken, and it instead resizes stuff to match other windows instead. Even moving a window to a new empty desktop and resizing it there resizes other windows on other desktops meta+T shows a popup with a 3-column layout that doesn't remotely match the organisation of my windows, and playing with it has zero effect on window locations. Shouldn't there be something in systemsettings to control how this feature behaves?
(In reply to triffid.hunter from comment #7) > Hi, how do I turn this off? > > It breaks my quarter tiling something fierce; I use a layout like: > > |------+-------| > | | | > |------+ | > | +-------| > |------+-------| > > And after a recent update to kwin-5.27 I can't resize the windows in that > right-hand column without it pulling the ones on the left with it - even > pulling stuff into the corner which _should_ resize it to a quarter screen > gets broken, and it instead resizes stuff to match other windows instead. > > Even moving a window to a new empty desktop and resizing it there resizes > other windows on other desktops > > meta+T shows a popup with a 3-column layout that doesn't remotely match the > organisation of my windows, and playing with it has zero effect on window > locations. > > Shouldn't there be something in systemsettings to control how this feature > behaves? Meta + Right = Quick Tile Window To Right Meta + Left = Quick Tile Window To Left search Tile in shortcuts kcm in systemsettings
Is there a way to turn this off? I prefer the old behaviour where I can resize windows independently.
I would second the ask for a method to turn this off. It is exceptionally annoying. All I wanted to do was resize one window momentarily to see something better and all the surrounding windows changed with it with no way back to the default position other than eyeballing it or restarting plasma (yeesh).
It is really annoying, especially, as the proposal mentioned to explicitly _not_ do it like it has been implemented. Furthermore, the observability of the whole feature is rather poor. What might help you at least a bit: - You can use <meta>+<t> to (hopefully) match your intended layout - use <meta>+<left arrow> and <meta>+<right arrow> to move windows around - when using the mouse although setting the layout, it still does not work. What kind of works is holding the <shift> key while moving windows around. Then they at least snap into the intended layout.
Please do not re-open fixed bugs if you don't like the feature. Instead, submit a new bug report asking for it to be opt-out.
(In reply to Nate Graham from comment #12) > Please do not re-open fixed bugs if you don't like the feature. Instead, > submit a new bug report asking for it to be opt-out. Hi Nate, just to clarify as I am sure you have a ton on your plate judging from the impressive and valuable work you do: I opened a feature request (tiling-on-demand), another feature (always-tiling) was implemented, this request was closed as fixed (due to that other feature) and I reopened. Is the expectancy really that I open a new request where I basically copy the request and we lose track of the history? I can do so if that helps, but I wanted to double-check as it seems sub-optimum to me. Kind regards Patrick
If you don't feel that the feature you asked for has actually been implemented, then you can un-mark the bug report for it as being a duplicate of this one.
I would like to draw attention to https://bugs.kde.org/show_bug.cgi?id=466687. I found this issue via a google search, because the "new" tiling is not exposed via keyboard shortcuts like quick tiling, and thus this issue is _still relevant_ for accessibility reasons - for users with impaired motor controls such as myself. I cannot use the "new" quick tiling because the only way to use it is with a mouse, and thus I am stuck with a method of quick tiling that does NOT have coordinated resize for adjacent windows. I would be very grateful if someone could take a look at the linked bug and implement keyboard shortcuts for the "new" tiling method.