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/
dominikh has quit [Ping timeout: 260 seconds]
dominikh has joined #river
dominikh is now known as Guest19851
skuzzymiglet has quit [Remote host closed the connection]
waleee-cl has quit [Quit: Connection closed for inactivity]
leon-p has joined #river
<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
maringuu has quit [Ping timeout: 276 seconds]
maringuu has joined #river
<ifreund> leon-p: I've been planning to make server global for a while but haven't gotten around to it yet
<ifreund> maybe I should do a quick refactoring day before I get deep into damage tracking
Guest19851 is now known as dominikh
lyhokia has joined #river
<novakane[m]> ifreund: si I'm testing std.fmt, is that something like this that you had in mind
<novakane[m]> well as a starting point, I need to adapt it to scanner.zig after
<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
<ifreund> also, you can get rid of the buffer and just write to the writer directly
<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
<novakane[m]> oops you're right, I changed this function so many time that I lost myself
<novakane[m]> hmm how I write to the writer directly?
<ifreund> novakane[m]: https://zigbin.io/843408
waleee-cl has joined #river
<ifreund> oops, should delete `i` as well, it's no longer needed
<novakane[m]> nice, that was my next step to add an enum
lyhokia has quit [Ping timeout: 240 seconds]
<novakane[m]> well it looks good, I can start with scanner.zig now
<ifreund> nice :)
<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?
<ifreund> sjtio: indeed
<ifreund> leon-p: made server global :)
gspe has joined #river
<sjtio> ifreund: thanks
<sjtio> I may be bad at reading wayland protocols, but the layout generator isn't aware of the focused tags right?
<ifreund> sjtio: it is actually, see layout_demand.tags
<ifreund> If you do something cool with this, please let me know so I don't feel tempted to remove it :D
<sjtio> oh I completely missed that! so focused tags are sent but not the focused view? any particular reason for that?
<ifreund> no good one really, we didn't have a use-case (though we didn't really for the tags either tbh)
<ifreund> future multi-seat support would also require sending multiple focused views
<ifreund> I think the best way to add that would be a new argument for the advertise_view event
<sjtio> I was just typing that out yeah
<sjtio> for context, I wondering if I could implement a 'sliding' layout similar to Cardboard or PaperWM (https://github.com/cardboardwm/cardboard)
<ifreund> hmm, yeah with that `is_focused` arg on advertie_view you totally could
<ifreund> though I imagine it wouldn't be as nice as Cardboard, they probably allow scrolling the views with the scroll wheel or something
<sjtio> yeah there wouldn't be anything like that, or any pretty animations but I don't think that matters for me
<sjtio> Is layout_demand sent when a view becomes focused?
<ifreund> sjtio: not, not currently
<ifreund> s/not/no/
<sjtio> alright, thanks :)
<novakane[m]> ifreund: is that what you want? quick exemple https://zigbin.io/1545d0
<ifreund> novakane[m]: hmm, is the [s] really needed? I don't think so
<ifreund> also but yeah that's the idea, we can also use the original variable name instead of title_case
<ifreund> we can also use the new std.zig.fmtId() or std.zig.formatId() to replace the current printIdentifier() / isValidIdentifier()
<ifreund> basically just do what makes sense to you to clean things up with the new tools the std has
<novakane[m]> hmm yeah without the [s] I had some problem before but I think it wasn't related so I could remove it
<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
skuzzymiglet has joined #river
waleee-cl has quit [Quit: Connection closed for inactivity]
<leon-p> ifreund: nice
<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.
<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
<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
<sjtio> I suppose people could use the focused view to have some horribly behaving layouts
<sjtio> does a layout generator have to reply to every layout demand or can they 'commit' no changes
<leon-p> I actually considered those exact examples, but came to the conclusion that they are not particularly partical
<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
<leon-p> sjtio: ^
waleee-cl has joined #river
<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
<ifreund> We certainly don't need that complexity currently, and I find it hard to justify adding it for this use-case
<ifreund> if you really want paperwm-style window management, I'd suggest using cardboard :P
<sjtio> yeah that all makes a lot of sense, I suppose I'll keep to 'traditional' tiling for now
<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
<ifreund> I'm not sure if the commands for manipulating the stack we currently expose are flexible enough for that though
<sjtio> yeah, it would be nice to be able to move a view to the top/bottom of the stack
<sjtio> I'll give paper wm tiling in river a go sometime and let you know how it goes!
<sjtio> I'm still not convinced it's not a gimmick anyway!
<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
snakedye has joined #river
<snakedye> leon-p: information about the focused view could be provided by the status protocol.
<ifreund> snakedye: how would that fix any of the problems described above?
<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.
<leon-p> snakedye: all river internal parameters layouts can depend on should cause a new layout demand when changed.
<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
<leon-p> also please let's not get into this again. we have had this exact discussion at least three or four times already
gspe has quit [Quit: gspe]
gspe has joined #river
hspak has quit [Quit: Ping timeout (120 seconds)]
hspak has joined #river
snakedye has quit [Remote host closed the connection]
snakedye71 has joined #river
snakedye71 has quit [Client Quit]
snakedye has joined #river
gspe has quit [Quit: gspe]
<snakedye> leon-p I disagree that the a new layout should absolutely be triggered to make a layout parameter (obtained through whatever means) useful.
<snakedye> There are usecases where you only need that information when a certain condition is met.
<snakedye> For example, if a view is added or removed. In this case, river would already send a layout request.
<snakedye> The layout generator can then make something with that parameter taken into account.
<snakedye> As long as the layout depends on that parameter and the parameter changes, it will inevitably have an effect on the layout.
<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).
<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 😅).
<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.
<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.
snakedye has quit [Ping timeout: 240 seconds]
leon-p has quit [Quit: Lost terminal]