Bug 485034

So, all of this actually was a not so laid down "monologue" in Niccolò Veggero's Telegram group. I am just reporting it here so that we all can discuss it.

As a tiling scripts user, I feel as though the Tiling API is incomplete and this is painfully evident when, pre-Tiling API, Bismuth would work really well but, post-Tiling API, Polonium (which uses the Tiling API) is very much limited.

In which ways, you ask?

The first enormous issue is that windows have to be shift-dragged to snap to tiles. This is okay if we're looking at tiles like they are implemented in PowerToys and it does overlap largely with that scope, but it isn't how tiling window managers really work. In a tiling environment windows should be able to be just dragged to other tiles, and the layout should be able to accomodate for the change (sure, this is up to the script that is providing the actual tiling engine implementation, but still it cannot do this now and so it pains a lot of people.)

Talking about shift-dragging, we should be able to shift-drag floating windows even if we only have one big tile. Currently KWin won't allow shift-dragging anywhere if you only have one window tiled in one tile, but Polonium exploits the shift-drag functionality to split that tile into two and place the other window besides the already placed one.

Lastly, there should be a way for tiling scripts to be able to provide clear highlighted insertion points for windows (which would require one less hack - that is, what I described above.) This could be done by repurposing desktop corner snapping, or by providing edge-snapping inside tiles.

And still, I feel as though this would only scrape the surface. KWin's Tiling API is a big promise, but far from complete; yet, I hope script developers and KDE contributors can collaborate towards a common goal here.