Make Tiling Shell a lightweight tiling window manager replacement #117
Comments
|
Hi! Can you describe the difference between point 1 and 3? It sounds to me like they would do the same thing. But I'm probably missing something! |
|
Hey @distefam, thanks a million for sharing these ideas.
I think 1) is about changing the focused window, while 2) is about swapping the position of two tiled windows |
domferr
added
enhancement
Understood, and as I mention in the linked ticket, there is a complimentary extension that works well for this. That said, it is unaware of whether a particular window is tiled or not so if one would want to differentiate between tiled and non-tiled windows when navigating then it would have to be integrated into Tiling Shell. Alternatively, and I've never developed Gnome extensions before so I'm not sure if this is possible, it would be interesting if Tiling Shell could somehow mark a window with a property that indicates whether it is tiled or not. Then, another extension could read this property and act accordingly. This would support the modular idea I mention in my original message.
This one is pretty important for the goal stated in this ticket: to make a lightweight tiling window manager replacement. Again, I'm not sure if that goal aligns with yours though.
I agree. While splitting a window is certainly nice it is not essential. What would go a long way to supporting this workflow, however, would be to implement #50. If we were able to switch layouts with a keyboard command then this would somewhat address the desire to "split" windows. I'll add a comment to #50 describing a common workflow of mine and how this would support it. I'm also amending my original post in this thread to add #50 as it is really useful to many tile-based workflows.
This is especially helpful when navigating between windows with keyboard shortcuts (c.f. #116). I use an ultrawide monitor, that means I can have a lot of visible windows, making it very useful to know visually at a glance which is the active window. Gnome Forge, PaperWM, and PopOS Shell all do this pretty well.
I agree that auto-tiling is a tricky problem to solve well. I'm not sure if you've read one of the Gnome developer's blog post called "Rethinking Window Management", but I'd recommend it if you haven't. Unfortunately, it doesn't seem that Gnome has been actively pursuing this since the blog post was written over a year ago. That said, some of the difficulties could be mitigated by allowing a user to mark individual apps/windows to never tile (I mentioned this in my original post). There could also be some very basic logic to start, for example:
These are just some basic logical rules. If you're interested, I'd be more than happy to flesh out a more thorough logic tree of when a window should be tiled and when not. |
|
Thank you for your reply @distefam! Here it is a quick update about this:
|
|
Auto-tiling would for me be the most interesting addition, i would love to have a mode in the way Hyprland implements it, where windows always try to take up the maximum available space. So the first opened window opens fullscreen, the 2nd one causes the first to downsize by 50% and the new takes up the additional space, etc. First 15s of the video below: |
|
Hey @litemotiv, thanks for sharing. This is interesting! |
|
To chip in some feedback, auto-tiling is the feature that brought me to Linux. I even chose Pop!_OS as my first distro because of it! I've since switched distros, and now that Forge is no longer maintained, I'm back to life without auto-tiling. Gotta say, I miss it. The reason why I love auto-tiling is because, every time I open a window, I have to drag it into my preferred position. This might not sound like a big deal, but if it takes a half a second to drag a window into place and then I spend a busy day at my computer and open a hundred windows, that's 50 seconds of my time lost. More realistically I probably open around 30 - 50 windows per day on average, so and in total that's around 1.5 - 2.5 hours per year that I spend dragging windows around. These subtle time saves add up! One way that Tiling Shell could improve the usual automatic tiling experience would be to only automatically tile windows when a new window is opened or closed. I suggest this because, in some automatic tiling implementations, if the user moves a window then the automatic tiler will take over and snap it back into position where it last was, effectively preventing them from moving it around. This would be effective because automatic tiling is only really useful when a window is created or destroyed. When a window is opened, the user is going to want it to already be in position for them to use it, making automatic tiling useful. And when a window is closed, the user is gonna want any open windows to expand and make use of the newly cleared screen space, again making automatic tiling useful. Outside of those circumstances, it's pointless, so automatic tiling might as well only happen during window creation/destruction so that users can rearrange windows however they like without it getting in the way. Also, yeah, I agree with the suggestion that having a blacklist to prevent windows from being automatically tiled would be a great idea as well. But either way, automatic tiling would be awesome and I hope that my explanation of all the time that it would save is convincing! If we just look at 491 users of Tiling Shell (that's the amount of stars right now) opening and closing around 30 - 50 windows per day and all using automatic tiling, you could save a couple hundred hours of time. 😉 |
|
first of all, thanks for making this and for encouraging feedback! i agree with the points and suggestions made above, but would also like to chime in on the autolayout. i am still using forge, and for me the autolayout is the key feature about it, taking a huge mental load off of me. before, i spent A LOT more time managing my windows than the calculated hour per year, more like half an hour per day. but as it is now, i open a window and often don't even have to think about where to place it... because it just doesn't matter that much. the main point is the most important information being available and it not hiding any other windows. it might just be open for a second or two, like with a password manager, and i love the feeling when that pops open but i still see my original window, i hit enter or whatever and it goes away again, everything snapping back to the way it was. i also use the window-splitting-feature a lot as well as the swapping... i never stack windows though, as i then have to hunter for my information again, clicking teenie-tiny bars to find my stuff. when i have something more important or just temporary, i unfloat it or maximize it, which in forge overrides the tiling behaviour. apart from that, i mostly use dual screens and something like 4 workspaces (more when i'm just on the laptop). i'm not saying this needs to be done in tiling shell - just sharing how i use my desktop. cheers! |
|
Thank you @Raindrac and @johannesrave, your feedback is invaluable! |
Describe the feature you'd like
I'd like Tiling Shell to provide the basic functionality of a tiling window manager. There have been other attempts at this (PaperWM, Material Shell, Tiling Assistant, gTile, forge, Pop-OS Shell, etc.) but a lot of them attempt to do too much. Tiling Shell's current implementation is clean and lightweight but there are a few things that are required to make it capable of replacing a tiling window manager:
Essentials
Niceties
<Super><Shift>ffor "always float this window".Adding these functionalities would make Tiling Shell a very nice lightweight alternative to a full-fledged tiling window manager. The latter have proved to be difficult to maintain (many of them seem to be abandoned after a few years as the maintenance is too great), which I think is because many have tried to do too much and thus had more surface area to update when Gnome shell changes its API.
I think applying the Unix Philosophy of modular components to compose a tiling window manager replacement is the solution to the above problem. While the niceties could be handled by other extensions, I do think that the things I listed under essentials, especially items 2 and 3 in the list above, make sense to include in the core feature-set of Tiling Shell due to their dependency upon its implementation of tiling.
The text was updated successfully, but these errors were encountered: