riverwm
Add select flag to toggle-focused-tags command
Hello everyone!
The Story
Because I used both sway and Hyprland for some time I was a little bit annoyed that I always had to press to buttons to 'emulate' scratchpads on river. Therefore I sat down and implemented this change.
The Change
When the -select flag is set in the toggle-focused-tags command, the command also tries to focus the first view in the given tag.
This is done so you don't have to first toggle the focus and then manually have to select the window.
Additional Notes
Currently this change has been running for me for more than one month straight without any problems whatsoever. I'm open for every kind of feedback and will implement the suggested changes, if you want to.
This should also close #789, if I understood the comment correctly.
I think that implementing #912 would be a much more composable and generally useful way to achieve what you want.
You mean by doing the following?
riverctl toggle-focused-tags $tag
riverctl focus-view 1
How do I ensure that the toggled tag(s) are always on top (e.g. at position 1)? Or if that's not the case how do I get the correct position?
While testing this in theory the toggled tags always got inserted into the last position they had in the stack. So always focusing the topmost window would not work. Am I missing something?
When this questions are resolved I would happily implement the riverctl focus-view n command over the holidays because I'm on your boat considering this would be a more generally useful command to achieve what I want. 👍🏻
Just adding a +1 for this feature (or the discussed riverctl focus-view n if it would solve the same problem). I am a big fan of the floating terminal scratchpad in sway, and this patch makes it doable (or at least no longer frustrating) in river as well.
I think this is a lot of accidental complexity and that the correct way to implement a scratchpad feature with good UX is to hardcode that feature in the window management logic rather than make the existing tag management features complex/flexible enough to do this.
Since I don't have plans to hardcode scratchpads in the river compositor process and do have plans to push window management logic out of the river compositor process to a separate "window manager" process (i.e. a layout generator on steroids) I think I'll close this PR for now.
Scratchpads with good UX will be possible and probably much easier to implement once my river-window-management protocol vision is realized.