11:56 <Moulberry> Does anyone have a patch for smart borders? There doesn't appear to be an option

11:59 <novakane> Moulberry: there is not, it's a bit hacky to make currently

11:59 <Moulberry> yep I remember making it 6 months ago it was very cursed

12:00 <Moulberry> iirc the problem was that rivertile doesn't know the total number of views in it?

12:01 <Moulberry> oh perhaps that is not the case any more

12:03 <novakane> rivertile does know the number of view that what I used for smart gaps in rivercarro, but rivertile doesn't know about the borders gaps, so it would need to be set in the layout generator, and then use river-control-protocol to change the size

12:05 <novakane> the problem is that everytime you change the size it send a layout_demand event, but you need to only have one if there is only one view, if there you go from one view to multiple view but only the first time

12:16 <Moulberry> hm yeah it was that LayoutDemand.zig didn't have the total number of views

12:21 <Moulberry> is there a problem with setting the border_width to 0 if `x == 0 and y == 0 and width == output.usable_box.width and height == output.usable_box.height;` in pushViewDimensions?

12:22 <Moulberry> seems to function... but is hacky as you said

12:31 <novakane> that on river side not rivertile?

12:32 <novakane> s/that/that's/

12:35 <Moulberry> oh you can just check if `self.view_boxen.len == 1`... smart borders seems very easy

12:35 <Moulberry> and... yes, its on river's side, but I never said it had to be done by rivertile

12:45 <novakane> for a river fork sure, but it would need to be on a layout generator to have a good design

12:46 <Moulberry> theres other changes I need to make to river anyways, but yeah I see your point

15:21 <novakane> btw ifreund for the explicit zig-wayland PR I'll probably let it like that till you have time for a review, no rush just to let you know

15:21 <ifreund> novakane: what's the state right now? Is it working?

15:22 <novakane> yeah it works but maybe not exactly as wanted

15:22 <novakane> a client could don't use scanner.interface() in its build.zig and nothing would be wrong

15:23 <novakane> s/don't/not/

15:40 <ifreund> I don't unterstand, what does calling scanner.interface() with your PR do then?

16:05 <novakane> ifreund: well you set a version in it and then the scanner only generate the event/request for < version

16:07 <novakane> but yeah it doesn't enforce to have it in your build.zig for all global interface, I couldn't make something that would do that yet

16:11 <ifreund> I'll try to take a look sometime soon, got a lot of stuff I'm supposed to be doing right now

16:12 <ifreund> (e.g. that monthly status update I said I'd write which is now 3 days late :D)

16:14 <novakane> lol no worries, fill my rss reader first :P

16:15 <novakane> but getting a list of global interface needed for a project and pass that around the scanner is way more annoying than expected ^^

21:50 <leon-p> hmm... somehow a client that does not even has a mapped toplevel yet can bring river up to 50% usage on my laptop

21:52 <leon-p> yep, it somehow floods river with requests

21:52 <ifreund> what requests?

21:53 <leon-p> sync

21:53 <leon-p> so probably a client bug?

21:53 <ifreund> yup

21:53 <ifreund> ideally we would rate limit/kill clients that seem to be buggy, but I don't know of any wayland compositor that actually does that

21:55 <leon-p> it's a gtk thing, so thats a bit weird since I'd assume gtk takes care of the Wayland stuff, but apparently it allows enough control for application devs to still screw things up

21:57 <leon-p> I think it's a bit hard to rate limit or kill clients, because you'd need pretty good heuristics to not kill fine clients that just happen to send a lot of requests (like high-fps video players or games).