05:46 <Guest35> Is there a way to make a keybinding to switch to the next/previous tag? This should be easy from the code side (simple bit shift), but I don't see a way to do it with riverctl.

06:09 <dagle> Well, it's easy if the mask is 00100, then it would be come 01000 but what if the mask is 00110? Should it be 01010 or 01100?

06:09 <dagle> become*

06:13 <Guest35> I'll take either one! Presumably the latter, though. I believe there is a dwm patch along those lines.

06:14 <Guest35> That would be the default behavior of a bit shift

07:24 <ext0l> always nice when i go to report a bug, then i find that it was reported and fixed a few days ago :D

07:24 <ext0l> (https://github.com/ifreund/river/issues/382 in my case)

08:08 <ifreund> dagle: looks like Guest35 is gone, but river already has a focus-previous-tags command for future reference

08:08 <ifreund> ext0l: almost a month ago really :P Have you gone that long without restarting river?

09:24 <leon-p> we should probably have a fullscreen filter as well I think (I found that when I open a video in mpv, I always want it fullscreen). Although it probably makes more sense to design the next river-control version to allow outsourcing filters to external clients...

11:40 <bfiedler> Can I match window titles in float-filter-add somehow? The Firefox sharing indicator is driving me up the wall

11:54 <ifreund> bfiedler: nope, not currently

11:55 <ifreund> we really need more flexible matching rules

11:57 <bfiedler> ifreund: Do you have grand plans for a refactoring or would this be a good thing for me to look at?

11:59 <ifreund> bfiedler: it's not clear to me what the "perfect" design for flexible filters looks like, so I'd hesitate to merge anything that adds too much complexity as we'll probably end up replacing it with something else in the future

12:00 <ifreund> I have some long term ideas of how a general solution could look, but adding support for matching on window title in the short term probably wouldn't be a bad idea

12:01 <bfiedler> Sounds good, window titles would already help a lot I think

12:01 <ifreund> if you want to avoid wasted work, feel free to open an issue first to get feedback on the user-facing API you want to expose before starting on the implementation

12:02 <bfiedler> There's this one already: https://github.com/ifreund/river/issues/289 I'll write a comment there

12:03 <ifreund> cool

13:38 <ino> hi guys! how are you?

15:13 <ino> what are you guys thoughts about dwl? I recently found it on github and it is a dwm clone for wayland. :)

15:18 <leon-p> ino: that question belongs into #river-offtopic

16:50 <ext0l> ifreund: i restart river every so often, but i don't update my system *that* much

18:06 <schmo> Hey, Guest35 decided to actually set up an irc client. I'm not seeing a focus-previous-tags option in the riverctl manpage. How do I use that command to shift right or left?

18:09 <leon-p> schmo: that is not built into river. You can use an external program for that. A few days ago I uploaded a python script to do that, but I can't find it anymore, sorry

18:10 <leon-p> the focus-previous-tags command simply makes river focus the tag set that was active before the current one

18:14 <schmo> Ah ok. Thanks.

18:18 <leon-p> schmo: here is the relevant discussion (irc logs): https://libera.irclog.whitequark.org/river/2021-08-14#

18:18 <leon-p> starting at 10:43

18:19 <leon-p> note that the pywayland setup is a bit involved, please see the PR that adds a python layout for details

18:20 <schmo> ok, thanks.

18:21 <schmo> How involved would it be to add something like get-tagmask to riverctl?

18:23 <leon-p> schmo: it's not a question of how complicated it is, but rather if there is a good use case. River does not implement features for the sake of having features.

18:24 <leon-p> and if your use-case is "shell script", then I can stop you already: all river scripting is supposed to happen over wayland

18:31 <schmo> so river can be scripted and controlled through libwayland.

18:32 <leon-p> schmo: through all wayland implementations, not just libwayland. Howeveer the necessary protocol extensions need to be created first :P

18:32 <leon-p> that kind of scripting is better than just some shell script like on X, because you are not /overriding/ window management, you are /integrating/ into it

18:33 <schmo> lol, but it sounds like the average user is not really expected to script river very much?

18:37 <leon-p> schmo: the average user uses GNOME. river already targets a special breed of person, the extra step to writing wayland client isn't that far IMO

