Crop And Lock (Reparent mode) style vertical viewport for each window/column

[Jarvvay]

This is not a feature request (although it vaguely suggests one). More like an experience story, to see if anyone in the community shares the same feeling with me. Very likely I got terribly wrong ideas / It's indeed my skill issue / I'm complaining about the wrong thing. If that is the case, I'd be thankful if people could point to me where I've been doing the dumb thing/not completing my due work.

---

Crop And Lock is a PowerToys utility that helps you focus on specific parts of your applications by creating smaller, cropped windows.
See Microsoft's demo animation.

In a word, their reparent mode carves out an "interactable"/input-passthrough thumbnail, which can be used afterward as a compact inplace replacement for its source window.

Before the long rant, I feel obliged to make it clear that the thread is not about adding general thumbnail creation feature to niri. That would better be left to some independent Wayland utilities. Rather, it's more of a question/discussion regarding (1) the general usefulness of a "vertical clipped view" for potentially enabling flexible/opportunistic/less disruptive layout, (2) how it can be achieved/utilized in niri, and (3) if it's a good idea overall to build it into niri. "Crop And Lock" in the title is only used as a keyword for other users to locate this thread, because I feel "vertical viewport" alone isn't very helpful to see the crux. But it should be noted that the feature proposed here is in large part unrelated to the thumbnail functionality found in the Microsoft tool, apart from the fact that both of them do the cropping.

---

Here begins the story.

Many users, me included, base their workflow on niri's best practice recommendation: 1-2 columns for "major work" in each workspace's "main" view, info/temporary windows going offscreen to the left/right end of the scroll. This flow works smoothly for many sessiones. And if you decide halfway you want switch/create "major work" column, you don't need too many keystrokes to transform into your new desired layout, provided you have proper default-column-width & preset-column-widths options in place.

This is the best way to get the most out of niri's toolset, and I'd love to follow it whenever applicable. But occasionally situations come up that I find it hard to adapt:

1. Normal column(s) A next to a fullscreen window (maybe a vertical 2-pane vim), where crossediting in quick succession between fullscreen window's right pane and normal column(s) A is needed. But switching into/out of fullscreen window each time triggers a whole screen slide animation (due to repetitive snapping), making it tiring to regain context;

2. "Interactable peekable window", like a music player sits across the right edge of screen, just sticks out long enough to let user see part of the playlist view. Now whenever user tries to interact with the "peekable window" (jump to another track for example), a workspace shift happen, defeating the purpose of a "peekable window";

3. Juxtaposing multiple windows of different width into one column for quick compare/back-and-forth using focus-window-up/down. When forming column, Niri reasonably stretch/shrink every other window to the width of first window in the column. This could be undesirable. Sometimes one of those windows would be better served if it takes a different width from others. Sometimes all of these windows have slightly different width for their "best" layouts. The behavior that window's width may change after being consumed also sort of goes against niri's "window size invariance" goal imo.

All of the above are in one way or the other revolved around the theme of "switching to a predefined width is not the best option, but not switching works against niri's model leading to viewport shifting/jumping around".

I have to agree they are probably misusing niri to force-adapt to their niche use case. For case 1, rather than editing in a half visible vim window (prone to making unexpected user interaction), it's better to use a vim script to turn the 2 panes in vim into 2 columns in niri so that the right column can now be properly fit in a screen together with A column; For case 2, media control/track name preview/switch should ideally be served with a shell component/a vertical scrolling ui music app, not the edge case of a window manager; For case 3, float every window and position them onto the same coordination should work for overlay comparison.

But I want to point out that most of these use cases have a transient nature. It means users bumping into them don't expect them and most likely would want it to be dealt with on an ad-hoc, get-it-done basis. Users don't plan a scenario of fullscreen window right beside a normal one, they encounter it. And while splitting fullscreen window into its proper column is the correct way going forward if you are going to start a long editing session, for quick dirty editing this is just extra management steps/change in navigation paradigm that delays the workflow. Not changing viewport to accommodate the focues window fully into view is definitely an anti-pattern, but here users wanting this behavior is (hopefully!) well aware of the caveat, and they are willing to consciously exchange safety for viewport stablility for this particular case involved. Similar considerations for the other two cases. Users wanting a sticky peekout window knows their music player UI is unlikely to give any surprise even if interacting with a largely hidden one. And user wanting overlay comparison is deliberately asking for it, and should be responsible for reversing the justapostion after the comparison is done.

---

There have been various requests here trying to solve the surprise/unwanted viewport jumping problem, of which I like the most are "disable snapping and fix the workspace viewport" and "sticky column", though it does not seem that either one are going to see big progress in near future, as there're still undecided design choices, and they lack a straight way to incorpate into niri's codebase.

So here is my two cents to further muddy the waters :).

I've been casually considering a set of niri actions to turn any window/column into a viewport of itself. By viewport I mean shrinking the width of that window/column no longer changes the window width and instructs it to recalculate its layout. Instead, part of the window shrunk out of the borders is simply hidden, while the window itself, completely unware of the shrinking, doesn't have to do any reflow or even rendering, because conceptually the shrinking here only affects the window/column's viewport, not the window/column that viewport is currently "casting".

