Provide windowrule for conditionally overriding a new window's "row mode"/"column mode" placement strategy

[chaorace]

When browsing the web, I open all new tabs as windows (via qutebrowser's tabs.tabs_are_windows option) because it allows me to spatially organize my browsing using the WM (example image included below).

When using this workflow with hyprscroller, I find myself fighting the WM because it always wants my new qutebrowser windows (read: browser tabs) to open as new columns when 90% of the time I would have preferred for the window to have opened under the same "stack" (read: column) as the original. Everytime I open a tab, I have to stop what I'm doing to admit the new window and manually scroll the viewport back into position.

It'd be preferable for my usecase if I could use rules to instruct the WM to always open certain windows as pre-admitted into the currently active column. The plugin:scroller:group windowrule seems unable to facilitate this because it only supports sending matching windows to a specifically dedicated "group" column.

There's a lot of different ways to skin this particular cat, but the simplest would be to extend the existing plugin:scroller:group windowrule with "special groups" which specify columns in relative terms, such as...

• *before current*: Insert matching window in the same column/row as the currently active window, above/left of it
• *after current*: Insert matching window in the same column/row as the currently active window, below/right of it
• *start current*: Insert matching window in the same column/row as the currently active window, in 0th position
• *end current*: Insert matching window in the same column/row as the currently active window, in last position

If the "special groups" concept is deemed to be too kludgey, I might instead suggest creating an entirely distinct windowrule with purpose-dedicated syntax (i.e.: plugin:scroller:admit before/after/start/end first/last/current [no-focus]). I won't bikeshed it too much -- pretty much any possible implementation should effectively satisfy my individual needs 😁

P.S.: Thanks for your work on this plugin. It's a real breeze to use and impressively stable to boot ❤

[dawsers]

OK, I understand the concept of what you want. I would like to know more about how you would use those window rules to facilitate your workflow. You would need to set them up in your configuration, and they would be "fixed", so when you are going to open a new "tab" there would need to be a trigger in the window title or whatever that makes those windows go to the right position in the right column. Is that something you are OK with?

Or do you think maybe it is better to confront the problem through some dispatcher, like the current row/column modes? It would be something like window creation modes you could trigger through a dispatcher. And when you are in a certain mode, new windows are set up at the right location. It would work like your "rules", but applied dynamically (before/after/etc.). This has the advantage of being dynamic, and useful for more cases, but the disadvantage it may require a keystroke when changing "modes".

Let me know your thoughts.

[chaorace]

I would like to know more about how you would use those window rules to facilitate your workflow. You would need to set them up in your configuration, and they would be "fixed", so when you are going to open a new "tab" there would need to be a trigger in the window title or whatever that makes those windows go to the right position in the right column.

I may have overcomplicated the usecase demo. For my usecase, I want to change the default behavior for all qutebrowser windows from "open in new column" to "open in current column". That's my intent 90% of the time and for the other 10% I actually prefer to manually reorganize everything anyway.

To put it another way, in terms of that hypothetical plugin:scroller:admit windowrule, I'd just need one line of configuration:
windowrulev2 = plugin:scroller:admit after current no-focus, class:org.qutebrowser.qutebrowser

Or do you think maybe it is better to confront the problem through some dispatcher, like the current row/column modes? It would be something like window creation modes you could trigger through a dispatcher. And when you are in a certain mode, new windows are set up at the right location. It would work like your "rules", but applied dynamically (before/after/etc.). This has the advantage of being dynamic, and useful for more cases, but the disadvantage it may require a keystroke when changing "modes".

Ultimately, any means of controlling the behavior would make me happy. If it were up to me, though... I'd say that these two approaches aren't mutually exclusive and in fact complement each other rather nicely. An analogous example in the builtin layouts would be how the group windowrule is complemented by the *group dispatchers; some groups are predictable and consistent, thus desirable to group via rules (e.g.: a dedicated group for Teams/Slack/Meet/Zoom) whilst others are more transient, thus desirable to group via dispatchers (e.g.: a group for apple pie recipes).

[dawsers]

So you can basically browse in column mode, but need a [no-focus] flag for new windows...?

That would be the simplest solution that gets the 90% you described.

Of course, if I implement that, I would add more stuff, but I just want to make sure that is what you are talking about.

[chaorace]

Oh! I see what you mean. I hadn't really been thinking in terms of the row/column mode switching. That would probably work for my usecase as-is. I don't really like any of the other changes that switching into the "column mode" triggers in the WM, but it's a much smaller issue than what I currently have

[dawsers]

I have implemented scroller:setmodemodifier in 00725c3

Please, have a look at it and let me know if this solves your problems.