Support tabs by optionally displaying multiple windows in a column as tabs

[elkowar]

Concept

This is a simple concept for how to add tabs into niri, without conflicting with any of the other potential ideas for future 2D scrolling, etc, and without requiring an additional set of navigation keybinds.
Instead of adding tabs as a completely separate feature, the idea is to allow any columns (vertically stacked windows) to alternatively be displayed as a set of tabs, rather than a vertical stack of windows.

While this still brings some limitations (you couldn't have a tab group be horizontally split), this, in return, solves most of the issues regarding the fact that tabs require a completely new set of keybinds, have complex and often unclear interactions with the rest of the UX, etc.
The semantics of the keybinds from columns would carry over 1:1, as the tab list could be displayed vertically.

This would require one additional keybind, to toggle a column between those two states, as well as one additional configuration option to define the default mode for columns.

Alternatives

There have been many different ideas floating around, such as allowing each column to scroll vertically (which would serve the same usecase, but with different UX), or adding a more general 2D scrolling concept.

Additionally, some of the usecases for tabbing could be served by having a "sticky".

All of these are much larger design questions, probably more complex to implement, and have way more difficult to answer questions in regard to how they interact with the rest of niri.

An additional variant of this would be to just resize the windows, which you can technically already hack together a bad version of via is-active-in-column and min/max-height in a window rule:

[YaLTeR]

Yeah, would be very interesting to try this. Probably not even that difficult to try (though without window titles because we don't have text rendering hooked up well enough).

[elkowar]

🤷🏻‍♂️ I'd love to have this even without window titles, definitely.

[bbb651]

An additional variant of this would be to just resize the windows, which you can technically already hack together a bad version of via is-active-in-column and min/max-height in a window rule:

To clarify, my idea was not to just resize the windows, but also "collapse" them so they only contain the window title. So from a user perspective they are vertical tabs (niri could represent them either as a column with collapsed windows or as a special tab container), with the benefit of reducing wasted vertical space that the active windows's tab would take (imo this is the main downside of vertical tabs, in both versions). I'm not sure how the UX of this would feel tough, and if the alternative way to implement it as special tiles is better.

[elkowar]

I guess this could just be a separate design for the tab bar, where instead of showing a typical horizontal tab bar, you just show the tabs "above" the active window above the window, and the tabs "below" the active window below.

[salman-farooq-sh]

How much work is vertically scrolling windows within a column?

Is it unanimously agreed that they are the best solution for this (disregarding the amount of work needed) or are there any benefits unique to other approaches like this?

They are much more nicer and are worth waiting for in my opinion.

[salman-farooq-sh]

Cool! So will we ever do newm-style 2d? or is it firmly forever out of scope for niri?

[YaLTeR]

Sounds pretty out of scope to me tbh

[salman-farooq-sh]

I agree.

[salman-farooq-sh]

So coming to my original comment, column tabs before column scrolling only because of amount of effort? I completely understand if so because to solve the problem faster. If you or someone else decides to add column scrolling later down the line, will both of these co-exist then or you only want maintenance burden of one? because the last thing we want is niri to get too difficult to be maintained and abandoned consequently.

[YaLTeR]

I like the tabs idea

[YaLTeR]

Opened an issue to track this: #933