SUMMARY When not using the custom tiling feature if I drag to a side and either the top or bottom 25% it will do a quarter of the screen. I would like the ability when I move a window using the tiling modifier into the top or bottom 25% of a zone to use the top or bottom half of that zone. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.0.2 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 Kernel Version: 6.7.10-273-tkg-linux-tkg (64-bit) Graphics Platform: Wayland Processors: 24 × AMD Ryzen 9 5900X 12-Core Processor Memory: 62.7 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 4080/PCIe/SSE2 Product Name: X570M Pro4
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.