04:13 <upsala> Hi, I'm having some issues with the 'tags' action of rule-add. I was assuming, that 'riverctl rule-add -app-id "steam" 000001000' would let my steam spawn on tag 4. What I don't understand is why 'riverctl list-rules tags' returns '*      steam   1111101000'. I also tried using 32 bits with the same result

04:17 <upsala> Ok small update... 'riverctl rule-add -app-id steam tags 8' gives the wanted result. Is that how it should work? I was reading it completely different.

06:09 <NickH> It takes an integer as argument not a bit map. See the example config that river ships with.

06:10 <NickH> Off topic: I remember some time ago one of the regulars in this channel mentioned a program for displaying pdfs for presentations

06:12 <NickH> My search of the logs has failed... anyone know what I'm talking about?

06:15 <NickH> Hmm, maybe pdfpc

06:36 <ifreund> NickH: pdfpc is indeed what I have used for that in the past

06:37 <NickH> Thanks for confirming. Looks very powerful. Seems to do more than I need.

06:37 <NickH> Looking for a replacement for zathura which for some reason has started messing up the display in presentation mode.

08:27 <ifreund> I am on my way to a music festival and will be offline until Tuesday or so :)

08:29 <novakane> enjoy :)

12:17 <leon-p> have fun!

12:18 <leon-p> I have never really found the extra functionality of pdfpc useful, becuse they would require me looking at my laptop screen, which isn't what you want to do during a presentation

12:18 <leon-p> so I just use presentation mode of evince and it's been fine

12:19 <leon-p> it's easiely the best PDF viewer on linux anyway

12:19 <leon-p> you can hover over links to get previous, it has vim-like nagivation binds by default, etc..

12:38 <NickH> leon-p: I eneded up using evince today. Was chairing a meeting with 10 or so speakers (mix of local and remote) showing their slides and projecting my screen over zoom. Worked well.

12:40 <NickH> Think I sill prefer zathura (when it works) but a working evince is *far* better than a non-working zathura.

13:13 <sewn> Why not use your browser which has a PDF reader

14:14 <leon-p> because the browsers performance is miserable

14:14 <leon-p> and it has no preview on hover for interlinks

14:14 <leon-p> and because it's display options are inferior

17:39 <sewn> for every seat, is there a wl_output assigned to it; or is every wl_output assigned a seat

17:40 <sewn> rather silly question, but I am asking in the context of the river status protocol

17:43 <leon-p> seats and outputs are fully independent

17:44 <leon-p> (if you are talking about wl_seat and wl_output, there are other concepts called seat which behave differently)

17:45 <leon-p> a wl_seat is a set of input devices, a wl_output is usually a physical screen but can also be f.e. headless

17:45 <leon-p> or are you talking about the river-specific feature of output focus?

20:54 <sewn> unsure

21:02 <sewn> I know the status protocol is being deprecated, but will the futrue protocol allow for 'passthrough' messages?

21:03 <sewn> for example, enabling, displaying setting certain settings entirely from riverctl

21:03 <sewn> its handy to have it simply for enabling or disabling a bar, since bar control can get very complicated (net socket? FIFO? whaaat?)

21:10 <sewn> I don't know how other bars do it

22:13 <leon-p> I think riverctl will also go away, we were never happy with how it works anyway

22:14 <leon-p> as for controlling bars, that very much depends on what software you'll be using

22:15 <leon-p> some currently existing bars make use of SIGUSR for toggling visibility

22:15 <leon-p> a socket and a simple IPC protocol is also possible (especially if the bar is built into the WM directly)

22:49 <sewn> leon-p: wait what

22:49 <sewn> riverctl is gone??

22:49 <sewn> well I mean it will be gone

22:49 <sewn> what will replace it then???

22:50 <leon-p> I don't see a need for a replacement

22:50 <sewn> no how will configuration be performed

22:50 <leon-p> via the WM of coursse

22:50 <sewn> keybindings n such

22:50 <leon-p> also the WMs responsibility

22:50 <sewn> leon-p: but you said riverctl will be removed

22:50 <sewn> what is the messenged that's going to tell it

22:50 <sewn> messenger"

22:51 <leon-p> I don't follow?

22:51 <leon-p> ah, I see

22:51 <sewn> leon-p: "the piece of software for controlling river's configuration and keybindings will go away"

22:51 <sewn> who will replace it

22:51 <leon-p> let me explain

22:53 <leon-p> all window management will be outsourced to external programs, basically turning the current layout generators into full window managers. this in turn means all window management configuration is now also fully in the domain of these window managers. this includes the very few appearance options river has. keybinds need to be part of the window management protocol as well for frame perfection, so keybinds will also need to be configured by the WM.

22:53 <leon-p> how the WM chooses to get configuration is irrelevant

22:53 <leon-p> it can have a config file

22:53 <leon-p> or it could have a socket and it's own ctrl CLI tool

22:54 <leon-p> the only thing left that riverctl currently does is input configuration, but there might be a dedicated protocol for that as well

22:57 <sewn> I'm sorry but why all of this

22:57 <sewn> what's the point of river just being some tiny little deck that needs other software to be actually useful

22:57 <leon-p> flexibility

22:57 <sewn> hm

22:57 <sewn> why not split configuration to its own module

22:57 <sewn> instead of everything being only in the WM

22:57 <leon-p> because that would make no sense

22:58 <sewn> why?

22:58 <leon-p> the WM already needs it's own configruation anyway

22:58 <sewn> I see

22:58 <leon-p> and like 90% of rivers configuration is just window management related anyway

22:58 <sewn> so the WM needs its own configuration but what about river

22:58 <leon-p> the very few things you can configure in river afterwards will likely also be done by the WM

22:58 <leon-p> with exceptions

22:59 <leon-p> right now you can use f.e. kanshi to configure outputs, that will most cecrtainly still be the case then

22:59 <leon-p> and inputs will probably also be configurable with a daemon similar to kanshi

23:00 <leon-p> "what's the point of river just being some tiny little deck that needs other software to be actually useful"

23:00 <leon-p> think of it the other way around

23:00 <leon-p> river is a tool to help make other software useful

23:00 <leon-p> both ifreund and I f.e. want to experiment with different window management ideas

23:01 <leon-p> that is a lot simpler in high-level languages like f.e. scheme. river in that case is a solid foundation for whatever high-level window manager we create on top

23:01 <leon-p> other people may want to create other kinds of desktops. river would be a good foundation to them as well

23:02 <leon-p> writing an entire wlroots based wayland server is simple, but also costs lots of time. so with river, people can create their desktops without having to write all of it

23:03 <leon-p> that will make river considerably more useful than what it is right now

23:09 <leon-p> my plan is to write a C library wrapping all the Wayland boilerplate and exposing a simple API which then can be used in whatever scripting language you prefer

23:09 <leon-p> probably won't be done this year though

23:10 <leon-p> also WMs will be able to render custom decoratins for windows, so we can finally have skeumorphic window borders again :)

23:22 <sewn> why make river X

23:22 <sewn> X handles everything except window management and depends on external tools such as a window manager, seem familiar?

23:39 <leon-p> I am aware of how X works, I have written software for X long before I jumped onto Wayland

23:40 <leon-p> the why is explained above

23:40 <leon-p> it's the same reason why we have layout generators instead of hard-coded layouts

23:40 <leon-p> the same reason why any software is configurable at all