riverwm
[Feature Request] Single tagset / Shared tags
Is it possible to get a single tagset across all outputs (Like qtile or spectrwm) instead of one for each output? As far as I know, it can't be done with riverctl.
If im not wrong then each output has its own u32 bitfield. Would it be possible to solve this using a u64 or u128 for all monitors, and then optionally bitshift for per-monitor tags (Something like tag << (m * n), where m is the monitor index and n the number of tags for each monitor)?
This is something I've been considering, but it's a pretty big change so it probably won't happen anytime soon. It would also require views to have exactly 1 tag instead of an arbitrary number and the ability for outputs to have no tags focused.
River will either switch to a single tagset across all outputs or it won't, I don't want to support the complexity of both.
Oh okay, guess I'll have to wait and see if that change happens. Would it be hard/possible to maintain a fork with that functionality?
Would it be hard/possible to maintain a fork with that functionality?
You're welcome to try, but it would be a pretty difficult task for someone new to river's codebase I believe. I do plan on working on this in the 0.2.0 release cycle, and hope to finally release 0.1.0 in ~1 week.
As long as tags are not bound to an output and on activation appear on the output the user currently focuses instead of the output focus changing, I am on board.
Although I must say I do prefer the current behaviour.
As long as tags are not bound to an output and on activation appear on the output the user currently focuses instead of the output focus changing, I am on board.
I 100% agree that output focus should never be switched automatically when focusing tags. Focusing a tag will always cause it to become focused on the currently focused output. If that tag was currently focused on some other output, it will first be unfocused there. Moving focus between outputs will always be a manual operation triggered by an explicit command by the user.
This would also make me feel a lot better about implementing foreign toplevel activation requests (#335) as changing output focus under the user will never be necessary.
What are the use cases this change would support? For me, I might like to be able to send all the views in the current tagset to another output. Maybe implementing a riverctl command to do that would be enough?
- I think its useful if for example your editor is on your 1st output and your browser is on your 2nd output, you can just activate the Tag with the browser on your 1st output to view documentation and code side by side, instead of having to manually bring the view over.
- It's easy for "standby-apps" (eg. music player, chat client), because you can quickly access them from any output.
- You also don't have to search for Views across different outputs (If you don't remember where you put them like me).
- You don't loose access to Views on a output if its broken/buggy (Sometimes River just disables my 2nd screen, and then i have to manually move the views from the black screen)
I hope that answers your question.
You don't loose access to Views on a output if its broken/buggy (Sometimes River just disables my 2nd screen, and then i have to manually move the views from the black screen)
I just tested disabling my second output with wrandr --output DP-1 --off and all views got reassigned to the remaining output while keeping their tag assigments. A broken+enabled display could make windows inaccessible but explicitly disabling it should make them available again.
I like this idea but wonder how this will effect things like scratch pads that use higher numbered tags.
i can think of work flows that would be nice if you culd have a single tag in the 1-9 range + a tag from the 10-31 range on just the current output.
This could likehy be done with helpers that allowed you to move views from a higher tag to the current one and back easily though
If there is a move to just having a single tag per workspace would it be possible to have per tag settings for things lke main_ratio and main_count.
This would be useful for places where you want to do actions lke changing the point where you insert a new client in the view list. If your layout has private copies of these values like stacktile has then you re limited n that you only have access to the glabal values in the river code base which may not be the same as what your layout is seeing.
would it be possible to have per tag settings for things lke main_ratio and main_count.
That is the job of the layout generator and in fact already perfectly possible.
If your layout has private copies of these values
It's not that layouts have "private copies" of the values, these values only exists in the internal state of layout generators. River itself has no concept of "main views", "main ratio", "gaps" or anything like that.
I like this idea but wonder how this will effect things like scratch pads that use higher numbered tags.
It will work exactly as it does now. There is nothing magical about "higher numbered tags".
The only difference is that the so called "scratchpad" would be shared across all outputs.
at present if you were wishing to create a.command to position new windows as the first slave how would this be done.
Do layout managers like stacktile update the internal values in river on a tag change?
If so I have no issues.
On Mon, 20 Sep 2021, 12:35 Leon Henrik Plickat, @.***> wrote:
I like this idea but wonder how this will effect things like scratch pads that use higher numbered tags.
It will work exactly as it does now. There is nothing magical about "higher numbered tags".
The only difference is that the so called "scratchpad" would be shared across all outputs.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ifreund/river/issues/357#issuecomment-922566726, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJN5S4Z56VW6V5XKBVOG7MDUCZ6T7ANCNFSM5ALSM3KQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
at present if you were wishing to create a.command to position new windows as the first slave how would this be done. Do layout managers like stacktile update the internal values in river on a tag change?
Layout generators (they are not "managers", they don't actually manage anything, all control lies with the server) have no influence on rivers internal state except for window position and dimensions, except for when they make use of the river-control protocol extension.
But as I already said river has absolutely no concept of "main area" and "remainder area" (or however else you choose to call these concepts). This is an intentional and important part of the design that allows us to both a) keep river itself as simple as possible and b) offer a massive amount of creative freedom to developers of layout generators.
So no, the layout generator can't just tell river "hey, please always put new windows in this area over here, thanks!".
However, the use case of having new windows not displace the window
currently at the top of the stack is a valid one. In fact, we already
offer a way to have new windows attach to the bottom of the stack. I
always intented this attach-mode configuration to have more option
than just top and bottom (somewhere else the addition of
before-focus and after-focus was already discussed and reveived my
approval). I am certainly open to extend this configuration option to
allow attaching windows at arbitrary position in the stack; The layout
generator then would need to update this setting whenever its internal
configuration for the amount of windows in the main area changes.
And alternative approach that in my oppinion is equally valid will open up in the future: We plan to outsource filters to external clients as well. Allowing filter daemons to place windows at arbitrary positions in the stack makes sense. A combined layout plus filter daemon could easily have the funcitonality of placing new windows at a specific position in the stack. But it will still take some time before we get to this point; Redesigning the river-control protocol extension will not be easy and requires lots and lots of time.
Friendly greetings, Leon Henrik Plickat
Thanks for the info. I think that iI may have been getting river confused with dwm/dwl which has those concepts embedded.
One unrelated question. Is there any chance that stacktile will get a monocle mode in the future?
On Mon, 20 Sept 2021 at 14:39, Leon Henrik Plickat @.***> wrote:
at present if you were wishing to create a.command to position new windows as the first slave how would this be done. Do layout managers like stacktile update the internal values in river on a tag change?
Layout generators (they are not "managers", they don't actually manage anything, all control lies with the server) have no influence on rivers internal state except for window position and dimensions, except for when they make use of the river-control protocol extension.
But as I already said river has absolutely no concept of "main area" and "remainder area" (or however else you choose to call these concepts). This is an intentional and important part of the design that allows us to both a) keep river itself as simple as possible and b) offer a massive amount of creative freedom to developers of layout generators.
So no, the layout generator can't just tell river "hey, please always put new windows in this area over here, thanks!".
However, the use case of having new windows not displace the window currently at the top of the stack is a valid one. In fact, we already offer a way to have new windows attach to the bottom of the stack. I always intented this
attach-modeconfiguration to have more option than justtopandbottom(somewhere else the addition ofbefore-focusandafter-focuswas already discussed and reveived my approval). I am certainly open to extend this configuration option to allow attaching windows at arbitrary position in the stack; The layout generator then would need to update this setting whenever its internal configuration for the amount of windows in the main area changes.And alternative approach that in my oppinion is equally valid will open up in the future: We plan to outsource filters to external clients as well. Allowing filter daemons to place windows at arbitrary positions in the stack makes sense. A combined layout plus filter daemon could easily have the funcitonality of placing new windows at a specific position in the stack. But it will still take some time before we get to this point; Redesigning the river-control protocol extension will not be easy and requires lots and lots of time.
Friendly greetings, Leon Henrik Plickat
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ifreund/river/issues/357#issuecomment-922603167, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJN5S43DPJEANPDFOXKDEBDUC2NF3ANCNFSM5ALSM3KQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
One unrelated question. Is there any chance that stacktile will get a monocle mode in the future?
It already has, just under a more descriptive name.
Any news on this? I'm asking decision-wise, not implementation-wise. In which direction will River flow? :wink: @nzure described the use-cases beautifully in https://github.com/riverwm/river/issues/357#issuecomment-894494937
All 4 use-cases are my 4 topmost critical issues I have with River and I switch outputs very often so for me the point 4 is not like Sometimes River just disables my 2nd screen but like I often reconnect my 2nd or 3rd screen to different devices like a work laptop or some SBC and in case of single tagset I would have just easily written a script which would treat some of tag bits as preferred output information and on any change to outputs or perhaps explicitly on a keyboard shortcut try to move
- 0x01-0x09 tags to monitor 0
- 0x11-0x19 tags to monitor 1
- 0x21-0x29 tags to monitor 2
@Grawp Decision wise river will 100% be usable in this way eventually. The implementation may take me a while though as I'm planning significant architectural changes to make this and many other features possible without changes to the compositor itself.
I would also love to see this! As someone with 3 monitors, i move multiple views between monitors quite frequently
