"Hybird" Mode

[Stoppedpuma]

I use niri as my default window manager on my laptop and find the experience to be great, so much in fact that I constantly find myself wanting to bring this experience to my desktop computer. I find myself running into one large wall though on desktop, the way of handling scrollable workspaces does not work that well for a desktop experience. On portable devices such as my laptop I find this great, but on desktop not so much and I always default back to more traditional tiling window managers such as Sway. I have spent a bit of time thinking and have thought of a way which merges the feel of a scrollable window manager such as niri and a traditional one such as Sway, an in-between mode hence the title "hybrid" (I also just couldn't think of a better name / description). This mode works by scrolling when the edge is reached manually instead of when new windows are created. The strip behaviour is kept, but managed into individual workspace like groups which I'm calling "Hybrid Workspaces" because I can't think of a better name, switching actual workspaces should still work as intended and create a new strip. I think this could also open the door to more benefits such as dynamic tiling options.

Below are some designs of possible implementations.

"Classic Scrolling": This mimics the current way that niri shows windows on the left and right sides

"Arrows": Arrows has little arrows on the sides showing how many "Hybird Workspaces" are to the left / right. The number of arrows should follow how many times the user can scroll in that direction.

"Dot indicator": The dot indicator is a classic tray approach which shows where the user is currently located.

[YaLTeR]

Hm, so more or less just have two dimensions of workspaces? Where every strip contains monitor-sized workspaces that you can scroll left and right, and up and down scrolls through strips. And then every workspace is a regular tiling WM sort of workspace.

This concept sounds like it would be easier to try as a Hyprland plugin or something, I feel like implementing "regular tiling" fixed to monitor size would be more effort in niri.

[Stoppedpuma]

Maybe. I think this would fit more naturally in the code as a new layer of hierarchy on top of columns. Though, my main question is how the UX around it should work in a way that is not confusing (un/grouping columns, moving windows in and out, etc.).

I think we could borrow a few ideas from sway here with coloured borders depending on the group type. Adding and removing could be done by selecting multiple windows similarly to shift clicking to select multiple and then using a keybind to create a group type (e.g regular group, tabbed group, vertical tabbed group, etc). Basically just colours to coordinate group type. Things could be added or removed to a group by dragging them in and out, possibly a keybind as well? Accordingly, it should also be easy to resize a group, a keybind option would be useful here as well, something like mod+alt+right and the windows should scale along with group resizes.

Below is a basic, very rushed design showing this. I haven't had much time to give this proper thinking UI and UX wise so I'll revise this when I have more time over the next few days.

[Stoppedpuma]

I have revised the designs mentioned above and rethought UX in particular about how specifically tabbed groups should work as I saw another discussion about tabbed groups here.

Hyprland requires an additional key to be used for switching between the windows in a group, for this example, lets use arrow keys and alt. Say the user is moving to the right of the strip, they wouldn't want to have to scroll through every window in a tabbed container, so instead we should hold alt when the container is selected to be able to move through the windows, if it isn't held, the users next right step goes past the container.

Revised design for horizontal tab container here:

As there's a bit of open space towards the sides with this design style, window decorations can be removed by default and buttons like close can be put onto the open area such as the top right.

Regarding vertical tab containers, it's pretty much the same thing. I've decided to put the vertical windows on the side instead of actually vertical like what you would find in sway or i3 because as niri is scrolling, chances are, the user wants to use more horizontal space and reserve vertical space for the application. The same idea of moving buttons like close and hiding window decorations for windows in these groups can be applied here such as above the tabs in the top right.

Vertical tabs design:

Some additional UX can be added here such as adding close buttons to the tabs which show on hover. This can be applied to both container types. Additionally, tabs should be able to be dragged around to be re-arranged. Dragging windows out of the group should work from both a tab level, and window level. From the window level though, a modifier should be held such as alt since it was mentioned above, otherwise moving with a bind such as mod+m1 should move the entire container, mod+alt+m1 in this case should allow moving the windows inside of tabbed containers.

As for "Regular Groups", I think these should have an option to be required to hold a key to switch through the windows inside, or just go through them by default as this one I can see being pretty 50/50 in preference.

[YaLTeR]

Thanks for the concepts and for the info on how it works in Hyprland.

Yeah, it's a bit unfortunate that adding this extra layer of grouping requires an extra set of binds. I feel like at this point it becomes too easy to tangle in the various layers of keybinds.

[Stoppedpuma]

This could always be done the opposite way where it goes through windows in a tab by default and a key could be used to ignore the windows in a group if you think that simplifies things? Otherwise I'm not too sure how to have this work efficiently for those using keys to switch between windows. Sway doesn't use a key at all and just goes through the windows, but as mentioned previously, this is pretty inefficient especially for the design of niri as it requires going through all the remaining windows in said direction before going to the next window outside of the container.

Of course a solution to this is to just not add horizontal tabbed groups which could work, but seem to be pretty 50/50 in preference compared to vertical tabbed groups. I think regular groups don't have to worry about the key behaviour as it's basically just the same behaviour you would find in a traditional window manager.

[mastoca]

@Stoppedpuma Could some of these ideas be tested by running niri in niri? I've customized my keybinds to a brittle degree but I could see separate niri instances could simulated 'grouped' like you describe if your display is massive enough to enjoy that. It will likely be very odd behavior but it would allow you to validate some these ideas.

I came from xmonad and had a host of tiled panels for different use cases, but I've enjoyed the smoothness of the endless scroll since I dedicated a separate trackpad to just do that with my left hand (contemplating using a keyboard with a knob to perhaps use that instead once it arrives).

In terms of ux, personally, I've found tabs to be a bit too much work to traverse and locate things.