06:14 <leon-p> i wonder if we should perhaps make root or server global. the amount of pointer hopping we do in some places to get there is a bit rediculous

08:59 <ifreund> leon-p: I've been planning to make server global for a while but haven't gotten around to it yet

08:59 <ifreund> maybe I should do a quick refactoring day before I get deep into damage tracking

10:39 <novakane[m]> ifreund: si I'm testing std.fmt, is that something like this that you had in mind

10:39 <novakane[m]> https://zigbin.io/f12e36

10:40 <novakane[m]> well as a starting point, I need to adapt it to scanner.zig after

10:43 <ifreund> yep, it looks like you're going in the right direction, I think your function turns a snake_case string into a camelCase string so it should probably be called camelCase not snakeCase

10:43 <ifreund> also, you can get rid of the buffer and just write to the writer directly

10:44 <ifreund> in protocol xml everything is snake_case by convention, so we just need two formatter functions to turn snake_case into camelCase and TitleCase

10:45 <novakane[m]> oops you're right, I changed this function so many time that I lost myself

10:48 <novakane[m]> hmm how I write to the writer directly?

10:51 <ifreund> novakane[m]: https://zigbin.io/843408

10:51 <ifreund> oops, should delete `i` as well, it's no longer needed

10:52 <novakane[m]> nice, that was my next step to add an enum

10:55 <novakane[m]> well it looks good, I can start with scanner.zig now

11:04 <ifreund> nice :)

13:11 <sjtio> sorry for being lazy and not checking myself, but can a layout manager give dimensions/position for a view that results in it being placed (partly) offscreen?

13:15 <ifreund> sjtio: indeed

13:16 <ifreund> leon-p: made server global :)

13:19 <sjtio> ifreund: thanks

13:19 <sjtio> I may be bad at reading wayland protocols, but the layout generator isn't aware of the focused tags right?

13:20 <ifreund> sjtio: it is actually, see layout_demand.tags

13:20 <ifreund> If you do something cool with this, please let me know so I don't feel tempted to remove it :D

13:22 <sjtio> oh I completely missed that! so focused tags are sent but not the focused view? any particular reason for that?

13:27 <ifreund> no good one really, we didn't have a use-case (though we didn't really for the tags either tbh)

13:27 <ifreund> future multi-seat support would also require sending multiple focused views

13:30 <ifreund> I think the best way to add that would be a new argument for the advertise_view event

13:30 <sjtio> I was just typing that out yeah

13:31 <sjtio> for context, I wondering if I could implement a 'sliding' layout similar to Cardboard or PaperWM (https://github.com/cardboardwm/cardboard)

13:34 <ifreund> hmm, yeah with that `is_focused` arg on advertie_view you totally could

13:35 <ifreund> though I imagine it wouldn't be as nice as Cardboard, they probably allow scrolling the views with the scroll wheel or something

13:36 <sjtio> yeah there wouldn't be anything like that, or any pretty animations but I don't think that matters for me

13:49 <sjtio> Is layout_demand sent when a view becomes focused?

13:54 <ifreund> sjtio: not, not currently

13:54 <ifreund> s/not/no/

13:57 <sjtio> alright, thanks :)

14:13 <novakane[m]> ifreund: is that what you want? quick exemple https://zigbin.io/1545d0

14:20 <ifreund> novakane[m]: hmm, is the [s] really needed? I don't think so

14:21 <ifreund> also but yeah that's the idea, we can also use the original variable name instead of title_case

14:23 <ifreund> we can also use the new std.zig.fmtId() or std.zig.formatId() to replace the current printIdentifier() / isValidIdentifier()

14:24 <ifreund> basically just do what makes sense to you to clean things up with the new tools the std has

14:26 <novakane[m]> hmm yeah without the [s] I had some problem before but I think it wasn't related so I could remove it

14:28 <novakane[m]> alright I do that and once I finish we will have time to see if it's good before zig 0.8.0 anyway

16:31 <leon-p> ifreund: nice

