travankor has quit [Remote host closed the connection]
sfreimuth has quit [Ping timeout: 248 seconds]
FollieHiyuki has joined #river
FollieHiyuki has quit [Client Quit]
waleee-cl has quit [Quit: Connection closed for inactivity]
FollieHiyuki has joined #river
FollieHiyuki has quit [Client Quit]
FollieHiyuki has joined #river
FollieHiyuki has quit [Client Quit]
<ifreund>
yeah kakoune is super nice, no regrets switching from vim here
<ifreund>
do we actually have a solid use case for seat-specific options?
<leon-p>
other than perhaps input device related stuff, i can't think of any
<ifreund>
I guess repeat rate and delay
<ifreund>
though that may be better set per input device
<ifreund>
and we want a dedicated protocol for that anyways I believe
<ifreund>
I think I'm going to leave out per-seat options for now
<leon-p>
yeah, let't leave seats out for now
<leon-p>
we can always add that later
<leon-p>
but per-output is important IMO
<ifreund>
I agree, though its importance is also fairly river-specific
<ifreund>
maybe not, you can configure e.g. border width and what not in an output-specific way in sway right?
<ifreund>
I wonder if there's any way to allow unsetting options that isn't racy
<leon-p>
I think in sway border-width is actually a per-view value.
<ifreund>
ah yeah makes sense
<ifreund>
and gaps are probably per-workspaces
<leon-p>
since the life-time of the database is relatively short, I think we can live without a way to remove values for now
<leon-p>
hmm... I think sway also has gaps per output in addition to per workspace, at least judging by the possible swaymsg commands.
<ifreund>
If its something we ever want to support we should probably consider it now as implementing it later would almost certainly be more painful
<leon-p>
I think it would be overkill. I think sway is just a bit special in that regard.
<leon-p>
I still thing a global list with an optional wl_output pointer is the way to go
<ifreund>
I was gonna make this a hashmap
<ifreund>
though maybe list isn't long enough for that to be worth it
<leon-p>
how would you do the per-output thing with a hashmap?
<leon-p>
include the output name in the key?
<ifreund>
that wouldn't be robust
<ifreund>
the simplest way would be to have a hashmap per output
<leon-p>
hmmm...
<ifreund>
but I'm thinking you're right that a global list would be simpler and use less memory
<leon-p>
and is more ergonomic to use, at least IMO.
<ifreund>
idk, calling a get() function with the desired key is nicer than iterating the whole list manually
<leon-p>
for the server implementation propably
<leon-p>
but a client would need to differentiate between the global and the different per-output lists
<leon-p>
not sure about this
<ifreund>
A client will also likely only store a few options it cares about
<ifreund>
I think we don't want a way to remove values in the protocol: this would make client code much more annoying to write with little benefit
<leon-p>
global list would have the advantage that options survive the destruction of an output though.
<ifreund>
also we don't want clients changing the type of the "default" options river sets
<leon-p>
yeah, let's not make options removeable
<ifreund>
output-specific options can't survive the destruction of the wl_output globabl
<ifreund>
or wait no, they totally could
<ifreund>
but not the destruction of river's Output struct
<ifreund>
leon-p: pushed a second draft of the protocol
<leon-p>
I'll have a look at it in a second
<leon-p>
Since we are already pumping out protocols left and right, why don't we also try a layer shell replacement? heh :D
<ifreund>
heh, if you want to have a crack at it be my guest :P
<leon-p>
Nah, I think what I'll do is hop and the standardisation request over at freedesktops gitlab and complain^w provide criticism.
<leon-p>
s/and/on/
<ifreund>
I must say, writing protocols is pretty fun. It's nice to have my own compositor to make that possible :D
<leon-p>
agreed :D
<ifreund>
s/my own/our own/
<leon-p>
meh, judging by code its like 9/10 yours, so keep your "my" :P
<leon-p>
although I am certainly happy my lazyness lead me to contribute to river rather than write my own compositor from scratch :D
<ifreund>
I've also succeeded in getting you to learn zig it seems :P
<leon-p>
totally :D
<leon-p>
And I am not regretting that
<ifreund>
and I think you've had a much greater than 1/10 impact on design
<leon-p>
That's my life long experience as a complainer hard at work
<ifreund>
hmm, I think zriver_option_handle_v1 might be the more idiomatic name for the second interface
<leon-p>
+1
<leon-p>
I am really looking forward to what will be possible if all three (or four?) protocols are done and implemented
<ifreund>
same, we've got some work to do :D
<leon-p>
and we chose a brilliant time for it, about a month before all the exams
<ifreund>
oh yeah, I'm always the most productive when I'm procrastinating though
<ifreund>
I think river-config should actually be quite easy to implement as it doesn't really interact with anything else yet
<leon-p>
right, it's basically just a list.
<ifreund>
I need to get some other work done first though.
<leon-p>
although for rivers config values you'll need to handle the changes
<leon-p>
is the per-output-transaction happening before or after river-config?
<ifreund>
nah that can happen in follow up commits
<ifreund>
oh yeah I need to do that too
<leon-p>
well, then I'll try to finish up river-layout this weekend.
<ifreund>
hmm, I'm going to try and get my fosdem slides done in the next couple hours so I can work on those things
<leon-p>
good luck! I am looking forward to your talk
<ifreund>
thanks
travankor has joined #river
travankor has quit [Ping timeout: 240 seconds]
jjanzic has quit [Ping timeout: 260 seconds]
entenel has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
waleee-cl has joined #river
FollieHiyuki has joined #river
entenel has joined #river
FollieHiyuki has quit [Quit: WeeChat 3.0]
<leon-p>
ifreund: do you think the layout name (the "=[]") should also be removed from river-layout? After all, this can also be done using river-config
<leon-p>
Oh. Thinking about it, this also just solved how I get the status string to my bar :D
<ifreund>
leon-p: yeah I'd say we should drop the layout name
<ifreund>
just pushed an untested river-options implementation to the branch
travankor has joined #river
betawaffle has quit [Read error: Connection reset by peer]