Saving layouts

[marko-radosavljevic]

Another killer feature I can think of, and it would be a real life-changer, saving/remembering layouts.

Instead of configuring every display you have, tiling everything perfectly on all monitors, every time you turn on your PC, it would be amazing to just load certain configurations. Because for the most things, you always need the exact same setup. For example code editor + 2 terminals + 1 browser (same sizes and location always), etc.

It's nice if you can load a certain configuration, close it after you finish your work, and open another one, without the hassle of snapping everything in place.

This is also incredibly useful if you often reset the gnome shell (glitches with custom setup, dev work), and all your snapped windows are lost. Or if you reset your PC often, or when gnome gets confused after resuming from suspension..

Especially in multi monitor setups, when some monitors always have the same fixed layout, this would be a huge time saver.

I haven't checked the code yet, and I'm not sure how feasible this feature would be at the moment. It would probably be a huge amount of work. What do you think?

Edit:
For example, terminator has this feature for terminal layouts, splits and different configurations. It's amazing ^^

[Leleat]

Not too sure about this one yet tbh. Currently I have the feature to open windows in a tiled state. But that was done using dumb workarounds and even with that it doesn't work for all windows. I need to check out how other extensions do it. If I can make it work, I'd add it.

---

I am planning on adding a different kind of layout option though (in a distant future). I want the user to be able predefine layouts. When activating a layout my dash asks which window goes into which spot. A similiar feature already exists in other extensions but usually it all happens automatically. I don't like that. I want the user to decide which window goes where.

[marko-radosavljevic]

Ah, nice, I was mostly curious how big you want to go with this extension. Simple windows-like snapping, or something with more features like layouts.

Thanks for the response, I like the idea of predefined layouts. Both options would be cool, so you can open predefined windows configurations and predefined splits (and you add windows manually). But yeah, the most useful feature would be just a predefined split. With the option to replace one window with another (the dash thing), maybe.

[Leleat]

With the option to replace one window with another (the dash thing), maybe.

Do you mean if a tiled window is closed that the Dash opens again to fill that empty space?

[marko-radosavljevic]

Maybe something like that? So you can swap windows in certain spot/split. The idea would be to reduce the amount of manual snapping and rearranging windows.

But I can see this as very annoying if you don't actually want to swap, so everything should be configurable, or a special bind/button that will do it. I think it's very important to avoid interrupting user workflow, extension shouldn't be pushy. So a lot of binds so the user can customize behaviour to their liking.

Also, something maybe worth noting, keyboard-centric workflow should always be available, it would be a dealbreaker for many users if they have to use mouse and drag windows around or click buttons. Not directly related to this idea, just something in general. Extension should behave in a way that the user forgets it exists, that's my opinion.

[Leleat]

So you can swap windows in certain spot/split. The idea would be to reduce the amount of manual snapping and rearranging windows.

Not sure, if that is exactly what you mean, but you can already "replace/swap" tiled windows.If you tile a window (either via DND or via keyboard shortcuts), it'll fit into the layout right below it. If there is none or if there is a non-tiled between the new tiled window will just use the default measurements (half/quarter screens).

Here is an example:

Edit:
Seems like mp4 didnt work :/

Well, here it is converted to a gif:

[Leleat]

Also, something maybe worth noting, keyboard-centric workflow should always be available, it would be a dealbreaker for many users if they have to use mouse and drag windows around or click buttons. Not directly related to this idea, just something in general. Extension should behave in a way that the user forgets it exists, that's my opinion.

Not sure, if the EGO version already has configurable keybindigs but the master branch definitely has.

[marko-radosavljevic]

Not sure, if the EGO version already has configurable keybindigs but the master branch definitely has.

Yup, I was thinking more in the feature and in the scope of that idea, extension should stay non-invasive. For example Dash should only appear when it's necessary, and when it appears, it should be navigable via keyboard, like it is currently.

And sorry for not expressing my idea about swapping precisely. I was thinking in the future, when you support more than 4 windows and complex layouts.

So maybe it would be annoying to replace these small windows, in a complex layout. First you have to find the window, then to grab it, then it's too big, and it's snapping to wrong things.. So in that case, it might be practical to have a button/bind to open Dash and quickly select windows the window you want to replace it with, via keybind. Sounds much faster.

[Leleat]

Ah, I get it what you mean now.

I was thinking in the future, when you support more than 4 windows and complex layouts

"Complex" layouts is a bit of an overstatement. When I allow for more than 4 windows to be tiled, it will be a simple "spiral" tiling (i. e. halfing the available free screen space with each now tiling).

So in that case, it might be practical to have a button/bind to open Dash and quickly select windows you want to replace it with, via keybind