18:37 <leon-p> but the hope is that eventually there will be an "ecosystem" (stupid word, but whatever) of user created scripts

18:40 <schmo> Ok, fair. This is definitely a rabbit hole in a rabbit hole (perhaps in another rabbit hole). Seems similar to suckless's way of doing things, with patches and all.

18:41 <leon-p> I'd argue river is several steps above suckless in that it is not just a barely functional proof of concept and user code is not necessarily needed

18:42 <leon-p> also rivers way of having user code is a lot cleaner

18:52 <bfiedler> Is there a "window title changed" event? Or what I'm rather asking is if we want to float based on window titles, do we want to handle title change events

18:52 <schmo> lol how is suckless a barely functional proof of concept?

18:53 <leon-p> schmo: self-imposed artificial limitiation such as "window manager in under 2000 LOC" don't exactly produce quality software. Also configuring via editing source code and recompiling is just sad.

18:55 <leon-p> bfiedler: yes there is using river-seat-status, but the way you get information about views will definitely change in the future

18:57 <leon-p> and patches are an extremely poor way of collecting user code: it leaves users with a bunch of half-working features that don't integrate into one another. And too keep compatibility with other patches (which is a lost cause in the first place, but many people try) you can't actually do all that much: If you change the code too much, other patches won't apply.

18:57 <schmo> I agree with you on the 2000 LOC, that part is stupid. They don't put comments anywhere which is annoying. That being said, suckless software has always worked perfectly for me and I have looked through the code, it's well written.

18:58 <schmo> Patching can get messy, but I have managed to get dwm working basically how I like it.

18:58 <schmo> I agree it can be yucky

19:00 <schmo> so user-made scripts for river always work with each other? They can't conflict?

19:00 <schmo> wayland scripts, that is

19:02 <leon-p> if the protocol is well designed, no, they can't conflict. Take the layout generators for example: It's literally impossible for multiple layout generators to "fight" over "layout supremacy". And since they are just basic Wayland client, you can also use all other protocol extensions supported by river without issue.

19:02 <leon-p> the trick is to strongly limit the way clients can control the server

19:07 <schmo> Why did you decide to try and implement a tag shift with a python script instead of building it into riverctl? was it easier that way, or was it decided not to implement that feature into riverctl for some reason?

19:08 <leon-p> schmo: because I was not feeling like adding a new feature to river, especially since it is already possible to implement it with a script.

19:09 <leon-p> the helper clients shipped with river are not supposed to be fully features. Think of them more as reference implementations.

19:09 <leon-p> *featured

19:10 <schmo> But it sounds like if someone made a pull request that put it in riverctl, it would get merged (assuming it worked)?

19:11 <leon-p> not necessarily. f.e. someone offered to add monocle mode to rivertile and that was not accepted.

19:17 <schmo> Is there a list of user scripts somewhere? That seems like a key part if you want an "ecosystem"

19:18 <leon-p> we have a wiki page with community layouts. one for scripts would make sense too, but there simply aren't that many yet, considering river did not even have a release yet

19:21 <bfiedler> ohhh yes it just did the thing I wanted it to do

19:21 <bfiedler> finally the firefox sharing indicator floats properly

19:42 <leon-p> anyway, I am off for the night

19:58 <Nulo> bfiedler, "it" what? It annoys me too

19:58 <Nulo> I would like to implement a river configuration thing in Lua

20:02 <Nulo> Answering to some things leon-p said: I feel like, with the flexibility that river provides, it is possible to make an intuitive river distro with GUI config, etc.

20:07 <bfiedler> Nulo: "it" in this case was river :) whenever I (have to) use $conferencing_software, the media share indicator on FF doesn't float (since FF doesn't float), so I hacked^Wimplemented support for floating windows based on titles

20:07 <Nulo> Ah, ok

20:24 <ifreund> bfiedler: nice! That's been annoying me too for a long time but I've been too lazy to fix it and silently hoping that firefox would start behaving better :D

20:24 <ifreund> I'll take a look at your PR after I shower and make dinner, just got home

22:21 <ifreund> not actually going to get any reviews done today, it got late

22:22 <ifreund> I owe all of y'alls PRs some attention

23:48 <Nulo> Comfy, not gonna lie https://nulo.in/temp/20210831_20h47m14s_grim.png