Support wider-than-display windows/columns and enable edge alignment keybinds

[artiepoole]

The Concern

I often find sidebars in GUI tools like browsers and IDEs to cause claustrophobia. I understand that there are other solutions, but I propose the following solution by using niri: enable edge alignment to override left alignment.

I also find it annoying when the columns shift focus when I am trying to copy from one window to another.

Below is an example of what the current implementation of scrolling allows for with the first image demonstrating the view with the column focussed, and the second image showing that you must focus a different column to see the right-most part of the IDE window.

Related discussion

#2464
#1347
#2483
#1520
#1929
#3033
#2998

Proposed solutions

I am planning to combine the ideas from #1929 with #3033 , rebased onto latest, and then modify them to support wider-than-display windows/columns.

Option 2 - add "focus-edge-<left/right/center>"

UPDATE: I just discovered #1929 and #3033 which may be doing exactly this.

In this approach, I would implement new keybind actions to go alongside the "center-focused-column/center-visible-column" actions. There would be two new binds - one which pans to put the left edge of the current window into view, and one for the right edge. Example names could be "left-align-focused-column" and "right-align-focused-column".

If the column is smaller than the current display width, this would just move the correct edge of the current column to the appropriate edge of the display (accounting for struts). This would also undo centering, so if you centered a window and wanted to un-center it, you can left align it, for example.

Pros:

• simplicity since most of the maths is already available: left align is already done when changing focus so we just need to add a "right align" helper.

Cons:

• does not support columns wider than 2x current resolution (is this a problem?) - you cannot pan within the window.
• Would probably need to tweak current centering logic to support columns wider than the display resolution. Current centering logic currently left aligns larger-than-display columns.
• does not change snapping on focus behaviour (copy and paste scenario described in problem statement)

Option 1 - DISMISSED due to maintainer vision - add a new smooth scrolling action for keybinds

In this approach, we would implement a new scrolling type which can be bound to input. This scrolling type would not snap new columns into focus, but would instead seamlessly scroll left/right by an amount (proportion, fixed virtual pixel amount etc, as implemented in other settings). When the previously focussed window goes completely out of view, the focus changes. There are a few edge cases to iron out, but I suggest that the next column would be focussed, unless it is the last one, and then it would become right-aligned.

I think there would need to be a global config to set the "3 finger swipe" control type (at least, I don't see this as a bound key in my configs so I assume it is hardcoded behaviour?), but otherwise I think this scroll type could be a new action which users can bind to, for example, Mod+MouseWheelUp. Binding to, for example, "smooth-scroll-right" instead of "focus-next-window".

Based on other discussions, there is also talk of disabling the snapping to view the whole window to help with, for example, copy+paste from documentation/examples into an IDE. This would require a different top level config for scroll type, which could be tied to the 3-finger-swipe behaviour.

Pros:

• the column can be arbitrarily wide
• users can (optionally) choose to not focus the whole display

Cons:

• complexity adds/changes/creates divergence in the snapping rules
• possibly not in line with the original developers' design principles

Option 3 - DISMISSED (same as option 1) Both of the above

If we implemented both, users could decide how to navigate extra-wide windows. From a cursory look at the code-base, the helper functions for the maths for all of this is already in place, the PR would be small.

[MintyDoggo]

I think both options would be nice to have, but realistically Option 2 is a much easier implementation to help alleviate some issues here

As you mentioned, we already have 2 PRs open for Option 2, mine handles column alignment and the other handles window alignment

We would ideally want to update these, either combining both into 1 or or making both compatible with each other and keeping them as 2 PRs

Awesome ideas though and just ping me if you want any review or help

[artiepoole]

Thanks for being open!

I have just started to work on this now. I am trying to combine your work with #1929 and the ideas from both can definitely live together easily enough. I already managed to rebase #1929 onto main, just minor refactoring.

I plan to take the #3033 single enum approach and to borrow the #1929 maths for alignment. I plan to change the names of all the functions and arguments to match the verdict made in #1929 comments from YaLTeR (align-window horizontal="left|right|center";) and then to make it easier for vertical alignment to be implemented.

Both approaches currently keep a "align-left" style fallback for overwide panes, so I plan to add a catch, and a top level layout state for this (similar to the already existing always-center-single-column option - which may need some reworking).

Do you have any other thoughts I should be aware of?

Very rough so I'll ping when it is ready for review but if you're interested the WIP branch is: https://github.com/artiepoole/niri/tree/artiepoole/feat-scroll-view