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/
leon-p has quit [Quit: leaving]
waleee-cl has quit [Quit: Connection closed for inactivity]
gspe has joined #river
gspe has quit [Quit: gspe]
gspe has joined #river
leon-p has joined #river
<travankor> ifreund: based on your reply on lock screens, are you going to upstream the screensaver protocol?
<travankor> it would be nice to get rid of input inhibit
<travankor> maybe the screensaver protocol could have a way to display certain views (for those that want notifications or whatever available in the lock screen)
<ifreund> travankor: indeed, I would like to see it upstreamed and killing input inhibit would be wonderful
<ifreund> I'm not sure about a mecanism for displaying certain views above the screensaver/lockscreen yet. If there's a simple and robust way to do it I wouldn't be opposed
<ifreund> needs investigation though
<leon-p> I think the protocol should offer a way to let the client display one full-screen view per output. But the compositor should be allowed to display more views if desired (like layer shell thinks on the overview layer, or in hikaris case arbitrary views).
<ifreund> leon-p: do you know off the top of your head how hikari allows configuring what views are shown above?
<leon-p> there is a keybind that marks views as to be displayed above the screen locker. Hikari already has built-in screen-locking.
<leon-p> it also has a dedicated unlocking binary, although I never investigated how it works
<travankor> (hikari explicitly doesn't support input inhibit)
<ifreund> a keybind seems like a strange way to do that tbh, seeems to me that you'd always want the same views/programs visibile
<travankor> tbh i thought hikari lets the user specify them in the hikari config
<leon-p> from what I remember from the hikari introduction video, the idea is that if you have long-running processes like compilations you'd want them to be dislayed even if the screen is locked. or maybe a terminal with top.
<travankor> you have to mark a view as "public"
<travankor> according to the hikari man page
<travankor> there's a view-toggle-public which I think is the keybinding (but I think there's a way to declare certain criteria as public as well)
<ifreund> makes sense
<ifreund> honestly, the simplest way I see would be to either display the overlay layer above the lockscreen or add a new layer-shell layer for the purpose
<leon-p> or maybe just leave it up to compositors to keep displaying arbitrary views whn locked
<ifreund> that's probably fine for the first iteration of the protocol yeah
<leon-p> we should also consider that some compositors may want to keep displaying their UI: Both GNOME and weston for example display their panels when locked.
<travankor> the panels should not be able to accept input though
<leon-p> yeah that is another interesting point: How to do input? Should a pointer be displayed?
<ifreund> IMO the compositor shouldn't pass any input events to clients while locked
<leon-p> agreed. that way UI elements that should be useable when locked must be part of the lock screen, which is a fine compromise, IMO
<ifreund> I don't think it should pass input to the locksceen/screensaver client either
<leon-p> I agree, but if you hope to standardize it this will be a problem.
<leon-p> also keyboard input shut definitely go to the lockscreen. Somehow you have to enter your password.
<leon-p> s/shut/should/g
<ifreund> generic "some character was entered" or "password was cleared" events would be enough to display the UI
<ifreund> the compositor should be what does the authentication
<travankor> I like this idea
<leon-p> seems reasonable.
<leon-p> although I think this discussion should happen either on #wayland or on freedesktops gitlab.
<ifreund> myfreeweb made a strong point in favor of select clients being shown above the lockscreen: on-screen-keyboards are a thing
<leon-p> true.
<travankor> I would prefer a new layer-shell layer rather than reusing an existing layer if you're going down this route -- or make this independent of layer shell
<travankor> a lot of layer shell client authors seem to arbitrarily pick layers without doing much research
<leon-p> btw, river-layout is getting close again. If I haven't missed anything, all that is left is implementing layouts depending on options and porting rivertile and the example layout.
<leon-p> travankor: Or just let the user decide
<travankor> true.
<ifreund> I'm leaning away from doing this through layer-shell being a good idea tbh
<leon-p> there should still be a way to have certain layer surfaces be displayed while locked.
<ifreund> this could be done without explicit support from the layer-shell protocol by whitelisting layer-shell namespaces for example
<ifreund> or by allowing clients to request that an arbitrary surface (be it xdg or layer or whatever) be displayed above the lockscreen
<ifreund> which the compositor would be free to deny of course
<leon-p> that sounds reasonable.
<ifreund> leon-p: also in case you didn't see it, this is what spurred the discussion today: https://github.com/swaywm/wlroots/issues/2706
<leon-p> yeah, I just found it :D
<leon-p> but if clients can request displaying a surface while locked, they should be informed when the screen is locked. Per the examples in that discussion: Panels / notifications / etc may want to hide certain information when locked.
<ifreund> not a fan, if they display sensitive information on the surface they request to be shown while locked that's their fault
<ifreund> sending notifications that the screen is locked/unlocked to clients is a pain because it needs to be done in a double buffered way to avoid races
<gspe> sorry guy, I'd like to try river.. maybe someone have a template for void linux
<travankor> not yet
<travankor> just follow the instruction on README
<gspe> ok thanks
<gspe> how is for everyday use?
<travankor> even though it works, it's still in development until 0.1
<travankor> s/development/a little rough/
<gspe> ok I'll try it, let's see how it works
<gspe> I really like dynamic tailing wm
<ifreund> I've been daily driving it on void for over 6 months at this point
<ifreund> I'm biased though of course :P
<ifreund> the main reason I haven't done a 0.1.0 relase yet is because of impending breaking changes rather than any bugs/missing features
<gspe> yeah seams almost complete
<leon-p> I think we have a problem with Option.set( .{ .string = null })
<leon-p> When using null as default layout namespace, the option can not be changed by the user somehow
<ifreund> indeed, I'll push a fix in a minute
<leon-p> thanks
<ifreund> ugh, i also forgot to support setting string options to NULL in riverctl
<ifreund> not sure what the right CLI is there
<leon-p> probably using some special character to indicate that the following string is not "null" literally, but null
<leon-p> maybe @null@
<ifreund> then it's impossible to set the sting to that value though
<ifreund> I think leaving off the argument is better
<leon-p> sure, make sense.
<ifreund> hrm, maybe special syntax would be cleaner
<ifreund> i'm not sure there's a valid use-case for setting NULL as the value of a string
<ifreund> ugh, maybe we should just outlaw null strings in the protocol
<leon-p> what would the default layout be then?
<ifreund> empty string?
<ifreund> hmm, what is the wire format for NULL string arguments actually?
<ifreund> guess I'm reading libwayland
<ifreund> ah yeah, so NULL is a zero length string on the wire
<ifreund> and an "empty" string is actually a single 0 byte
waleee-cl has joined #river
ifreund1 has joined #river
ifreund1 has quit [Client Quit]
ifreund1 has joined #river
ifreund2 has joined #river
ifreund has quit [Read error: Connection reset by peer]
ifreund1 has quit [Ping timeout: 258 seconds]
ifreund2 is now known as ifreund
<ifreund> leon-p: pushed the fix for setting currently null string options to hopefully unblock you
<leon-p> I'll have a look in a minute.
<ifreund> I'm still not sure where I want the riverctl CLI to land though
<ifreund> I think the most sane thing is to have a special string that means NULL, be it "NULL", "@null@" or whatever
<ifreund> but then we have the problem that some non-riverctl client is totally able to set that special string as the value of the option
<ifreund> the simplest fix would be to amend the protocol to disallow null strings but I'm not totally happy with that either
<ifreund> and indicating null on the riverctl CLI by ommiting the argument doesn't fully solve the problem as we need a way to represent a null get-option result as well
<ifreund> My current favorite idea is to the riverctl CLI unable to distinguish between an empty string value an null string value
<leon-p> that sounds reasonable.
<leon-p> But we are pre 0.1, so we make absolutely no guarantees regarding interface stability. If we don't like it, we can always change it later.
<ifreund> true :D
gspe has quit [Quit: gspe]