16:32 <leon-p> sjtio: the reason the layout generator is not aware of the focused view is because when I designed the protocol I really did not like the idea of layouts depending on that. And I don't think I have changed my mind on that.

16:34 <leon-p> also it would mean sending a layout demand for every focus event, which is effectively just wasting cycles in the majority of cases

17:04 <sjtio> leon-p: I see, the only use cases I can think of off the top of my head is PaperWM-like tiling (still not sure if it's a gimmick or actually helpful) or growing views when focusing them

17:04 <sjtio> I suppose people could use the focused view to have some horribly behaving layouts

17:05 <sjtio> does a layout generator have to reply to every layout demand or can they 'commit' no changes

17:18 <leon-p> I actually considered those exact examples, but came to the conclusion that they are not particularly partical

17:20 <leon-p> the layout generator can choose not to reply, in which case the layout demand will time out and the output will enter floating mode. however in that case the layout generator should /not/ commit, because committing without pushing the right amount of view dimensions is a protocol error

17:20 <leon-p> sjtio: ^

17:20 <ifreund> sjtio: right now they have to reply to every layout demand with a full layout. Technically we could add a way to "commit" no changes, but the nt he client would need to keep track of the current state in order to know if anything has changed or not

17:20 <ifreund> We certainly don't need that complexity currently, and I find it hard to justify adding it for this use-case

17:21 <ifreund> if you really want paperwm-style window management, I'd suggest using cardboard :P

17:25 <sjtio> yeah that all makes a lot of sense, I suppose I'll keep to 'traditional' tiling for now

17:28 <ifreund> the "proper" way to do paperwm style tiling in river would be to making foucusing the next/prev view also move that view to the top of the stack

17:29 <ifreund> I'm not sure if the commands for manipulating the stack we currently expose are flexible enough for that though

17:29 <sjtio> yeah, it would be nice to be able to move a view to the top/bottom of the stack

17:30 <sjtio> I'll give paper wm tiling in river a go sometime and let you know how it goes!

17:31 <sjtio> I'm still not convinced it's not a gimmick anyway!

17:37 <ifreund> Please do, I'm all for making river flexible enough to fit people's use-cases as long as it they stay within my tolerance for complexity

17:45 <snakedye> leon-p: information about the focused view could be provided by the status protocol.

17:45 <ifreund> snakedye: how would that fix any of the problems described above?

17:49 <snakedye> leon didn't wanted focus changes to trigger a layout event. it solves that. if one knows the index of the focused window in the stack, he could zoom it but riverctl doesn't provide a way to zoom a view at an index.

18:47 <leon-p> snakedye: all river internal parameters layouts can depend on should cause a new layout demand when changed.

18:48 <leon-p> so while layout generators can get the focused view via river-status, it is effectively useless since they can do nothing about it changing

18:48 <leon-p> also please let's not get into this again. we have had this exact discussion at least three or four times already

22:04 <snakedye> leon-p I disagree that the a new layout should absolutely be triggered to make a layout parameter (obtained through whatever means) useful.

22:04 <snakedye> There are usecases where you only need that information when a certain condition is met.

22:04 <snakedye> For example, if a view is added or removed. In this case, river would already send a layout request.

22:04 <snakedye> The layout generator can then make something with that parameter taken into account.

22:04 <snakedye> As long as the layout depends on that parameter and the parameter changes, it will inevitably have an effect on the layout.

22:04 <snakedye> You could also use layout values to trigger a layout event if it's a necessity (I don't think it is most of the time).

22:04 <snakedye> The last time we had this discussion I proposed using river-status but I didn't have any response (that might actually be a hint 😅).

22:04 <snakedye> To my defense I don't think I said the same stuff each time and I tried to find a common ground. If you really don't want to talk about this again just ignore this and I'll take the hint.

22:28 <leon-p> snakedye: I think we just fundamentally disagree on what layouts are supposed to be. And I have stated all my points already, so let's leave it at this.