<leon-p>
I have been thinking about the default options problem a bit.
<leon-p>
The best thing I can come up with is somehow flagging all outputs created before the init runs and apply the initial wave of default options (meaning all coming from init) to them as well retroactively
<leon-p>
it is a hack, but I really don't see another way
dominikh has quit [Ping timeout: 246 seconds]
dominikh has joined #river
_whitelogger has joined #river
leon-p has quit [Quit: leaving]
waleee-cl has quit [Quit: Connection closed for inactivity]
yyp has joined #river
yyp has quit [Ping timeout: 246 seconds]
yyp has joined #river
Edd[m]2 has quit [Quit: Idle for 30+ days]
leon-p has joined #river
<ifreund>
leon-p: I'm starting to question whether having per-output layouts and options is really worth the complexity...
<ifreund>
do we really lose that much by making everything global?
<ifreund>
(aside from a lot of work we've put into this path that is...)
<yyp>
And also since there could be multiple tags focused at the same time, per-tag layouts in that case would not work. Should we use the first one? Or the last one? Or the original? So many questions..
<leon-p>
yyp: per tag layouts are not planned and are therefore not a concern. Implement that in your layout.
<yyp>
Oops, misread the original message
<yyp>
nevermind then
<leon-p>
ifreund: I'd prefer to keep per-output layouts.
yyp has left #river ["srry"]
<leon-p>
despite, getting rid of per-output layouts would not solve the problem. You'd still need output defaults for the main_amount and other options.
<leon-p>
you could of let the layout client set those, but I don't think that is good UX
<ifreund>
I was actually proposing getting rid of per-output options as well
<ifreund>
I'm very unsure if this is actually a good idea or not
<ifreund>
I'm just annoyed by the complexity
<leon-p>
I don't like that very much, tbh. The exact same layout on all outputs makes multiple monitors not very useful for me.
<leon-p>
but I am annoyed as well
<ifreund>
I figure the layout generator could still do different things depending on the output
<ifreund>
but river wouldn't have to know or care about it
<leon-p>
sure, but how to configure the layout generator? You'd need different options for different outputs, like main_amount_HDMI1 and main_amount_HDMI2. Then You'd have to use different kaybinds. And then the UX is worse than before we had river-options.
<ifreund>
fair point, that does sound worse
<leon-p>
we could get rid of river-options, but then we'd be less generic again
<leon-p>
actually I don't think that would even solve our problem. Default options would still be needed.
<ifreund>
Right now I'm thinking that river-options needs some new semantics, similar how kakounes options are scoped
<ifreund>
if the option hasn't been defined in the output scope then the global value is used
<leon-p>
you mean global options as fallback options?
<leon-p>
Not sure that would work
<leon-p>
at least not with the current model
<ifreund>
why not?
<leon-p>
because layout clients work like this: they request an per-output option, and if it does not exists they create it and set it to a value.
<leon-p>
so we'd have to explicitly write into the protocol that even if you request a per-output option, you can still get a global one
<ifreund>
yeah, this would require protocol changes along those lines
<leon-p>
and how would you do the switch? When the client already has the global option, and then suddenly the per-output option it requested gets created. what happens?
<ifreund>
I don't know, at least not yet
<leon-p>
braindump: as an alternative to river-options, we could also let layout clients subscribe to keybinds, so they are in charge of their own local values.
<leon-p>
if we actually get rid of per-output layouts, if we have one single globals layout clients. We could get rid of namespaces and simply only allow a single layout client to connect. Choosing between multiple different layouts would then be the done by the client, based on whatever layout configuration mechanism we want.
<leon-p>
although I should add I definitely like the current approach better
<ifreund>
I think we wouldn't actually need any changes to interfaces of the protocol to get the behavior we want, just to the descriptions and server side implementation
<ifreund>
how this would work is if an unset output-specific option is requested with get_option_handle we would initialize it to the global value and send that
<ifreund>
where things get a little trickier is dealing with global options being updated in the server side implementation, but I think that's very doable
<leon-p>
yeah that sounds good.
<leon-p>
we'd just have to document that users should set global options before starting layout generators
<leon-p>
but that won't solve the issues with the per-output options layout and output_title, which have to be created when the output gets created.
<ifreund>
output title is created by river so that's not a problem really
<ifreund>
as for the layout namespace to use, why can't that fallback to a global?
<leon-p>
yeah, actually it can. I guess output_title can as well.
<leon-p>
nope, actually not
<leon-p>
because we have come full-circle
<leon-p>
those global options are set after the initial outputs are created.
<leon-p>
which was our original problem
<ifreund>
that's fine though, as long as nothing request them before the global options are set
<leon-p>
yes, BUT layout and output_title are created on output creation.
<leon-p>
so if we want globals to apply to them, we'd have to do it retroactively
<ifreund>
why does layout have to be created on output creation?
<ifreund>
if it's unset we can just behave as if it were null
<leon-p>
but null is a valid state for layout
<ifreund>
yeah, that's the point?
<leon-p>
I am not sure I follow
<leon-p>
if layout is null, no layout is used. so the user would have to manually set one. we we're talking about default options to avoid just that
<ifreund>
we don't have to actually set it for the output on creation though
<ifreund>
we can just leave it unset and behave as if it were set to null
<leon-p>
so if I understand you correctly, you want to only create the layout per-output option when river actually has to choose a layout?
<ifreund>
only create it when the user sets a per output-option
<ifreund>
otherwise fall back to the global option which defaults to null
<leon-p>
but than the first outputs don't have a layout
<ifreund>
they do if the user sets the global layout option
<leon-p>
so you want to override the per-output layout option when the global one is set?
<leon-p>
because the global one will be set _after_ the per-output ones for the first outputs
<ifreund>
there wouldn't be any per-output layout option until a user explicitly sets one
<leon-p>
that breaks the way river sets layouts
<ifreund>
yeah the layout code would have to be tweaked to fit this, but I don't think it would be particularly hard
<leon-p>
i think I understand what you mean
<leon-p>
but we definitely need to overhaul riverctls options interface then. the distinction between declare-option and set-option does not fit this model and is not a good representation of the protocol IMO
<ifreund>
You're probably right. I'm going to look at the server side of things first though
<leon-p>
of course
<leon-p>
what when a client requests a per-output option which does not exist and a global option does not exist either? Is a global or a per-output option created?
<leon-p>
asking because rivertile (and I assume all layout in the future) set options to default values when they are unset.
<ifreund>
I think both would be created
<ifreund>
I think I might also end up changing the protocol to better fit this new model
<leon-p>
ok, so if a client requests a per-output option that does not exist, it gets the global one. What do we do when it tries to set the option? Create the per-output one it requested in the first place?
<ifreund>
probably
<leon-p>
hmm...
<ifreund>
though this could likely be made less convoluted with some protocol improvements
<leon-p>
I think I get the overall idea, but I am not sure on the details. If I was a user wihtout any knowledge, all that would probably seem like spooky action at a distance.
<leon-p>
my problem here is that layout clients set options. that makes sense when writing them, but for a user that is totally opaque
<leon-p>
maybe we should seriously consider only allowing a single layout client to connect at once
<ifreund>
probably need some way to inspect options
<leon-p>
you mean some request that makes the server send you all option names?
<ifreund>
or some other way to implement that functionality in a client
<ifreund>
All this stuff sounds pretty racy, but I don't think we actually care that much
<leon-p>
it breaks apart as soon as a user starts a layout client before setting the default options
waleee-cl has joined #river
<leon-p>
ifreund: btw, do you have any idea on the foreign-toplevel issue? (output enter not send when handles are advertised). Is it a river issue or a wlroots issue? I'd like to tackle that but not sure how much of that protocol wlroots takes care of.
<ifreund>
leon-p: oh I think I know what's happening there, you bind the foreign-toplevel-manager before the wl_output
<leon-p>
that should be fine though, since the toplevel handles get bound after both toplevel-manager and all wl_outputs.
<leon-p>
also doing some printf debugging I found out I do not receive the event _at all_
<ifreund>
not from the server's perspective, it sends all the handles and their initial events as soon as you bind the manager
<ifreund>
iirc ammen99 mentioning this issue at some point
<leon-p>
does it really? I was under the impression the registry just fires all events away and only then handles the server the responding requests
<ifreund>
and yes your right that's how it works from the clients perspective
<ifreund>
but the server doesn't know that the wl_output has been bound until it gets the request
<leon-p>
the apparent workaround is getting a second registry, which is ugh
<ifreund>
which comes after the request binding the toplevel-manager
<ifreund>
yeah I'm not a fan of the situation either, wonder if we can fix it somehow for foreign-toplevel-info
<leon-p>
I wonder if I can just store all values when the toplevel-manager is advertised and bind it later without a second registry...
<ifreund>
yeah you can
<ifreund>
just do a roundtrip after binding the wl_outputs but before binding the registry
<ifreund>
s/registry/foreign-toplevel-manager/
<leon-p>
A server side solution might be the server advertising wl_outputs first, then the toplevel-manager.
<ifreund>
indeed, though libwayland doesn't make that easy
<leon-p>
I have a suspicion this issue will come up a lot with protocol extensions in the future...
<leon-p>
its not exactly uncommon to depend on the wayland core objects
<leon-p>
and it works. thanks
<ifreund>
no problem, it's definitely an ugly wart of this protocol
<leon-p>
interestingly its a problem of toplevels being able to appear on multiple outputs. otherwise you could have an output-toplevel-manager and have new_handle be an output event.
FollieHiyuki has joined #river
FollieHiyuki has quit [Client Quit]
FollieHiyuki has joined #river
FollieHiyuki has quit [Remote host closed the connection]
FollieHiyuki has joined #river
FollieHiyuki has quit [Remote host closed the connection]