ifreund changed the topic of #river to: river - a dynamic tiling wayland compositor - https://github.com/ifreund/river - channel logs: https://freenode.irclog.whitequark.org/river/
<leon-p> pkill9: you don't need a list of all tags. River always has 32 of them.
<pkill9> oh ok
<leon-p> what you want is the currently active tags of an output
<leon-p> you can get that using the river-status protocol
<leon-p> you'll have to write a wayland client basically
<leon-p> but what you want is definitely possible
<leon-p> it's also not particularly complicated. So even if you have not written wayland code yet, you could do it.
<pkill9> cool
<leon-p> in short, you can get the currently active tags of an output as well as a list of all view tags per output. You'll have to AND the entire list to know which tags are occupied. Then you need to determine an occupied tag that has a higher/smaller index than the currently active one and set that one as (solely) activated.
<leon-p> but careful: multiple tags could be active at once
<pkill9> i eventualy want to treat multiple tags as another workspace
<pkill9> idk
jjanzic has quit [Ping timeout: 264 seconds]
Misthios has quit [Ping timeout: 256 seconds]
exception has joined #river
<pkill9> so is all WM info via river-status and needs some binary to access it? I want to use rofi to manage windows, so need a list of open windows and their tags
<leon-p> basically.
<leon-p> riverctl should probably display all this information at some point, but currently is doesn't
<leon-p> well, for a list of open windows you'll need foreign-toplevel, not river-status
<leon-p> in the future river-status is supposed to integrate with foreign-toplevel, but we are not quite there yet
<snakedye> Can I write a river-status client in rust?
<leon-p> most likely.
<leon-p> I have seen wayland clients written in rust.
<leon-p> using river-status is just like using any other wayland protocol
<leon-p> maybe take a look at ifreunds waylock. It's written in rust
<snakedye> Nice 😃
<snakedye> Is there any helpful documentation about how to make Wayland clients?
<leon-p> the slow route is reading wayland-book.com by drew devault
<leon-p> the fast route is reading the code of existing clients
<leon-p> in ultra short explanantion: You setup a display and a registry. You give the registry callback function, a listener. the registry will call the listener for every global object. you compare the objects name and if you want it, you bind it. objects you bind that way include seats, outputs, river-status-manager-v1, xdg-shell, etc. Usually, global objects are used to bind scoped objects. With the
<leon-p> river-status-manager-v1 you can bind a river-output-status-v1 for a wl_output. these objects also have listeners
snakedye has quit [Ping timeout: 240 seconds]
<pkill9> is it possible to create a layout that creates two of the single-window modes side-by-side?
<leon-p> why wouldn't it by?
<leon-p> you can position every windows wherever you want
<leon-p> the only limitation is that because of the windows always just being a simple list, complex layouts may just be a bit awkward to use
<leon-p> but other than that, as long as a layout can be expressed as a set of window dimensions, it is possible
<leon-p> or in simpler terms, layouts work like this: the layout generator receives a few parameters from river, and then just outputs new x,y coordinates and widht/height for every window. thats it. no magic.
<leon-p> it is a really simple system. although considering how many times this has been explained, we might need to document it a bit better
<pkill9> ah cool
<pkill9> yea it would be awkward, would need to be able to switch between the two sides without changing the window
<pkill9> then again, that could probably be handled with a script
<pkill9> once info on the workspace can be accessed with river-status
<leon-p> would be awkward even with a script, because river renders all windows in order with the currently focused one at the top, meaning the order would not be as expected
<pkill9> oh ok
<pkill9> maybe a nested instance of cage could be used
<leon-p> or propose a change
<pkill9> would probably be a bit hacky
<leon-p> technically it would make more sense to render views in the order they have been focused in.
<pkill9> yea, dunno whether such a change would be accepted
<leon-p> can't hurt to ask
<pkill9> wouldn't it be a fundamental change in how the windows are managed
<pkill9> yea true
<leon-p> not at all, just a change in the stacking order
<leon-p> considering rendering will have to be redone at some point anyway, now is a good time to make the change
<pkill9> how would it change the stacking order? I'm not sure what would need to be done to have it work how I imagine
<leon-p> currently, the order in which windows are on top of each other is just the normal window list.
<leon-p> the change I talked about would mean that which window is on top of which other window depends on the order they have been focused in
yyp has joined #river
waleee-cl has quit [Quit: Connection closed for inactivity]
yyp has quit [Read error: Connection reset by peer]
yyp has joined #river
yyp has quit [Remote host closed the connection]
leon-p has quit [Quit: leaving]
yyp has joined #river
yyp has quit [Quit: bye!]
<ifreund> that doesn't play very well with multi-seat
<ifreund> not that multi seat is currently supported :D
yyp has joined #river
yyp has quit [Quit: have a great day]
leon-p has joined #river
<pkill9> is it possible to change the disable-touchpad-while-typing behaviour? maybe wiht another env var
<ifreund> pkill9: don't know, does e.g. sway expose something for that?
<pkill9> yea, i have this in my sway config
<pkill9> input * dwt disabled #Disable 'disable-while-typing' for touchpad
<pkill9> i also have this: input * xkb_options "ctrl:nocaps"
<pkill9> xkb options can be specified by env var
<pkill9> so maybe dwt can, but idk
<ifreund> pkill9: I don't think libinput exposes any environment variable config
<ifreund> I saw a hack of a project that should let you do this recently though, let me see if I can get a link
<pkill9> cool
<pkill9> how feasible woudl it be to launch an instance of river inside itself?
<pkill9> the goal would be to have two separate single-window-mode stacks
<ifreund> you can already run river nested inside itself, I do it all the time for testing
<ifreund> there isn't any interoperation between the two instances though
<pkill9> nice
<pkill9> I guess I mean in terms of workflow
<pkill9> actually it wouldn't work
<pkill9> it wouldn't have access to the windows in the main river process
<ifreund> exactly
<pkill9> would river accept changes that allow for what I desire?
<ifreund> I think what you want could potentially be achieved by decoupling river's notion of outputs from physical outputs
<pkill9> basically single-window-mode, separately
<ifreund> this would be quite a large change though, and I'm not sure if I want it
<pkill9> so it would function like emacs frames
<pkill9> yea
<ifreund> certainly not before river is a little farther along and has stuff like damage tracking done
<pkill9> idk if it would be really needed or if I'm overthinking
<pkill9> I think it would be better as a fork of river
<ifreund> perhaps yeah
<pkill9> because I don't like feature creep, and i like river's simplicity
<pkill9> :P
<pkill9> hmm it owuld just be simpler to have a command that selects two buffers to put in a tag
<pkill9> and just destroy that when I no longer want it
<pkill9> might be a bit annoying but oh well
<pkill9> since have to put them on a tag for every combo
<pkill9> alternatively... i could have it remove the window from the tag
<pkill9> yes I think that would wokr
<pkill9> work*
yyp has joined #river
yyp has quit [Read error: Connection reset by peer]
yyp has joined #river
snakedye has joined #river
snakedye has quit [Ping timeout: 240 seconds]
yyp has quit [Quit: have a great day]
gspe has joined #river
daurnimator has quit [Ping timeout: 272 seconds]
waleee-cl has joined #river
daurnimator has joined #river
yyp has joined #river
yyp has quit [Quit: have a great day]
yyp has joined #river
snakedye has joined #river
<snakedye> leon-p thanks for the explanation 😀
<snakedye> Regarding layouts, is it possible to store the output of a layout generator inside river-options? Or maybe have this functionality built in by default.
<snakedye> River layout could also provide that information. I think it would be really helpful for manual tiling.
<pkill9> could it be possible to tag windows with text, and if that tag doesn't exist then it gets created?
<leon-p> snakedye: river just wants a new set of window dimensions/coordinates whenever it starts a layout demand. You could certainly get creative with river-options, but river itself would know nothing about that.
<leon-p> pkill9: So like marks in sway? I have proposed that already, but I believe you could implement that as a foreign-toplevel client. Although I haven't had the time yet to properly try it.
<pkill9> I guess so yea
<snakedye> leon-p It's not really about changing what river takes but what it gives. River could give the previous layout to the layout generator instead of having to manually duplicate that information in river-option.
<leon-p> snakedye: that's unecessary, because with river-layouts, layout generators run continiously and therefore can store that data themselves
<ifreund> ^^^
<snakedye> that's certainly more practical but now I'm not so sure about how to deal with arguments :v
<ifreund> if you want to save state currently, just use the filesystem or something
<leon-p> note though that trying to create some sort of manual tiling layouts, while creatinly possible, will probably be pretty awkward
<ifreund> yeah that too
<leon-p> snakedye: you mean the arguments controlling your layout generator you showed off on reddit? WHy not use river-options for that?
<snakedye> Not just the arguments for layouts but also for the others given river like mod-main-count or the screen height
<leon-p> the first will come through river-options, the second through river-layout
<leon-p> as I said, when river-layout is merged, layout generators are launched once and run continiously.
<snakedye> Are parameters like mod-main-count or mod-main-factor edited through river-option?
<leon-p> yes
<leon-p> `riverctl mod-option -focused-output main_factor 1`
<leon-p> river creates these as default options for each output
<leon-p> but nothing stops you from also using an arbitrary amount of custom options
<ifreund> aside from the amount of RAM you have :P
<snakedye> I assume it would preferable to have a Wayland client to get theses options?
<leon-p> basically we are still dynamicly tiling, but no longer tied to main_amount, main_factor, etc. Use your imagination.
<leon-p> snakedye: a wayland clients will be the only way to communicate layouts to river
<ifreund> (riverctl is a wayland client)
<snakedye> I mean instead of calling `riverctl get-option -focused-output name` have something integrated inside the layout generator but I supposed I'm just over dramatizing the performance hit of running shell command
<leon-p> snakedye: why would you call it via shell?
<leon-p> to reiterate: It is totally impossible to have a layout generator that is not a wayland client itself (unless you have a bridge-thingy, but that would need to be a wayland client as well). So why execute an external binary when you can just do it natively?
<snakedye> The way I imagined it the executable wasn't the wayland client itself, `riverctl layout` was the bridge thingy using the binary I made to generate layout and would communicate it to the compositor. idk if this makes sens.
<leon-p> I think I know what you mean, but no it does not work like that.
<leon-p> the layout generator will have to be it's own wayland client
yyp has quit [Quit: bye!]
<snakedye> I think I'll have to read that wayland book. This layout protocol is more complicated than I anticipated but it'll be a fun experience.
<ifreund> if you want to get started quickly, you can literally just copy paste the contrib layout in C leon-p just linked, it already does all the boilerplate setup for you
<ifreund> Also fwiw, wayland is a lot easier to get started with in C/Zig than rust
<ifreund> hopefully I can get the transaction system wrangled into shape shortly so I can finally merge river-layout...
<snakedye> I just looked into Smithay and it seems like what I need but I'll keep Zig in mind
<leon-p> note that whatever wayland library you are going to use needs a scanner utility to generate code for custom protocols.
<ifreund> snakedye: Smithay is a rust compositor library, you want wayland-rs
<ifreund> they have a scanner, but I don't know how to invoke it manually
<snakedye> I think I'll just switch to Zig then. Seems like less work 😅
<ifreund> this should get you started: https://github.com/ifreund/hello-zig-wayland
<leon-p> speaking og rivertile, I need to redo a few things in its code, so don't merge yet :D
<leon-p> s/og/of/
<ifreund> leon-p: I haven't really looked at rivertile yet, focusing on river itself
<leon-p> ah, then I still have time
gspe has quit [Quit: gspe]