00:18 <sokan> hey! I'm using bspwm for quite some time and consider giving wayland a go, for security reasons. I read that river is bspwm inspired, so the question is, how easy or hard will the migration and getting accustomed to river be? I expect differnces but it'd be nice to know what to expect :)

01:55 <NickH> sokan: I'm not sure if there are any former bspwm users here.

01:56 <NickH> I suggest just reading the wiki and giving it a try. If you have questions, check the man pages and/or ask here.

05:11 <RZ_MJ[m]> leon-p: Tag implementation will get moved to layout generators? That is an awesome info. I once considered making my own window manager (and decided I'm way to dumb for it). I was thinking through how I would make a workspace/tag system too. I too thought about string tags. My idea was that if the output string and the window string would match or one of them was a substring of the other (either way) the window would be shown. If none was a

05:11 <RZ_MJ[m]> substring of the other, it would be hidden.

05:11 <RZ_MJ[m]> The consequences would be a) windows could be made sticky by having an empty string b) combining tags would mean concatenating them c) a window with the combined tag 'Project1Project2' (11000 in binary tags) would not show up on the combined output tag 'Project2Randomstuff' (01001 in binary tags), which I consider to be a good thing since it avoids crammed layouts in complexely tagged situations.

08:49 <tiosgz> leon-p: can you update shell completions in #852?

09:25 <ifreund> RZ_MJ[m]: yep, moving the implementation of tags out of the compositor process is a long term goal

09:26 <ifreund> there are still some unanswered questions to solve though, for example how bars should work

09:26 <ifreund> I'll probably start exploring in that direction after the 0.3.0 release

09:35 <RZ_MJ[m]> My uneducated guess is the layout generator would not just give river a list of window positions, but also a list of information units to pass on to the bar. Those information units could be tags (each with a name, focus boolean, etc.), could be the current layout name, things like that. (Maybe this is obvious: I barely know anything about zig or wayland protocols).

09:39 <ifreund> RZ_MJ[m]: that kind of approach is what the proposed ext-workspace protocol does. I personally think it introduces too much accidental complexity trying (and probably failing) to abstract over all possible window management approaches

09:40 <ifreund> The simplest approach technically would be to either put the bar inside the layout generator/window mananger or have the layout generator/window mananger communicate with existing status bars directly over some kind of custom protocol

13:39 <leon-p> Just added the completions

13:39 <leon-p> made me think that perhaps we should update how we do shell completions

13:40 <leon-p> some modern CLI tools do their own completion using a non-documented `complete` command

13:40 <leon-p> maybe that would be more maintainable for us as well

13:45 <ifreund> I don't have very strong opinions about how the completions should work. I worry that a more complex system to make keeping them up to date/in sync easier might be more trouble than it's worth at this stage

13:46 <ifreund> I'd be happy for someone to find a good solution there though and explain to me how much better it is :)

13:48 <leon-p> well, frotunately completion is only annoying when we add a new command, so maybe every other month :D

13:54 <ifreund> yeah, I quite like how little I have to think about completion when not adding new commands

16:33 <leon-p> then I better propose the unique ID related commands carefully...

19:11 <kyby64> Hi.I want to map KP_1(KP_END),KP_2(KP_DOWN),... in river

19:11 <kyby64> KP_1 and KP_2 work as intended

19:11 <kyby64> riverctl map normal Super KP_1 set-focused-tags 1

19:11 <kyby64> riverctl map normal Super KP_2 set-focused-tags 2

19:11 <kyby64> but KP_3 and others act weird.for example this map just show tags1 and tags2 together

19:11 <kyby64> riverctl map normal Super KP_3 set-focused-tags 3

19:12 <kyby64> and this shows tags1 and tags3 together

19:12 <kyby64> sorry I don't know how to explain that correctly just imagine it show this two *workspaces* together

19:12 <kyby64> riverctl map normal Super KP_5 set-focused-tags 5

19:12 <kyby64> and yes I know there is no workspace in river

19:13 <kyby64> is there anyway to map KP_3 and other keypad keys? or something is wrong with my setup?

19:15 <leon-p> kyby64: this is expected behaviour

19:15 <leon-p> there is no tag 1 or tag 2

19:15 <RZ_MJ[m]> kyby64: https://github.com/riverwm/river/wiki/How-tags-work

19:15 <leon-p> in reality, tags are just a bitfield

19:16 <leon-p> the integer 3 equals the binary 000011, which are the tags bound to super+1 and super+2 in the default config

19:16 <leon-p> the tag bound to super+3 would be 000100, which is 4

19:20 <kyby64> so how I can tell river to just show the windows in tag 3.sorry I'm just trying to understand the concept of tags.I'm familiar with workspaces

19:20 <leon-p> by converting the binary representation to integer

19:22 <leon-p> take a look at the default config, it makes use of bitshift to make this more ergonomic