I will add a keybinding to "auto"-tile to the free screen space. I have already implemented it but not yet pushed to master (because it isn't completely ready yet). Here is how it looks.

[marko-radosavljevic]

So in that case, it might be practical to have a button/bind to open Dash and quickly select windows the window you want to replace it with, via keybind

Just to correct my thought there, I meant replacing individual window, that might be annoying to replace otherwise (too small - requires finding, dragging, possible resizing, so you can snap it; too fiddly in short). But working with windows in your example already does look smooth. ^^

I will add a keybinding to "auto"-tile to the free screen space. I have already implemented it but not yet pushed to master (because it isn't completely ready yet). Here is how it looks.

Oh, that's amazing, I love it!

It would be cool to have some config file for auto-tile behavior. For example, some windows just aren't usable at the smallest splits, and some are preferred at that spot, for example terminals. Being able to make auto-tile smart is important, because otherwise it's not very useful, if most of the windows are not usable at that size. Just something to think about, also it's also close to predefined layouts at that point.

I like how smooth animations look, and it's still in alpha state. Congrats ^^

[Leleat]

I like how smooth animations look, and it's still in alpha state. Congrats ^^

Thanks, but I can't take credit for that. These are GNOME's native animations xD

[Leleat]

So maybe it would be annoying to replace these small windows, in a complex layout. First you have to find the window, then to grab it, then it's too big, and it's snapping to wrong things

I've added a new shortcut to adress this. Checkout the keybindings page. The focused window can be tiled to the exisiting layout below it. Here is an example how to tile a window to an existing layout below it.

[Leleat]

I am planning on adding a different kind of layout option though (in a distant future). I want the user to be able predefine layouts. When activating a layout my dash asks which window goes into which spot. A similiar feature already exists in other extensions but usually it all happens automatically. I don't like that. I want the user to decide which window goes where.

I have implemented that type of layout now (when it comes to functionality; need cleaner code). I'll try to see, if I can implement your suggested type of "layout-ing". Here is how the current version works:

[marko-radosavljevic]

Wow, such amazing progress in a short amount of time. Looks great, already a fully featured window manager! ^^

I've added a new shortcut to adress this. Checkout the keybindings page. The focused window can be tiled to the exisiting layout below it. Here is an example how to tile a window to an existing layout below it.

Yup, something like that seems good. The idea would be to have floating window experience and tiling in the same time, seamlessly. So if you open a window in the floating mode, you should be able to quickly integrate it into an already existing tiling scheme, even in more complex situations like that one. Also, it doesn't require a mouse, which is even more important. I believe every mouse-centric feature should have a keyboard alternative. Smooth experience is the most important thing for mass adoption. ^^

I have implemented that type of layout now (when it comes to functionality; need cleaner code). I'll try to see, if I can implement your suggested type of "layout-ing". Here is how the current version works:

Clean, I like that the order of added splits is respected. Consistency is important for fast workflow, user should be able to open all windows in split second, while blindfolded. It shouldn't be a conscious action, because if you have to think about windows, it's another context switch, and mini break in the workflow.

Just my personal opinions and comments on design in general, take it with a grain of salt of course. I'm not really sure what exactly is good/optimal, because I never used something even remotely close to this. It's already the best hybrid window manager I tried so far, so congrats. ^^

[marko-radosavljevic]

@Leleat

I tested current master and found a few issues with layouts.

1. Layout placement doesn't respect 'Enable Dash' disabled. Not sure if this is intentional or not.
2. When you place a layout over an existing layout, and you decide to not open the second window with the Dash, you can't exit the Dash with ESC, mouse clicks, or any other button.
3. Inconsistent and slightly annoying behaviour: When you tile a new window to the side, for example, it doesn't respect existing layout. It will always tile to the 0.5 of the display. And if you do it without layouts, tile to the left, resize window, tile another to the left, it will match the size of the previous window.

System info:

OS    : Ubuntu 20.04.1 LTS x86_64
Kernel: 5.8.0-36-generic
DE    : GNOME Shell 3.36.4

[Leleat]

Layout placement doesn't respect 'Enable Dash' disabled. Not sure if this is intentional or not.

That is intentional. I gave the option to disable the Dash in case people didn't want the "auto-suggestion". But if you activate a layout, you are actively asking for it, so the setting is ignored.

When you place a layout over an existing layout, and you decide to not open the second window with the Dash, you can't exit the Dash with ESC, mouse clicks, or any other button.

Can you elaborate please? Do you mean the "Tile to other tiled window" keybinding or something else or this is about the layouts? Can you make a step-by-step example?

Inconsistent and slightly annoying behaviour: When you tile a new window to the side, for example, it doesn't respect existing layout. It will always tile to the 0.5 of the display. And if you do it without layouts, tile to the left, resize window, tile another to the left, it will match the size of the previous window.

The changing width depends on the free screen space. Originally (when I only allowed a 2x2 grid like windows) I also took the windows below it into account. I changed that when I allowed more complex layouts. For example, how would you expect the extension to determine the size of the left half screen tiling in the following layout:

The width could be limited by 1, by 3 or by 2/4... I don't know what the user would want in this case. So I default to 1/2 of the screen and "adapt" the width only by the free screen space (so that it's explicit that the user wants to tile it to the other window).

I am of course open for suggestion on how to handle the "adaptive" tiling. Maybe I'll check for how many windows are in the layout below it and adapt the size, if the layout below is a 2x2 grid like before.

That is why I introduced the "Tile to other window" keyboard shortcut. That way you explicitly tile to another window (or free screen space).

[Edit]

Which commit version did you use?

[marko-radosavljevic]

I'm using 9e2f8ea,

Can you elaborate please? Do you mean the "Tile to other tiled window" keybinding or something else or this is about the layouts? Can you make a step-by-step example?

It's about layouts, the user should be able to get rid of the Dash if they decide not to tile. It's probably even worse in complex layouts, where you would be forced to select 10 windows to exit.

day.283.-.dash.and.I.are.becoming.best.friends.mp4

When you place a layout over an existing layout, and you decide to not open the second window with the Dash..

This is an incorrect observation on my part, you can reproduce this issue with only 1 layout. Dash is not disposable unless you finish the tiling.

I changed that when I allowed more complex layouts

Ah I see, I haven't noticed new keybinds, I will get back to you when I test everything properly. From what I have seen so far, seems like complex layouts made simple/default experience worse.

playing-with-tiling.mp4

Things I tested:

1. Windows don't stick anymore, so you can't resize both while they are tiled.
2. 'Tile to other window" works only if the window is fully in the empty space.
3. You can't tile to the window under.
4. Tile to the right and left always tile at half.
5. 'Tile to the empty space' opens the window in full screen.

Not sure if it's worth it, because most users would have simple layouts.

I am of course open for suggestion on how to handle the "adaptive" tiling. Maybe I'll check for how many windows are in the layout below it and adapt the size, if the layout below is a 2x2 grid like before.

Yeah, that would be nice. But maybe the inconsistency would be annoying, because you would never know how it would behave? I don't have a good idea atm. Maybe an option between 2x2 and complex in the settings as a band-aid?

Btw, after all the testing poor thing is broken, when I try to open the layout on second display, Dash appears on the first one... ^^

[Leleat]

This is an incorrect observation on my part, you can reproduce this issue with only 1 layout. Dash is not disposable unless you finish the tiling.

Windows don't stick anymore, so you can't resize both while they are tiled.

Hmm, you should be able to abort it. For me both works.

output_file.mov

But it does look like some bug is happening to you on the second tiling (i. e. no shafding is happening etc...)

Can you run journalctl -fo cat /usr/bin/gnome-shell in a terminal and reload your shell (alt+F2, then enter R). Then try the tiling and post the output here for debugging, please?

Tile to the right and left always tile at half.

I think this is what we were talking about in the previous comment, right? The "adaptive" size depends on the free screen (i. e. the a non-tiled layout) below it. Here is an example with the DND preview:

output_file.mov

'Tile to the empty space' opens the window in full screen.

The window should maximize, if the the free screen space below it is ambigious (i. e. not 1 rectangle). In the .mov above I tiled with that keybinding. Can you provide a video to show me the bug?

'Tile to other window" works only if the window is fully in the empty space.

You can't tile to the window under.

Sorry, don't understand these 2. Can you also provide a video for these?

[Leleat]

Btw what is that mouse/keyboard overlay? Do these bugs also appear without them? What are extensions do you use/does Ubuntu ship with?

[marko-radosavljevic]

playing-with-tiling.mp4

All of these are referencing things I tried in the video, in that order, mainly so you can see how my thing behaves:

1. Windows don't stick anymore, so you can't resize both while they are tiled.
2. 'Tile to other window" works only if the window is fully in the empty space.
3. You can't tile to the window under.
4. Tile to the right and left always tile at half.
5. 'Tile to the empty space' opens the window in full screen.

Thanks to your videos now I know everything is badly misbehaving on my end. ^^
Will get back to you when I gather all the necessary info for debugging.

[Leleat]

Any news? Especially this

Btw what is that mouse/keyboard overlay? Do these bugs also appear without them?

I've also just pushed a commit, which should hopefully make the tiling now also adapt the size to the layout below it (and not just based on the free screen space). You can escape the "adaptive" sizes by holding Ctrl.

[Leleat]

Closed due inactivity and getting side-tracked.

Original feature request will be tracked in new issue.