<novakane[m]>
but of course rects[i] isn't possible
<leon-p>
your first code snippet using for(rects)|rect| will not work because rects is a pointer to pixman.Box32, not a slice
<novakane[m]>
I forget to remove the rect += 1 at the end in the second snippet exemple, don't mind it
<leon-p>
also you are incrementing |rect|, but it is not persistent between loop runs
yyp has quit [Quit: now it's safe to turn off your computer]
novakane has quit [Quit: WeeChat 3.1]
novakane has joined #river
<leon-p>
your second snippet looks better
<leon-p>
but you really should initialize nrects to 0 when you don't know if the C code will actually write anything to it
<novakane[m]>
yeah my second snippets was first solution, I just tried the other because I couldn't make the it works tbh
<leon-p>
yeah, I see the problem. pixman gives you a pointer to at least one element, but zig sees it as a pointer to exactly one element. Not sure what to do here tbh, haven't done much with the C interop yet.
<ifreund>
ugh, I think It probably won't compile, forgot to make the extern functions return [*] pointers
<novakane[m]>
oops
<leon-p>
will that pixman function always return at least one rectangle? I am not familiar with pixman, but my intuition is that if a function can return a variable amount of structs, it can also return none.
<ifreund>
also a good point :D
<ifreund>
though I don't think that requires any special casing here
<leon-p>
no idea. if it is a well-behaving function it will set n_rects to 0, but if it isn't it may just return NULL and not touch n_rects.
<ifreund>
aaah i forget how macro heavy pixman's soruce is
<ifreund>
the definition is PREFIX (_rectangles) (region_type_t *region,
<ifreund>
and the function body is also pretty much just macros
<leon-p>
of course it is
<ifreund>
ok, it never returns 0 or null
<leon-p>
wait, pixman is partly written in assembly? They really are serious about speed...
<ifreund>
yeah there's a reason people use it
<ifreund>
that doesn't mean I don't get to complain though :D
<leon-p>
:D
<novakane[m]>
and here I am making you rewrite pixman.zig everyday :p
<ifreund>
nah this is good, I never actually tested any of it, just wrote it in a couple hours back in september or something
<leon-p>
I think I might switch to pixman from cairo as my go-to drawing library then. Not depending on glib is a plus and for the simple things I do I can do the vector math by hand anyway.
<ifreund>
pixman is the backend for cario if you weren't aware
<novakane[m]>
and then I need to update PointerConstraint everytime :p
<leon-p>
yeah I know, but all it does AFAIK is hiding it behind a vector abstraction and providing a bunch of buffer conversion functions as well as helper functions to get straight from an image file to a buffer.
<leon-p>
and I'd rather do that by hand if it helps getting rid of a few dependencies
<ifreund>
leon-p: you could probalby check out fuzzel's source for inspiration, cario is optional there now
<leon-p>
ifreund: nice, I'll check that out
<ifreund>
looks like I need to bump the void package as well..
<novakane[m]>
ifreund: ah of course, ty
<novakane[m]>
I think pixman is starting to messed up my brain :p
<ifreund>
that doesn't sound good :D
<novakane[m]>
well I'm just dreaming of rect and box all night now :p
<leon-p>
dnkl: you might want to sanity check the corner roundness option in fuzzel. You can end up with funky patters if you put in to high numbers :D
<leon-p>
love how there is always a good proposal for any slight annoyance in the language :D
<novakane[m]>
gonna make a small PR for zig-wlroots
<novakane[m]>
ifreund: you maintain it too.
<novakane[m]>
?*
<ifreund>
yes
<leon-p>
hmm, configuration via options means we can not send the user any feedback via riverctl. To see what went wrong they have to get the river logs.
<ifreund>
I think we might want to stick to the upcomming river-config protocol for most options
<leon-p>
what are the advantages of that?
<ifreund>
we can send nice feedback via riverctl
<ifreund>
we also don't have to make everything able to be overriden per-output/silently ignore when the user tries to do that
<leon-p>
that would mean having the config fragmented between river-options and river-conntrol
<ifreund>
we could also add special casing to validate some options in riverctl
<ifreund>
seems ugly though
<leon-p>
that would mean we'd do it the same way as mutter, which I have mentioned yesterday
<ifreund>
well, we wouldn't crash on invalid values, just ignore them
<ifreund>
but yeah I don't like that approach
<ifreund>
we could also add an option type for colors
<leon-p>
all it would gain us is error messages in riverctl. we can already handle wrong input just fine by ignoring it
<leon-p>
can't we just do something with callbacks?
<ifreund>
like add an error callback to the protocol?
<ifreund>
probably
<leon-p>
i was actually more thinking about an add-on protocol so we don't have to pollute river-options itself
<leon-p>
or maybe just an event
<leon-p>
if an option has been set to a wrong value, river checks if the client has bound river-user-feedback-manager and if it has it sends an event with an error message
<leon-p>
or something like that
kchambers has joined #river
novakane has quit [Ping timeout: 245 seconds]
novakane has joined #river
novakane has quit [Quit: WeeChat 3.1]
novakane has joined #river
<skuzzymiglet>
so I'm thinking about completion generation. it seems the current architechture isn't very declarative - descriptions are comments not data, and options are matched by commands instead of being declared. all of which makes it hard to automate
<leon-p>
you mean command completion? I don't think there is any way around specifying the completion tree by hand. What you can do however is take that tree and automatically convert it into completion functions for all the different shells
<leon-p>
you could probably do it in build.zig embedding a json file with the tree, considering zig an easiely parse those
<skuzzymiglet>
should I create an issue for discussion?
<Dedguy21>
also I noticed if I run Chrome (ya don't kill me) it seems to bring waybar up with it simultaneously no hanging.
<ifreund>
that sounds pretty funky
<Dedguy21>
right?>
<leon-p>
hmm, I have something similar where sometimes randomly on sway some gtk programs take about 5 to 10 seconds to start. If I start another one during that time the other one immediately catches itself and starts up as well.
<ifreund>
that definitely sounds like the same bug
<leon-p>
although I always thought it was about them being gnome apps who have some servery things going on
<Dedguy21>
anyway it hangs at line 57 in the pastebin if that helps
<Dedguy21>
and ya might be the same bug, I'll test that by getting rid of the sys bar
<Dedguy21>
sys tray module i mean, I don't think there's anything else gtk related on my waybar config
<ifreund>
waybar uses gtk regardless of what's in your config
<Dedguy21>
ah ok
<ifreund>
novakane[m]: I can reproduce with your config by the way, trying to narrow it down now
<leon-p>
well, you guys have fun. I need to catch up on some sleep now. bye
leon-p has quit [Quit: leaving]
<novakane[m]>
ifreund: well I found it
<ifreund>
oh?
<novakane[m]>
mod="Mod4" # Logo key
<novakane[m]>
the comment
<ifreund>
oh really?
<ifreund>
what the fuck is wrong with bash
<novakane[m]>
yeah I forgot there is some weird things like this with comment :/
<novakane[m]>
we could have debug river and libxkbcommon for so long
<ifreund>
novakane[m]: you sure it's that comment? removing it doesn't fix things for me
<novakane[m]>
really? damn
<novakane[m]>
wait I tried 3 times with and without and it was that
<novakane[m]>
and now I still have it with the comment removed