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/
ifreund has quit [Ping timeout: 252 seconds]
c7s has quit [Ping timeout: 268 seconds]
n8r has quit [Ping timeout: 260 seconds]
n8r has joined #river
n8r has quit [Quit: WeeChat 3.1]
waleee-cl has quit [Quit: Connection closed for inactivity]
waleee-cl has joined #river
leon-p has joined #river
novakane has joined #river
ifreund has joined #river
maringuu has quit [Read error: Connection reset by peer]
maringuu has joined #river
yyp has joined #river
yyp_ has joined #river
yyp has quit [Ping timeout: 252 seconds]
yyp_ is now known as yyp
<novakane[m]> hmm so I need some help... again, if someone can put me on the right way to implement something like this in zig it would be cool
<novakane[m]> I tried differents thing, like this for exemple https://zigbin.io/24cbdb
<leon-p> you mean the loop? just use a while loop. The rest should be fairly similar, depending on how zig-pixman abstracts it of course
<leon-p> I'll have a more in-depth lool in a moment, I am in a lecture right now :P
<novakane[m]> I tried a while loop too at first like this https://zigbin.io/afba31
<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.
<novakane[m]> yeah that's my problem
<novakane[m]> hmm doesn't really look ideal
<leon-p> you can always ask in #zig, they are pretty helpful
<novakane[m]> yeah I'll try that
<novakane[m]> what if I try to make an array of rects
<leon-p> you are a bit limited by what the function returns
<novakane[m]> right that the pixman part
<novakane[m]> oh there is something like this is the doc https://ziglang.org/documentation/0.7.1/#toc-C-Pointers
<novakane[m]> looks like my problem
<novakane[m]> or maybe not
<ifreund> novakane[m]: that's an error in zig-pixman, the return type should be [*]Box16 not *Box16
<ifreund> though we could also just abstract a bit more and have zig-pixman return a slice
<novakane[m]> oh
<novakane[m]> that's just what they said me in #zig
c7s has joined #river
<novakane[m]> thanks let me try that
<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> go for it :D
<novakane[m]> how do I access x1 now?
<ifreund> rects[0].x1
<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
c7s has quit [Quit: c7s]
<dnkl> leon-p: really? I'll have to try that :D
snakedye has joined #river
novakane has quit [Quit: WeeChat 3.1]
novakane has joined #river
snakedye has quit [Ping timeout: 240 seconds]
<leon-p> ifreund: any idea what could cause this error https://paste.rs/Pm8 ?
<leon-p> It happens when an option is changed and it's event.update.signal is emited
<leon-p> to me it seems like the wl.Signal list is messed up, but I have no idea how that would happen
<novakane[m]> can you use fn foo(arg: ?*bar) void {} in zig?
<novakane[m]> using ?* in function parameters
<leon-p> novakane[m]: yes you can
<novakane[m]> leon-p: thanks
<novakane[m]> well I'm gonna need that in zig-wlroots
<leon-p> just be careful with the ordering "?*" and "*?" are totally different things
<ifreund> leon-p: the config struct gets copied when it is returned from init, breaking the pointers for the listeners
<leon-p> oh. that makes sense
<leon-p> thanks
<ifreund> yeah... eventually zig will be able to make this a compile error
<ifreund> no problem!
<novakane[m]> yeah I want to call a null value so ?*wlr.Box should be good
<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?
<leon-p> go for it.
<novakane[m]> well good luck with this, shell completions is a nightmare :p
novakane has quit [Ping timeout: 250 seconds]
novakane has joined #river
yyp has joined #river
<novakane[m]> I'm not sure if I like working on damage tracking or if I hate it, it changes after every line I write :p
<leon-p> do you do full damage tracking or just the on-off type?
<novakane[m]> full, at least I'm trying
<novakane[m]> That's interesting though, I'm learning a lot about zig, river and all wayland thing
<novakane[m]> but it's hard, for me at least :p
<leon-p> well, you have chosen to do it the hard way, sooo :P
<novakane[m]> hey I'm not here to do things by halves :p
<ifreund> damage tracking is definitely a non trivial project to take on, it would be great if I don't have to do it myself :D
<ifreund> be prepared for a picky review though :P
<novakane[m]> hmm prepared for a messy review though :p
<novakane[m]> be*
mmurd has quit [Ping timeout: 240 seconds]
mmurd has joined #river
<ifreund> novakane[m]: by the way, did you check if libxkbcommon 1.2.1 fixed the crash you were hitting?
<ifreund> actually nvm, 1.2.1 only had one commit and it looks unrelated
Dedguy21 has joined #river
<Dedguy21> Just a question, I'm sure has been asked a zillion times. Why does it take so long for waybar to load upon the  initial launch of River?
<novakane[m]> ifreund: yeah since I switch to void linux I didn't tried it again
<ifreund> Dedguy21: almost certainly a waybar or gtk bug...
<ifreund> it loads instantly for me
<Dedguy21> @novakane yes you suggested yambar, I tired it but still figuring it out.
<ifreund> if you want to investigate you could get a WAYLAND_DEBUG=1 log of waybar
<Dedguy21> When I restart river it loads instantly, ifreund I will do that thanks
<ifreund> novakane[m]: hmm, can't reproduce the crash with libxkbcommon 1.2.1 on void
<novakane[m]> weird, let me try
<novakane[m]> oh yeah nice, thanks
Dedguy21 has quit [Quit: Connection closed]
josip has quit [Remote host closed the connection]
josip has joined #river
Dedguy21 has joined #river
<Dedguy21> Upon the initial start up it hangs a bit at this point
<Dedguy21> 0.0559 → zxdg_output_manager_v1@26.0 get_xdg_output(id=new zxdg_output_v1@24.1, output=wl_output@19.0)
<Dedguy21> That was the slow waybar start issue I just mentioned
<Dedguy21> so it seems it has something to do with xdg portal i'm guessing?
<ifreund> nah, the xdg-desktop-portal is a unrelated, it uses dbus not wayland
<Dedguy21> ok
<ifreund> could you put the full log in a pastebin or something?
<novakane[m]> ifreund: still have it...
<Dedguy21> ok
<Dedguy21> reboot
Dedguy21 has quit [Quit: Connection closed]
<ifreund> novakane[m]: well that's no fun, could you paste your river init script somewhere?
<ifreund> maybe you're using some keycode that I'm not
<ifreund> any luck with a stacktrace?
<novakane[m]> nope I can't get anything else that what I posted, once I go to the null pointer then it's infinite loop and I can't do anything else
kchambers has quit [Quit: WeeChat 3.1]
<ifreund> novakane[m]: just for sanity, does it happen with the example init script?
<novakane[m]> ifreund: hmm looks like it works whith the default init
<novakane[m]> where did i fucked up
<ifreund> novakane[m]: you didn't fuck up, you just found a bug either in river or libxkbcommon
<ifreund> and my money is on libxkbcommon right now
<ifreund> just gotta figure out which part of your config it doing it and see if I can reproduce
<novakane[m]> well glad it's not my fault then :p
<novakane[m]> I'll try to find it too
Dedguy21 has joined #river
<Dedguy21> pastebin: https://pastebin.com/wX7c4By5
<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
<ifreund> this is what I've got it down to so far
<novakane[m]> hmm try removing mod="Mod4"
<ifreund> got it, your loop bounds are wrong, so the last iteration passes "" for the key
<ifreund> which casuse things to crash
<novakane[m]> oh
<novakane[m]> right O..8
<novakane[m]> of course I don't bind 0 to a tags, I was so used to have a tenth on it
<novakane[m]> that's what you get when you try some hacky thing for an azerty keyboard :p
<novakane[m]> nice investigation btw, I can close the issue
<novakane[m]> thanks
<ifreund> novakane[m]: it's an xkbcommon bug :D
Dedguy21 has quit [Quit: Connection closed]
<novakane[m]> ifreund: good thing you put your money on it :p
<novakane[m]> weird it didn't happen before though
<ifreund> not weird, they changed that function significantly in 1.2.0
<ifreund> I wonder if I can fix it, it would be cool to get a commit into libxkbcommon
<novakane[m]> well try your luck
<novakane[m]> you just need to work all night long on it :p
yyp has quit [Quit: now it's safe to turn off your computer]
novakane has quit [Quit: WeeChat 3.1]
<ifreund> yay, I can go to bed now https://github.com/xkbcommon/libxkbcommon/pull/238
snakedye has joined #river