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/
hollmax[m] has quit [Ping timeout: 246 seconds]
hollmax[m] has joined #river
edrex has quit [Ping timeout: 246 seconds]
edrex has joined #river
Edd[m]2 has quit [Ping timeout: 265 seconds]
samhsmith[m] has quit [Ping timeout: 240 seconds]
pkill9 has quit [Ping timeout: 265 seconds]
novakane[m] has quit [Ping timeout: 258 seconds]
ifreund_ has quit [Ping timeout: 272 seconds]
pkill9 has joined #river
edrex has quit [Ping timeout: 244 seconds]
Bonicgamer[m] has quit [Ping timeout: 272 seconds]
Edd[m]2 has joined #river
samhsmith[m] has joined #river
Bonicgamer[m] has joined #river
novakane[m] has joined #river
edrex has joined #river
ifreund_ has joined #river
_whitelogger has joined #river
waleee-cl has quit [Quit: Connection closed for inactivity]
gspe has joined #river
leon-p has joined #river
gspe has quit [Quit: gspe]
gspe has joined #river
emersion has quit [Remote host closed the connection]
emersion has joined #river
skuzzymiglet is now known as I
I is now known as skuzzymiglet
waleee-cl has joined #river
<novakane[m]> hey, is there a alternative to `swaymsg -t get_tree | grep "app_id"` please?
<leon-p> maybe there is some foreign-toplevel thing?
<leon-p> basically having something like that is simple, since river supports foreign-toplevel, but I don't think anything like that exists
<novakane[m]> alright thanks, it's helpful sometime to make some floating window but not really a priority
<ifreund> hmm, does that really not exists yet?
<leon-p> there are tons of foreign-toplevel clients, but I have found none that just list all available toplevels
<leon-p> but I am currently writing one
sjtio has joined #river
<leon-p> works, but naively assumes all handle events are send in order, which may break on some compositors
<leon-p> novakane[m]: ^ for you
<novakane[m]> leon-p: nice thanks I'm gonna try it
<leon-p> (note that I couldn't test it on river yet, don't have it build on this laptop)
<novakane[m]> Looks like everything works fine
<novakane[m]> on river
<leon-p> nice
dominikh has quit [Remote host closed the connection]
dominikh has joined #river
<novakane[m]> you're really efficient
<leon-p> well it's a fairly trivial program if you are used to Wayland code
<leon-p> also I have dabbled with foreign-toplevel before and so did not need to read the protocol
<ifreund> whoops, didn't look back here before I made one too: https://github.com/ifreund/ltoplevels
<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> we use wayland scanner to generate some C code still due to https://github.com/ziglang/zig/issues/131
<leon-p> I see
<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
gspe has quit [Quit: gspe]