SUMMARY As a long time Plasma user I was excited to hear tiling is being introduced. I was using X11 Plasma + i3wm, but I'd really love to migrate to pure Plasma on Wayland. Unfortunately it turned out the hearsay was kinda exaggerated, because it was just about customizations for a feature Plasma had always had. Still, it might be a nice step forward, but one thing that's really missing, is forcing new windows to tile. STEPS TO REPRODUCE 1. Go to `systemsettings → Window Management → Window Behavior` 2. Switch to tab `Advanced` 3. Open the drop-down list `Window placement` OBSERVED RESULT There's no tiling option. EXPECTED RESULT There's a tiling placement option. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 6.1.0 KDE Plasma Version: 6.1.0 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.1
What specifically would this placement mode do? Feels like you're asking for a UI entry point to what's actually a very complex feature that has yet to be written. :)
(In reply to Nate Graham from comment #1) > What specifically would this placement mode do? Make newly created windows get tiled automatically per the tile layout that was configured in the existing layout constructor > Feels like you're asking for > a UI entry point to what's actually a very complex feature that has yet to > be written. :) Well, doesn't seem that complex to me… There already is a logic for tiling that gets triggered when a person drags window to the edge of the screen. I imagine the new feature would just treat newly created window as if it was immediately dragged to the edge, which would trigger the logic. There may be a question of "which edge" because the layout editor supports adding more than just two tiles — but for starters I think it is fine to chose an arbitrary one. FWIW, as a KDE + i3 user, I personally don't use more than two tiles on a single workspace at the same time.
> There may be a question of "which edge" Yeah, that's the rub. What if I open more windows than there are tiling zones? What if there's no room for new windows anymore? The UX of a typical tiling WM is not as simple as it seems.
(In reply to Nate Graham from comment #3) > > There may be a question of "which edge" > Yeah, that's the rub. > > What if I open more windows than there are tiling zones? What if there's no > room for new windows anymore? Well, since amount of tiling is determined by whatever has been set up in the tiling editor, an answer to this question seems to me just a "undefined behavior". From technical POV I think the solution is to just start creating a new layer of tiling. From usability POV I think it may be better to put a window freely over the tiles, to let the user chose what to do with it. Either solution works since a user know they ran out of tiles. > The UX of a typical tiling WM is not as simple as it seems. FWIW, Idk if i3wm has predefined tiling maps, but even if it has I never used it. To me the UX here is to just open a new window and let i3 to tile it in a way so all windows take equal amount of space. I may adjust it afterwards if so desired (but I rarely do that because I don't typically use more than 2 windows on a single workspace). Generally, this part is simple as well. But since we have tiling editor whom windows should obey, making windows "take equal space automatically" would require changes to the editor, so I wouldn't bother about it for now 😊
Ah, so after 2 windows, you'll move them to another workspace so they don't end up overlapping or the tiles don't resize to be tiny, right? workspace creation is currently not integrated with new window placement at all, so now, as I suspected, it's sounding a bit more like "create an automatic tiling system." :) KWin devs have stated in the past that at the moment, they don't want to add automatic window-manager-style tiling to KWin. However it is intended to supply support the infrastructure to make it possible via 3rd-party KWin scripts, such as Polonium. I'd recommend using that or another one if you want window-manager-style tiling in KWin
(In reply to Nate Graham from comment #5) > Ah, so after 2 windows, you'll move them to another workspace so they don't > end up overlapping or the tiles don't resize to be tiny, right? Yes > workspace > creation is currently not integrated with new window placement at all, so > now, as I suspected, it's sounding a bit more like "create an automatic > tiling system." :) Sorry, I didn't really understand that comment. I can move a window to another workspace well enough, so there's nothing to be done. In case you were talking about automatically tiling the moved window, this is unrelated to the feature discussed, because "window placement" option only concerns new windows.
If we implemented a "tile new windows" feature, and didn't tie it into automatic virtual desktop creation, then as more windows got created, the tiles and their windows would become tinier and tinier, eventually making it impossible to use the windows. On typical screen sizes and resolutions, this would start happening with even a very low number of open windows, like 5 or 6. If we did tie the "tile new windows" feature into automatic virtual desktop creation, then we've created a built-in automatic tiling system, and as I said, KWin devs have already stated that they aren't interested in doing that at this time.
(In reply to Nate Graham from comment #7) > If we implemented a "tile new windows" feature, and didn't tie it into > automatic virtual desktop creation, then as more windows got created, the > tiles and their windows would become tinier and tinier, eventually making it > impossible to use the windows. On typical screen sizes and resolutions, this > would start happening with even a very low number of open windows, like 5 or > 6. Why would you want to create a virtual desktop automatically? No one does that, and I don't know a usecase for that. If a user feels uncomfortable with the current amount of windows, they simply move the current window to another desktop. Moving a window to another desktop has always worked.
Like I said, with your idea, if we didn't create virtual desktops automatically, then as more windows were opened, all open windows would become smaller and smaller to fit into the same area, eventually reaching to point of being uselessly small. And for typical screen sizes, this point would arrive at only 5 or 6 windows.
(In reply to Nate Graham from comment #9) > Like I said, with your idea, if we didn't create virtual desktops > automatically, then as more windows were opened, all open windows would > become smaller and smaller to fit into the same area, eventually reaching to > point of being uselessly small. And for typical screen sizes, this point > would arrive at only 5 or 6 windows. I feel like there's some sort of confusion. You don't need to create a virtual desktop, you don't need to do anything whatsoever besides tiling. This is exactly how it works: you just tile the windows and that it. If you try suddenly move a window to another desktop just because you decided the screen is out of space, a user will get upset. Don't do this. If a user wants, they'll do that either manually or with screen rules.
…besides, my idea was simpler. KDE already has a "tiling layout editor", so what this report is about is simply following the layout chosen in the editor, and if we are out of space on the first layer, just start the second one. It may not be ideal, but it is simple and can be implemented much easier and with less discussion on the merits and etc, because that basically reuses an already existing feature. Anything more complicated might or might not be added later, separately. That's ± fine in terms of a workflow, because people will just move excess windows to another desktop, with a shortcut. With that idea windows won't even get smaller as new ones appear.
In your model, are windows allowed to overlap at all? If so, it's not really a tiling system, right? And if not, then windows will inevitably get smaller as their tiles are shrunk to make room for new tiles and new windows.
(In reply to Nate Graham from comment #12) > In your model, are windows allowed to overlap at all? > > If so, it's not really a tiling system, right? Yes and no. Kwin has a setting called "window placement" that decides how a new window will be placed. It also has a "tiling manager" that decided how windows should be tiled. All I'm suggesting is to merely combine these two features by adding a placement option that will tile new windows according to the setting. It's definitely not the "tiling WM" functional, but such automation still simplifies life and if so desired any other features may be added on top of it later. > And if not, then windows will inevitably get smaller as their tiles are > shrunk to make room for new tiles and new windows. As I explained previsouly, even if that was the case, it wouldn't be a problem, at least not one that a compositor should do anything about. It is expected to be the user's care not the compositor's. Suddenly moving a window to another desktop will most likely get a user upset.
> adding a placement option that will tile new windows according to the setting Ok, so then windows are allowed to overlap, so indeed it's not really an implementation of a tiling window manager. Let's say we did do this. How would it decide which tile zone to place a newly-opened window in? The user can create any arbitrary number of tiles.