feat: focus-workspace-or-monitor-up and focus-workspace-or-monitor-down

[salman-farooq-sh]

@lpnh Thanks for the new feature in #456!

I was wondering if the same thing can be done for upper and lower monitors too i.e. focus-workspace-or-monitor-up and focus-workspace-or-monitor-down. It would work the same but instead on workspaces, though it needs to be discussed how the last/bottom-most workspace which is dynamic should be handled.

Possible options:

1. A flag or variation of the up and down binding that skips the last and empty workspace before moving the monitor up or below.
2. Fixed number of workspaces? I think 1 will still be helpful.

My particular use-case is 2 external monitors plus the laptop's built-in screen. But I know many people who use a single small 24" external one raised by some books on top of their 15" macbooks (sorry no niri for them :)).

My logical layout:

.-----------. .------.
| 32"       | | 24"  |
|           | |      |
*-----------* |      |
     .------. |      |
     | 16"  | *------*
     *------*

Another one:

.------------.
| 24"        |
|            |
*------------*
   .------.
   | 15"  |
   *------*

Edit: Sorry, I missed the existing discussion
Duplicate of: #296

[lpnh]

Thanks for sharing your thoughts and suggestions! If I had to choose, I would probably follow something closer to the first approach. The thing is, I was planning to start working on focus-column-or-monitor-* to finish what I started. I'm just waiting for feedback on my current PR. To give you an answer, I would love to implement these other two if I receive approval.

[lpnh]

Hey @SalmanFarooqShiekh, I would like to hear your opinion on this. I was working on a focus-window-or-workspace-or-monitor-{down/up} action and noticed the new PR #497. Do you think an action like focus-window-or-workspace-or-monitor would still be useful for your use case? If so, how do you feel about the behavior of "checking for an available window before trying to switch to the other workspace"? Do you find this addition relevant to your suggestion?

[SalmanEsketchers]

My ideal layout would be 5 monitors but most laptops only support 4 at most and I do need a laptop. So I am after this when I get the 4th monitor:

.------. .------------. .------.
| 24"  | | 32"        | | 24"  |
|      | |            | |      |
|      | *------------* |      |
|      |    .------.    |      |
*------*    | 16"  |    *------*
            *------*

[salman-farooq-sh]

But I am also quarter-a-mind to ditch all the external monitors because a big reason I tried Niri was in my search to replace what I felt at times to be hardware "bloat" (i.e. all these extra monitors) with a beautiful maybe-unicorn software solution. My baseline requirements were:

1. Something with liquid-smooth window switching animations so it feels as natural and less jarring as possible moving between stuff (just like the real world moving between physical objects)
2. An easy mental map of where all my offscreen windows are, that I am able to keep effortlessly updated or be "in sync" with. Something I can navigate directionally (aka real physical world vibes) instead of having Mod+{A-Z} each hard-bound to particular windows. Think about it, your mind works by placing stuff to the up/down/left/right/behind/front of other stuff.

Having these two things makes even a single monitor a joy to work on. Niri does all this for me, currently short of being a freely 2d scrollable area of windows, which it is almost, which I half-think might not even be all that practical in real-life but I know one thing, if anyone can do it well, it will be Niri. Niri was an actual real working implementation of what I thought existed only abstractly in my mind.

Plus Niri looks so cool ngl hehe.

[lpnh]

Thanks once again for sharing your thoughts and suggestions! I'll try to address some of them here.

It was just an extra key bind or two to move from the second or third column on the portrait monitor to the monitors on the left. I found it much quicker to just switch monitors with the dedicated binds.

I think I agree with you, it probably works better for use cases with one or two columns at most for each workspace. At least, that's why I think it's useful for me.

A solution that has come to my mind as I wrote this (and I will try it tomorrow) is that I put each of the three portrait text editors in three separate workspaces on the portrait monitor.

Yeah, this would be my suggestion. As someone who was initially reluctant to include workspaces in my workflow, I found they can be quite useful, though they do add some complexity. What I do is give each one a specific purpose, so I can predict what I will find in each. However, I'm still exploring what workflow would be the best fit for me.

I guess I don't use workspaces much if at all on the two monitors placed one above other. So either solution for me will work

So, I think I'll just drop the focus-window-or-workspace-or-monitor-{down/up} for now. In my opinion, we should avoid adding unnecessary extra actions.

but I know one thing, if anyone can do it well, it will be Niri

Yeah, I share this feeling too. I really like YaLTeR's design choices, and I trust their judgment on how things should be.

So, that's probably it. Let's keep having fun with Niri. Feel free to ping me anytime.

[salman-farooq-sh]

I think I agree with you, it probably works better for use cases with one or two columns at most for each workspace. At least, that's why I think it's useful for me.

It definitely did deserve being added to Niri, that's why YaLTeR accepted it and I will use it too tomorrow again, hopefully long-term this time.

I guess I don't use workspaces much if at all on the two monitors placed one above other. So either solution for me will work

So, I think I'll just drop the focus-window-or-workspace-or-monitor-{down/up} for now. In my opinion, we should avoid adding unnecessary extra actions.

I think I made a mistake in that. Upon further thinking, #497 won't work for me because using it I won't have the same bind being able to switch workspaces on the portrait monitor AND switch between up and down monitors on the left of portrait. So, focus-window-or-workspace-or-monitor-{down,up} will be usefull afterall. Besides in my opinion focus-window-or-workspace-or-monitor-{down,up} is arguably more in line with and in spirit of focus-column-or-monitor-{left,right} than focus-window-or-monitor-{down,up} is. My argument is focus-column-or-monitor-{left,right} lets you explore the whole horizontal space across monitors and strips, something which does the same for vertical space across monitors and workspaces (kinda imagine them as vertical strips for this, or vertical scroll area) should also exist, making the whole global coordinate space including all the workspaces and columns in it, navigable with just 4 simple directional binds. This is definitely not unnecessary imo. Users should have both options available to freely choose from, otherwise it's just less flexibility and less use-cases addressed.

"checking for an available window before trying to switch to the other workspace"

I assume you mean to ask about skipping or not skipping the last empty workspace when moving to a monitor down. My opinion is same for this too. Let's not limit the user to either option. @YaLTeR what do you suppose the config should look like for adding all of this and #497?

Yeah, I share this feeling too. I really like YaLTeR's design choices, and I trust their judgment on how things should be.

Me too.

[YaLTeR]

I assume you mean to ask about skipping or not skipping the last empty workspace when moving to a monitor down. My opinion is same for this too. Let's not limit the user to either option. @YaLTeR what do you suppose the config should look like for adding all of this and #497?

The actions themselves should be fine to add as they thankfully don't add too much of a maintenance burden. As for skipping vs. not skipping the empty workspace, let's first try one of these and see if it feels right? Then if you feel like you sometimes need one and sometimes the other, we can think how to configure it (maybe just a property on the action itself).

[salman-farooq-sh]

@lpnh Let's do further conversation on this in #296 because this was really a duplicate of that made in error from the beginning. Let's not scatter the convo more.