<ifreund>
Mine prints more info and in json, but doesn't free memory or clean up its wayland objects :D
<leon-p>
I guess yours is more robuts, since it stores the toplevels in a list instead of just printing everything, but ngl I am pretty happy with my use of sync :)
<leon-p>
s/robuts/robust/g
<ifreund>
yeah, nice hack :P
<leon-p>
Well, it is mentioned in wayland.xml, so not really a hack :D
<leon-p>
"To mark the end of the initial burst of events, the client can use the wl_display.sync request immediately after calling wl_display.get_registry.
<leon-p>
"
<novakane[m]>
well everybody is too efficient here, I'm gonna try it too then
<novakane[m]>
ifreund: is it zig 0.7..1 too
<novakane[m]>
?
<ifreund>
indeed
<leon-p>
since everything in the message queue is guarenteed to be processed in order, by the time the sync callback is done, all previous requests have been handled and their respective events send. So not a hack, rather a little used neat trick that is just a tiny bit cleaner than a roundtrip
<ifreund>
yeah makes sense
<ifreund>
I've been thinking about extending zig-wayland for client code to optionally get rid of the registry setup boilerplate
<ifreund>
zig should be much more capable of effectivly abstracting over that than C
<ifreund>
the only hard part is dealing with freaking outputs and seats
<leon-p>
what I'd like is a build-option for zig-wayland to not link lib-wayland, because if you don't use its cursor or list stuff you shouldn't need it.
<ifreund>
it doesn't link libwayland automatically
<ifreund>
you choose whether or not to do that in your build.zig
<leon-p>
won't it complain though? Or is zig lazy enough here
<ifreund>
zig should be lazy enough
<leon-p>
nice
<ifreund>
I think we might have a hard dependency on wayland-scanner and wayland.xml though currently
<leon-p>
doesn't it implement its own scanner?
<leon-p>
wayland.xml is fine though, because realistically everyone interested in a wayland-library is going to have that
<ifreund>
I'll make sure that gets fixed in the self hosted compiler, tried to hack it into stage1 but gave up
<leon-p>
stage1 is C++ isnt't it? Can imagine that isn't much fun :D
<ifreund>
luckily andrew's take on how to use C++ keeps things quite close to C, just a few simple templates here and there to avoid void pointers
<ifreund>
what makes it hard to hack on is mostly architectural, zig's changed a lot since the stage1 compiler was started and we've learned a lot about how to do things right
<leon-p>
so its the typical problem of lots of bandaids and no refactoring
<ifreund>
yeah pretty much, which is fine because it'll be thrown out when stage2 is feature complete anyways