11:55 <travankor> ifreund: based on your reply on lock screens, are you going to upstream the screensaver protocol?

11:55 <travankor> it would be nice to get rid of input inhibit

12:03 <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)

12:11 <ifreund> travankor: indeed, I would like to see it upstreamed and killing input inhibit would be wonderful

12:13 <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

12:13 <ifreund> needs investigation though

12:16 <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).

12:23 <ifreund> leon-p: do you know off the top of your head how hikari allows configuring what views are shown above?

12:24 <leon-p> there is a keybind that marks views as to be displayed above the screen locker. Hikari already has built-in screen-locking.

12:25 <leon-p> it also has a dedicated unlocking binary, although I never investigated how it works

12:26 <travankor> (hikari explicitly doesn't support input inhibit)

12:27 <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

12:27 <travankor> tbh i thought hikari lets the user specify them in the hikari config

12:28 <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.

12:29 <travankor> you have to mark a view as "public"

12:29 <travankor> according to the hikari man page

12:32 <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)

12:34 <ifreund> makes sense

12:35 <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

12:35 <leon-p> or maybe just leave it up to compositors to keep displaying arbitrary views whn locked

12:36 <ifreund> that's probably fine for the first iteration of the protocol yeah

12:37 <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.

12:39 <travankor> the panels should not be able to accept input though

12:40 <leon-p> yeah that is another interesting point: How to do input? Should a pointer be displayed?

12:41 <ifreund> IMO the compositor shouldn't pass any input events to clients while locked

12:42 <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

12:43 <ifreund> I don't think it should pass input to the locksceen/screensaver client either

12:44 <leon-p> I agree, but if you hope to standardize it this will be a problem.

12:44 <leon-p> also keyboard input shut definitely go to the lockscreen. Somehow you have to enter your password.

12:45 <leon-p> s/shut/should/g

12:45 <ifreund> generic "some character was entered" or "password was cleared" events would be enough to display the UI

12:45 <ifreund> the compositor should be what does the authentication

12:45 <travankor> I like this idea

12:46 <leon-p> seems reasonable.

12:47 <leon-p> although I think this discussion should happen either on #wayland or on freedesktops gitlab.

12:49 <ifreund> myfreeweb made a strong point in favor of select clients being shown above the lockscreen: on-screen-keyboards are a thing

12:50 <leon-p> true.

12:52 <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

13:12 <travankor> a lot of layer shell client authors seem to arbitrarily pick layers without doing much research

13:12 <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.

13:12 <leon-p> travankor: Or just let the user decide

13:12 <travankor> true.

13:13 <ifreund> I'm leaning away from doing this through layer-shell being a good idea tbh

13:15 <leon-p> there should still be a way to have certain layer surfaces be displayed while locked.

13:15 <ifreund> this could be done without explicit support from the layer-shell protocol by whitelisting layer-shell namespaces for example

13:16 <ifreund> or by allowing clients to request that an arbitrary surface (be it xdg or layer or whatever) be displayed above the lockscreen

13:17 <ifreund> which the compositor would be free to deny of course

13:18 <leon-p> that sounds reasonable.

13:19 <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

13:20 <leon-p> yeah, I just found it :D

13:21 <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.

13:22 <ifreund> not a fan, if they display sensitive information on the surface they request to be shown while locked that's their fault

13:23 <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

13:48 <gspe> sorry guy, I'd like to try river.. maybe someone have a template for void linux

13:49 <travankor> not yet

13:50 <travankor> just follow the instruction on README

13:50 <gspe> ok thanks

13:50 <gspe> how is for everyday use?

13:52 <travankor> even though it works, it's still in development until 0.1

13:52 <travankor> s/development/a little rough/

13:55 <gspe> ok I'll try it, let's see how it works

13:56 <gspe> I really like dynamic tailing wm

13:57 <ifreund> I've been daily driving it on void for over 6 months at this point

13:58 <ifreund> I'm biased though of course :P

13:59 <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

14:00 <gspe> yeah seams almost complete

15:05 <leon-p> I think we have a problem with Option.set( .{ .string = null })

15:06 <leon-p> When using null as default layout namespace, the option can not be changed by the user somehow

15:11 <ifreund> indeed, I'll push a fix in a minute

15:11 <leon-p> thanks

15:22 <ifreund> ugh, i also forgot to support setting string options to NULL in riverctl

15:22 <ifreund> not sure what the right CLI is there

15:24 <leon-p> probably using some special character to indicate that the following string is not "null" literally, but null

15:24 <leon-p> maybe @null@

15:24 <ifreund> then it's impossible to set the sting to that value though

15:24 <ifreund> I think leaving off the argument is better

15:25 <leon-p> sure, make sense.

15:40 <ifreund> hrm, maybe special syntax would be cleaner

15:41 <ifreund> i'm not sure there's a valid use-case for setting NULL as the value of a string

15:50 <ifreund> ugh, maybe we should just outlaw null strings in the protocol

15:56 <leon-p> what would the default layout be then?

16:01 <ifreund> empty string?

16:04 <ifreund> hmm, what is the wire format for NULL string arguments actually?

16:04 <ifreund> guess I'm reading libwayland

16:06 <ifreund> ah yeah, so NULL is a zero length string on the wire

16:06 <ifreund> and an "empty" string is actually a single 0 byte

17:23 <ifreund> leon-p: pushed the fix for setting currently null string options to hopefully unblock you

17:23 <leon-p> I'll have a look in a minute.

17:23 <ifreund> I'm still not sure where I want the riverctl CLI to land though

17:24 <ifreund> I think the most sane thing is to have a special string that means NULL, be it "NULL", "@null@" or whatever

17:25 <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

17:26 <ifreund> the simplest fix would be to amend the protocol to disallow null strings but I'm not totally happy with that either

17:27 <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

17:28 <ifreund> My current favorite idea is to the riverctl CLI unable to distinguish between an empty string value an null string value

17:30 <leon-p> that sounds reasonable.

17:31 <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.

17:32 <ifreund> true :D