<edrex>
but I might be happy to settle for integration with existing compositors if I can get enough metadata out and direct windows effectively
<leon-p>
RE: hidden tabs: In Wayland there really is nothing special about "hidden" things. They simply don't get displayed and that's it. The applications don't even know anything about it. So I am certain Sway does not resize hidden tabs. That would make no sense
<edrex>
one of the things that's frustrating for me with sway is that it's hard to say: i'm going to run a command that will create a new window, and I want it placed here (ad hoc not a priori)
<edrex>
i have a script that does some contortions with PIDs and such to make that work in sway, but it's pretty awkward
<leon-p>
regarding your compositor idea: Have a look at the foreign toplevel protocol stuff, that allows you to track certain things about open toplevels (which is basically the Wayland term for toplevel (hence the name) application windows). It is planned to have a special protocol extending that even further in river. Maybe that is enough for your needs
<edrex>
thanks, that is very helpful!
<leon-p>
also, layout generators will be wayland clients as well in the future. See the PR I am working on if you are interested.
<edrex>
It's actually not that terrible, except it accumulates rules over time.
<leon-p>
So it is perfectly possbile to write some sort of "river manager", which checks open applications, providis layouts and does all the river settings and stuff
<edrex>
leon-p: yeah, i was reading it and planning to start there rather than with the current protocol
<leon-p>
then you will have found the C example in contrib/. That is a good starting point both for layouts and Wayland clients in general
<edrex>
What are the advantages of a wayland protocol vs pipes? Types? Binary interface? shared memory?
<leon-p>
by the way, if you start designing your "river manager" now, your ideas and feature requests and be considered /before/ we start work on the next version of river-stats :)
<leon-p>
RE: Wayland-protocol vs pipe: The protocol is considerably easier for advanced communication and it is completely async and it allows the layout generator to be integrated with other wayland stuff
<edrex>
I need to write toy code to learn about what's available now so i can complain effectively
<leon-p>
heh :)
<leon-p>
by the way, you can also set all river settings from your code via the Wayland protocol. Literally everything can be changed live. So content-aware settings are totally possible
<edrex>
thanks a lot for engaging with me :) I'll keep learning and try to be helpful with testing and use cases where I can.
<leon-p>
glad I could help
<leon-p>
thinking about the "river manager" idea, we could probably even have some sort of river-dconf-bridge, if we ever decide to go User Friendly™. Not a very pleasant thought, but certainly possible.
waleee-cl has quit [Quit: Connection closed for inactivity]
travankor has joined #river
trav20240 has joined #river
travankor has quit [Remote host closed the connection]
trav20240 is now known as travankor
waleee-cl has joined #river
travankor has quit [Ping timeout: 240 seconds]
waleee-cl has quit [Quit: Connection closed for inactivity]
<ifreund>
I have no interest in maintaing a dconf bridge thing, though that should be doable out of tree eventually
waleee-cl has joined #river
job has left #river ["Leaving"]
<leon-p>
ifreund: I was wondering how to raise a protocol error to the client. I looked a bit through the code but could not find any examples.
<ifreund>
leon-p: you want wl.Resource.postError(), though zig-wayland could make this nicer to use
<ifreund>
we should have postError() functions for each object taking the apporpriate error enum
<leon-p>
Ah. I found that function, but could not find it in river grepping around, so I was not sure.
<leon-p>
I'll try it
<leon-p>
I'm down to a single compiler error, so we are close
<ifreund>
I'm going to push a commit to zig-wayland doing what I said in a couple minutes
<ifreund>
pushed it, though I haven't actually tested aside from making sure it compiles
<leon-p>
I'll check it out. thanks
<leon-p>
Don't know if it actually works yet, but I just added the errors to the protocol and zig-wayland correctly generated the postError() method
<leon-p>
btw, are there any plans to eventually make the output of the zig-wayland scanner formated?
<ifreund>
hmm, I could have it invoke zig fmt on the output dir automatically
<ifreund>
would that be useful? I've just been running zig fmt manually on the dir when I want to read the generated code
<ifreund>
hmm, zig fmt is part of the std so I could also just call it directly...
schmo has joined #river
<schmo>
hellooo
<schmo>
I have been trying out river and it seems to freeze at random. I can fix it by switching back and forth from another TTY. Is this just because it is early stages and buggy, or am I doing something wrong? I installed it from the AUR.