When I use tiling in KDE, the windows moved to the bottom of the screen are smaller than the ones above by the size of the taskbar. I wonder if it would be possible to make the layout that we configure with super+T to be created based on a fraction of the available screen space for placing windows, instead of the full screen size.
I know that I could adjust the heights manually, but it’s quite difficult to do precisely.
hi, welcome.
not sure i follow your question.
when i use meta+t to edit the layout it does not show the space used by any of my panels, as you say… but when i actually use drag+shift to place a window into one of those tile areas it DOES take the panels into account.
does it not work that way for you?
It cuts off the bottom windows by the height of the panel, it does not shrink all window “slots” proportionally.
For example here I opened the console in a top slot, and the system monitor in the bottom slot. Then I closed and re-opened the system monitor so that it remembers the window size, then I moved it next to the console window without snapping to compare the window sizes.
As you can see, the system monitor is smaller. My panel is 36 pixels tall. I bet if you count the pixel difference in height between these two windows, it’ll be exactly that.
ah, so i reproduced your test with a panel at the bottom of my portrait screen that was 100pt thick.
then i used Meta-T to create a full screen height tile zone which i then split vertically so that it shows two equal size tiles stacked on top of one another.
then i did as you described and tiled a konsole window to the top position and a system monitor to the bottom position, then closed and re-opened the monitor so it could dragged over to compare sizes
there is clearly a 100px difference in height.
so the feature you would want is:
Meta+T tiling editor should take into account the thickness of all panels on the screen and block out or subtract those areas from tile size and the split calculations.
what is the goal?
while it may be more aesthetically pleasing, is there an actual use case for such a feature?
is there some reason why you need each tile area to be exactly equal?
as a quick fix, you could add a panel to the top edge of an equal thickness to the bottom and then the tile editor split line would produce equal sized windows.
Yes, this is it. This behavior is the same with window snapping, not just tiling (i.e. dragging a window to the edge of the screen with the mouse). Would be nice if it also took into account the panel size.
For me the use case is just effective use of available screen space when mixing tiling and floating workflow or saving time adjusting windows. I don’t always put the windows in the same spot, and I don’t always explicitly use tiling, and so if I arrange 2 windows vertically that both used to be tiled in the top row, content on one of them is partially hidden, and if I do the same with the bottom row windows, there is free space on the screen that is wasted.
But yeah, it’s mostly an aesthetic thing for me.
However it would also address an issue where with a tall enough panel and a small enough bottom row, there is no space for the windows at all (for example with a 3x3 or 4x4 layout).
so your use case is you want to be able to tile a window, close it (so it remembers the size), then open it again as a floating window and be able to drag it to arrange it as tho it were tiled but in a different order from when it was originally tiled.
that seems like a VERY specific use case with off ramps to less onerous options at several points along that trajectory (like simply resizing the now floating window)
you should look into using window rules to define set sizes for specific windows… that might better suit your use case rather than trying use tiling to achieve it.
tiling (both quick and custom) are for quickly arranging your current windows so they don’t overlap with each other… its not really for re-creating a static, lego style board of windows and apps where windows/apps can be interchangeable.
If I sometimes want the window to take up 1/8 the screen (2 rows of 4), sometimes 1/4 and sometimes 1/2, I don’t see how I would do that with window rules. But with tiling I can snap it with the mouse to a corner to get it to 1/4, snap to side to do 1/2, and set up tiling to do 1/8.
Also window rules are buggy. Konsole never remembers its position correctly after a reboot, even after I set it up in the window rules. I usually put it in the bottom right corner of my screen on the left, and set window rules to remember its position, but after a reboot it always spawns in the top right corner of that screen, and if I just let it be and continue working as if that’s its place now, I have to deal with the issue that we’re discussing - wasted space on the screen, because the window was cut off before it was closed.
under meta+t there is also the option to make a floating tile which you can resize with fine control (tho it does not show the size in pixels, and it probably should).
you could set up a couple variations of those floating tiles that size your windows just how you like them for all the various arrangements and then just use the custom tiling feature as a way to quick-size cookie cutter any window to conform to your lego puzzle piece standards… then just drag them when you want them without changing their size.
seems like that would work with your current work flow better than anything we could change about the tiling editor (except for possibly adding those pixel counts)
I don’t see how that helps at all. When I move something out of that floating tile, it snaps back to its original size like with the regular tiles, so unless I want to restart the program every time after sizing it with those tiles (which I do not, and it also doesn’t always work), I would have no way of placing the windows in the correct spot.
Adding pixel counts to the layout editor would certainly help with adjusting the custom grid, but it would still require a lot of manual intervention, especially if the taskbar is tall and the bottom row of windows is small. And it also wouldn’t address the issue with the screen edge snapping (or is there a way to customize the grid for it too that I missed?).
But yeah, if I can do pixel perfect layouts for the tiling and snapping grids, it would work for me, since I would only have to do the setup work once per screen, even though it would require a calculator to do it right.
But then again, the tiles are defined as proportions of the screen, so measuring their size in pixels is quite counter-intuitive. For example I have a 1440p screen and 2 4k screens, and the 1440p screen is usually at 67% scaling (to have the same window sizes as on the 4k screens). But I sometimes have to reset the scaling to 100% because some applications bug out (for example the Brave browser window in wayland mode keeps getting smaller each time I drag it to that screen). What would be the pixel sizes of the tiles, and how would they be adjusted when I switch between 67% and 100% scaling?
well yeah… you have to do the same trick you usually do by closing the window so it remembers the size.
i thought we covered that ground.
I do not “usually do it”, it was a way to demonstrate and reproduce the problem in the easiest way I could think of. Nor does it work with every program even if I did do that. I open the window and snap it in place where I want it, as a normal person would do, not close and reopen it again as the psychopath that you seem to think I am 
. Then I close it when I’m done, shut down the PC, and the next day when I boot up and start the program again, it is not where I put its window the day before, even though the window properties are set to “remember” the position. That’s one of the cases when this mismatched size becomes a problem.
Besides, as I said before, mine is not the only use case that is affected by this. The current behavior is frankly bordering on being a bug, considering that it might entirely delete a row of windows if the panel is tall enough.
fair enough you maniac 
but in my defense you did say your use case was to move these windows around and that’s how you noticed this situation… i mean otherwise how would even know?
i don’t know if this rises to the level of a bug because tiling does seem to be doing what it says it’s supposed to do and at least the panel is taken into account when the window is tiled, so there is nothing hidden behind the panel (i would consider that a bug for sure).
the problem is only that the two tiles are not the same size as they would seem to be from the meta+t editor view.
