Proposal: A "Global Jump Container" mode for easier navigation across the entire workspace

[with9]

I really love Scroll, it's a fantastic and refreshing take on Sway window management. Thank you for your work!
I love the implementation of jump container. jump provides an overview of everything on active workspace, but when the scroll is very long, the windows can become very small/hard to see. Could we have a mode (perhaps called jump tab or a global version of jump container) that displays all windows on the active workspace in the same style as jump container?

[dawsers]

But you would have an even worse idea of the content. jump container has to cut content off the view to show all the views in the container. Instead jump only scales them. I think scaling them gives a better idea of what is inside the view (even if it is small, at least it represents the content). If, like you say, you have lots of windows, so many jump is not working for you, this new mode would let you see even less, it would be impossible to discern what each window is, you would only see a couple of lines of unscaled content for each.

For jump container, it made sense to do it that way, because if I had scaled the windows, then I would have had to scale all the others in the row, and that would have created a discontinuity for people who want to have one view always focused while accessing a random view from the nearby column (imagine an editor, and several terminals or documentation on the nearby column).

So I am not sure this is a good idea. I would need more convincing. Maybe you have too many windows in a workspace, and things become hard to manage. Maybe you could use trailmarks to mark your most used applications, and then use jtrailmark jump to move to them?

Thank you.

[with9]

Thanks for the detailed explanation!

You've convinced me—I agree that scaling is generally better for recognizing content, and having windows clipped into "thin strips" would indeed make them hard to discern.

Interestingly, I found a workflow that works perfectly for me by combining commands: bindsym key focus right; jump container

[TheTechRun]

I must be doing something wrong because jump container does nothing when i call it. jump workspace and scratchpad jump work fine for me though.

[dawsers]

I must be doing something wrong because jump container does nothing when i call it. jump workspace and scratchpad jump work fine for me though.

Do you have more than one window in the active column when you call jump container?

jump container is a jump mode for the current column that shows all the windows in that column in a jump view that only affects that column.

[TheTechRun]

Just to be clear:
On my ultrawide in horizontal mode, 3 programs left to right would be 3 columns correct?
On my portrait monitor in vertical mode, 3 programs top to bottom are rows?

Edit:
I misunderstood what jump container was (I think), but even with programs open in the same column on multiple workspaces jump container still does nothing.

If so, then no jump container does nothing. I am on nixos using the flake from the README.md. Not sure if I am hijacking this thread... so should I just create an issue?

[dawsers]

Just to be clear: On my ultrawide in horizontal mode, 3 programs left to right would be 3 columns correct? On my portrait monitor in vertical mode, 3 programs top to bottom are rows?

Edit: I misunderstood what jump container was (I think), but even with programs open in the same column on multiple workspaces jump container still does nothing.

If so, then no jump container does nothing. I am on nixos using the flake from the README.md. Not sure if I am hijacking this thread... so should I just create an issue?

Let me explain the different jump modes and container hierarchy in scroll in case there is some misunderstanding.

Unlike sway or i3, which use an "infinite" tree hierarchy of vertical/horizontal splits, scroll only uses a 2-level hierarchy.

Let's consider you are using a landscape monitor, which is the most common use case, for portrait mode (and vertical layout), simply swap the words column with row and v with h.

When you are in an horizontal layout (generally useful for landscape monitors), it creates a row with columns. This means, by default, opening new windows will add columns to the main row (there is just one row, containing the top level of the hierarchy). Then, if you want, and change mode (set_mode v), you can add any numbers of containers to the current column. Those new containers are the second level of the hierarchy, and what jump container would show.

So if you only have your row of columns, and each column only has one window, jump container won't do anything, because there is nowhere to jump to: your current column only has one container window, so jump container would only let you jump where you already are.

So jump container only applies to the current, active column, and will only let you choose when that column contains more than one container. The opposite happens in portrait mode if you are using a vertical layout. In this case you have a column of rows, so jump container will only show you something, if your current row has more than one window.

In general, you will want to use jump (without container or any other argument) to move around the active workspace. jump container is just for people who use lots of windows in a column, and need to quickly access one of them while keeping a regular view for the rest of the workspace. I personally almost never use it.

So you have jump workspaces to quickly select a workspace with an overview, jump, to jump to any window in the current workspaces for all the monitors, jump container to select a window for the current column, trailmark jump to select one of your trailmarked windows for the active trail,....etc. Each jump mode serves a purpose, though I agree maybe there are too many and in the end you could find it confusing. But each possible workflow with scroll (and there are many possibilities!) favors one or two of them.

Let me know if you still have any more doubts.