Summary: | Add ability to put a window in a portion of a tiling layout zone by placement Top/Bottom 25% | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | Jonathan Isom <jeisom> |
Component: | Custom Tiling | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | RESOLVED INTENTIONAL | ||
Severity: | wishlist | CC: | hey, mobile.harvey, nate, notmart |
Priority: | NOR | Keywords: | qt6 |
Version First Reported In: | 6.0.2 | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
See Also: | https://bugs.kde.org/show_bug.cgi?id=466057 | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Jonathan Isom
2024-03-16 13:07:42 UTC
Hi - I'm a little unclear about this request. Would it be possible to provide a little more detail so the feature request is really clear? Thanks, Nick (In reply to Nick from comment #1) > Hi - I'm a little unclear about this request. Would it be possible to > provide a little more detail so the feature request is really clear? Thanks, > Nick If looking at the default tiling layout, 3 zones in a 1x3 layout, currently when moving a window into one of the zones the window will fill that zone. My suggestion is that if a window is dragged to either the upper 25% or lower 25% of a zone it would fill only that half, creating 2 sub-zones each. With the 3 zones in the default it would effectively allow 6 windows, 3 top and 3 bottom in a 2x3 layout, to be tiled onscreen without having to subdivide the zones in the template editor ahead of time. This would add additional flexibility to the tiling system and apply only temporarily until the window(s) are moved out. Currently if I wanted to do this I'd have to go to the tiling layout editor, split the zone vertically, use the layout for ever how long that is, then undo the split when I am done. Hope that is clearer. Kind of the opposite of Bug 464611. IMO neither really make sense as they propose violating the semantics of how custom tiling works. In both cases you should just modify the tile layout to accommodate what you want. I think the underlying issue is that modifying the layout feels slow. Bug 466057 proposes addressing that, and if implemented, I think it would be usable for the use cases you have in mind here. |