waleee-cl has quit [Quit: Connection closed for inactivity]
travankor has joined #river
alexnask[m] has quit [Quit: Idle for 30+ days]
_whitelogger has joined #river
travankor has quit [Ping timeout: 240 seconds]
exception has joined #river
<leon-p>
ifreund: Re using foreign toplevel handles for when advertising views for layouts, I don't think it fits this use case very well, TBH. When you just want a views title or app-id, having to use foreign-toplevel wastes a ton of cycles.
<leon-p>
because of how many events the client reveices
<leon-p>
And regarding your other idea, should I change the protocol to have a layout-manager object? I have no opinion on this, but the sooner we decide the better.
<ifreund>
leon-p: I'm fine with just an app_id for now, we can reconsider as it becomes more clear where river-status/river-control are heading
<ifreund>
and yeah I think the layout-manager thing is more idiomatic wayland than a request that may only be sent once
<ifreund>
Right now I'm thinking that I just want the layout protocol done before 0.1.0, the others can stay as they are for the first release, they have a lot farther to go
<ifreund>
So my prioroties are unblocking you from working on the layout stuff (though I can also do the server implementation if you want) and fixing other bugs/improving documentation
<leon-p>
well, if there are no great protocol changes after today I probably can get the server implementation done before newyears.
<leon-p>
btw, if we have a layout-manager object from which clients bind layout objects, we could probably make those per-output.
<leon-p>
(and it also allows clients to have multiple different layouts, so in general a good idea)
<ifreund>
would making them per output elimintate the need for the serial?
<ifreund>
no I guess not as layout requests can be interrupted
<leon-p>
no, because a layout client may be so slow that it never finished handling a prior request when a new one comes in
<ifreund>
I think making them per-output would still be a good move though
<leon-p>
Ok, then I'll finish up the protocol today
<ifreund>
cool, I'll try to get you another review tonight so you can focus on the implementation without the protocol shifting more
<leon-p>
you operate in the berlin timezone as well, don't you? To give a rough estimate, by 18:00 I should have come up with something useable (still have some other timesinks today).
<ifreund>
yeah I'm in germany currently
<ifreund>
don't know if you noticed, but we have channel logs now thanks to whitequark
jjanzic has joined #river
<leon-p>
oh sweet, another excuse to put off setting up a server with a bouncer!
<ifreund>
yeah, should make things more accessible
waleee-cl has joined #river
leon has joined #river
leon is now known as leon-p-X200
<leon-p-X200>
ifreund: I think we need to rename the "layout request", because technically it is an event and not a request.
<leon-p-X200>
Its probably a bit confusing
<ifreund>
leon-p-X200: layout_update perhaps?
<leon-p-X200>
"update" sounds like something passive, as if the client were just informed of some changes.
<ifreund>
hmm
<ifreund>
layout_required then
<leon-p-X200>
yeah, thats better
<ifreund>
I wonder how long we have until someone complains about us using "master" instead of "main"
<leon-p-X200>
heh. We avoided the word "slave", so I think we are fine
<ifreund>
we have mentions of "slave" in the wiki iirc
<leon-p-X200>
although you could argue that "master" is a poor description of the concept. something like "focus area" would make more sense, but sadly that work it already used
<ifreund>
also main is actually more accurate here, the master views have no control over the others
<leon-p-X200>
maybe we could just quietly purge the words some people may get offended by from the wiki and documentation just to be safe?
<ifreund>
it would probably cause us less headache down the line
<leon-p-X200>
Yeah, I neither want to offend people nor do I want discussions about offending people
<ifreund>
exactly, I just want to get work done :P
<ifreund>
trunk is also the superior default branch name, maybe I should start using that for my projects
<leon-p-X200>
Let's just hope the CoC people don't find our projects.
<ifreund>
yeah I'm not adding a CoC :D
<leon-p-X200>
although if they do, my plan is to just use the GNU one
<leon-p-X200>
thats fairly inoffensive
<ifreund>
probably would be worth it to shut them up and get back to work if it comes to that
<leon-p-X200>
Well, that should be discussed when it comes up; No reason to spend any thought on it while it is not a problem
<ifreund>
+1
<ifreund>
the only reason to to the master->main rename now is because it would be a breaking change down the line
<leon-p-X200>
hmm... Yeah I think I'll do that. Makes more sense than "master"
<ifreund>
yeah, if master made more sense it'd be different. I just took the terminology from dwm though
<leon-p-X200>
just pushed the changes. renamed "layout request" to "layout demand" (thanks thesaurus) and "master" to "main". Also added a small description of what the "main views" actually are.
<leon-p-X200>
(as well as the other stuff we talked about)
<leon-p-X200>
probably missed a few errors that should be raised
<ifreund>
sweet, I'll give it another read a minute
<leon-p-X200>
and I think we should start to make sure the wording is fine. It should be possible for someone without prior experience with dynamic tiling layouts to understand what it does.
<ifreund>
wording was pretty decent I thought, improving that isn't a breaking change either if people have issues with it
leon-p-X200 has quit [Quit: leaving]
<ifreund>
leon-p: hmm, should we allow ommiting a set_view_dimension request to hide views?
<ifreund>
for a given view index I mean
<ifreund>
that seems better than the status quo which would be placing the views behind others
<ifreund>
though maybe that makes more sense if they are transparent?
<leon-p>
well, placing it behind others is not actually "hiding", it'll be visible if you focus it. A ton of dwm layouts use this on purpose
<leon-p>
And if we allow hiding, this is probably the wrong protocol for it
<leon-p>
hiding belongs to a mechanism that also allows changing the tagsets, moving the views to different outputs, changing their position in the view stack, etc.
<leon-p>
also hiding views is aking to "minimizing" them, which I am not a fan of. IMO something like that just does not belong into an advanced window management scheme where multiple workspaces (or in our case tags) are available where unneeded views can be "parked"
<ifreund>
agreed, lets not do that
<ifreund>
I think leaving out an index should be a protocol error though, we shouldn't just silently ignore the layout
<leon-p>
Sure
<ifreund>
yeah, aside from that and my 2 comments on github this looks good to go
<leon-p>
do we really need to send an namespace_in_use event? To me it seems like an error is the way to go
<leon-p>
although an error is fatal of course, which may be a bit too agressive
<leon-p>
yeah, missed that part of your comment :P
<ifreund>
yeah, since the client cannot know what namespaces are in use I'd rather make the error recoverable
<leon-p>
yeah, also good for a client which wants to register multiple layouts, which should not die jsut because one of them re-uses a namespace
<ifreund>
indeed
<leon-p>
by the way, this has just solved the issue of rivertile deciding where to place the master^W main area
<ifreund>
oh? what issue?
<leon-p>
telling rivertile where to place the main area.
<leon-p>
now it can just register four river_layout objects with different namespaces
<ifreund>
ah yeah, that is nice
ifreund1 has joined #river
ifreund has quit [Ping timeout: 246 seconds]
ifreund1 is now known as ifreund
<leon-p>
just ported the C layout in contrib to the new protocol changes
<leon-p>
the protocol feels pretty nice to use
<ifreund>
:)
<ifreund>
I wouldn't spend time writing any example clients aside from the C one for this PR
<ifreund>
everyone should at least be able to read C
<leon-p>
yeah, I don't think I'll learn rust just for this PR
<ifreund>
I can write a rust one in 10-20 minutes if we feel like we want one
<ifreund>
I don't really think we do personally though, I'd rather have a python example
<leon-p>
Is there a Wayland implementation for python already?
<ifreund>
pretty sure I saw libwayland bindings or something
<leon-p>
I have seen some work on writing python modules in zig on reddit recently. Maybe eventually we can provide a python library which handles all the wayland things in zig, where users can create layouts by writing a simple call-back function in python.
<ifreund>
idk if you saw my message earlier, but I also plan to write a client in zig that runs our current layout generators
<ifreund>
lua would probably be a better choice than python for embedding
<leon-p>
I am sure eventually people will do neat things like that. For now we should probably just focus on the basics though.
<leon-p>
and yeah I saw your earlier comment. may be a good idea
<ifreund>
very nice comments in the C example by the way
<leon-p>
Yeah, I wanted to make it as simple as possible to create layouts.
travankor has joined #river
travankor has quit [Remote host closed the connection]