Below is a concept demo. The right "nest" window is a (wide enough) floating window running inside a nested niri session window which is itself tiled on the host niri session, to emulate a window that has been turned into its own vertical clipped viewport as described above. The left "host" window is just a normal tiled window on the host. You can see the viewport window don't have to recalculate its layout as its frame gets resize. It's because what I'm resizing is just a viewport, and the underlying window is untouched at all.

resize-vs-viewport-resize.mp4

I believe these "viewportify" actions have the potential to fit cleanly within the niri model because:

• Currently only workspace can have a viewport, and this "viewport for window/column" thing adds a new dimension, orthogonal to other layout concerns, which means it shouldn't be interfering with any exsiting assumption baked into the niri codebase, particularly the "snapping/scroll into view" bit;

• The "window itselt not knowing border change, thinking it's still using the previous width" part feels like a natural extention along the line of niri's existing "windowed fullscreen" idea, where "window itself doesn't know the real window state, believing it's fullscreening within its border";

• This doesn't conflict and perhaps interacts well with other proposals fixing the same problem. Could be implemented as a first step towards more layout control approaches. From a philosophical perspective, when compared to a traditional tiler, Niri preserves auto-tiling convenience, and tries to trade workspace compactness (ws potentially spanning a long scroll) for window size stability (no auto resize), while this "viewport for window/column" proposal preserves window size stability (still no resize) and tries to trade window visibility (partially hidden window UI anti-pattern) for viewport stability (cropping helps avoid unnecessary workspace shift and makes shorter scroll possible);

• With the help of (yet another) indicator bar, it can hint to the user if the current window/column is being clipped/displayed partially, and if it is then the bar can function as a real scroll bar which user can control manually to show other part of the window/column, which might help mitigate the window visibility issue above;

• This is fully backward-compatible. For users averse to the "scrolling for individual window/column" idea, they can simply choose not to use any of these actions, so cropped window/column won't come up as an accidental complexity to them.

It would enable more use cases if a niri action exists to crop the hovered window/column along the monitor edge (should be strut edge, to be precise). This action can be seen as an inversed version of expand-column-to-available-width, except that it shrinks viewport instead of expanding column. After cropping, targeted window/column will become eligible for auto focus switch with focus-follows-mouse max-scroll-amount="0%", since the window/column is now fully contained inside the screen.

Below is purely for explaining the idea of how such an action would work in practice, as I haven't found a way to extract precise scroll location from niri ipc (Well, what is really needed is a tiled window's absolute location, like tile_pos_in_workspace_view but for tiled window). You can see that workspace stop shifting and autofocus starts to work after cropping is done, and that cropping doesn't change its target's layout.

crop-at-screen-edge-for-preventing-workspace-shift.mp4

Both of above two demo videos build upon nested niri session. The one level of indirection is giving me two cursors and breaking clipboard sharing. I've also not thought about a good way to emulate shrinking the viewport from the left. (While niri IPC provide stream data of resizing, it's too discrete to allow a smooth mirroring from the nested session) So ideally this would look better if built into the compositor.

---

Thanks for reading this and bearing with my bad wording and messy style. I strive to maintain a clear intention, but I'm not so sure if I've been able to picture the full landscape of this problem in mind. There are possibly many glaring factual errors and horrible misunderstandings. Like I say in the beginning, this thread is more about sharing vague experience and collecing thoughts. (I should really have done more research/experiments to see how it goes for myself!) So what do you think about this feature? Is it convenient/awkward? If you like it, what kind of usage for it do you have in mind? And are there any possiblilities to do it outside the compositor? If you hate it, is it fixable (like limiting its scope to certain use case), or is it fundamentally broken and not gonna work out at all?

[YaLTeR]

Thanks for the write-up. I agree with your three problematic cases, I hit them myself too when having to deal with many windows at once (especially case 1).

The viewport clipping is an interesting idea, but I'm not sure it helps here? Like, that's a whole separate action (-s?) to remember, just for this situation. And it's unclear to me how to scroll inside such a clipped window. Basically it feels like more effort than just dealing with case 1 through other means.

For case 2 arguably some view lock proposals are better suited.

I'll also add that dealing with many windows is just generally annoying, regardless of the WM. I get similarly overwhelmed on GNOME for example, just there it's overview + alt-tab searching instead of scrolling back and forth. This isn't to say that we shouldn't try to come up with a better system for dealing with this; just that this is a problem all WMs are facing.

[Jarvvay]

Totally agree. I'm also not really confident if adding a whole new axis (maybe even serveral! Haven't decided if clipping from either side is useful) to iron out just a handful of edge case is really helping the whole situations here. That's the reason I'm posting here to see if anyone in the community would come up with some better ideas :)

For your "a whole separate action" concern, I believe an auto clipping keybind (hit the keybind to clip all the visible window on screen) should achieve an effect very similar to that of the view lock proposal, with the added benefit (maybe?) that you can still scroll the view, as it's only those windows that cross the screen border get clipped out.

Yea, WM is a HARD PROBLEM! I'm really impressed at the amount of effort put in niri to ensure its user interface feel natural and its implementation clean from edge case, as well as carefully choosen sane defaults providing an enjoyable process for newcomers. A breath of fresh air indeed.