<ifreund>
got the ext-session-lock-v1 implementation working :)
<ifreund>
goodnight all o7
mon_aaraj has joined #river
mon_aaraj has quit [Ping timeout: 268 seconds]
mon_aaraj has joined #river
mon_aaraj has quit [Ping timeout: 240 seconds]
mon_aaraj has joined #river
mon_aaraj has quit [Ping timeout: 256 seconds]
mon_aaraj has joined #river
mon_aaraj has quit [Ping timeout: 250 seconds]
mon_aaraj has joined #river
mon_aaraj has quit [Ping timeout: 256 seconds]
mon_aaraj has joined #river
mon_aaraj has quit [Ping timeout: 256 seconds]
mon_aaraj has joined #river
snakedye has joined #river
p00f has left #river [#river]
mon_aaraj has quit [Ping timeout: 260 seconds]
mon_aaraj has joined #river
mon_aaraj has quit [Ping timeout: 240 seconds]
mon_aaraj has joined #river
tiosgz has joined #river
<tiosgz>
ifreund: how is it with the solid color, actually? your implementation of session-lock renders everything (as the user would most likely expect)
<tiosgz>
but in the protocol you wrote that the compositor is supposed to only render a solid color (or some stuff alike layer-shell)
<tiosgz>
is it compositor policy then?
mon_aaraj has quit [Ping timeout: 240 seconds]
mon_aaraj has joined #river
noopdecoder has joined #river
noopdecoder has quit [Client Quit]
<leon-p>
speaking of that part in the protocol, "Instead the compositor should blank all outputs with an opaque
<leon-p>
color such that their normal content is fully hidden.
<leon-p>
"
<leon-p>
sounds a bit wrong to me. Maybe it should say "the normal content should not be rendered" or something like that.
<tiosgz>
or even let the compositor decide (because if you as a user run semitransparent swaylock, you expect everything to still be visible through it, don't you?)
<leon-p>
tiosgz: the protocol states that the only surfaces that should be shown are a) the lock surface and b) surfaces the compositor deems worthy of being shown while locked (for example status bars, or perhaps even something like swaybg). So yes, it is compositor policy, with the strong recommendation to not render regular windows.
<leon-p>
tiosgz: semi-transparent swaylock is an idea as good as a water-slide without water. What's the point if everything is still shown?
<tiosgz>
nobody can interact with it
<leon-p>
I know a lot of people prefer such aesthetics, so I would actually welcome the protocol forcing them to do the right thing :P
<tiosgz>
:D
<tiosgz>
not me though, i did it only for testing
<leon-p>
also consider the following scenario: you have your compositor locked transparently. Suddenly a new window appears with sensitive information. but you don't notice, because you left, thinking your device is safe.
<leon-p>
if you /really/ want a transparent lock, take a screenshot, dim it a bit and display it on your lock surface.
<tiosgz>
hmm. that makes sense for the usual case, indeed
tiosgz has quit [Quit: tiosgz]
waleee has joined #river
noopdecoder has joined #river
Phyrric_ has quit [Ping timeout: 245 seconds]
noopdecoder has quit [Quit: noopdecoder]
Phyrric_ has joined #river
<ifreund>
tiosgz_: no, the implementation doesn't render everything. Just a solid black background, lock surfaces, and drag icons
<ifreund>
the wording of the protocol may be able to be improved there
<tiosgz_>
oh, gosh. i'm stupid. sorry for the hassle
<tiosgz_>
it seems like i forgot to do one `git checkout`, namely just before compiling river
<ifreund>
heh
<tiosgz_>
and since i'm used to not being to run swaylock in kiwmi, i didn't notice
<tiosgz_>
*being able
<tiosgz_>
uh, yep, that was it. again, sorry for the hassle. everything's as expected now
<ifreund>
no worries, thanks for testing!
<leon-p>
seems like it works for every arbitrary ascii char. Nice!
<leon-p>
*non-alphanumerical ascii char
<leon-p>
oops, that was intended for #river-offtopic
<tiosgz_>
actually… if i kill the swaylock and replace it with another (which i then unlock normally), river gives input back to normal clients but doesn't respond to its keybinds (maybe because it doesn't restore normal mode?)
<leon-p>
tiosgz_: you can try out whether it is still in locked mode by binding a key in locked mode
<tiosgz_>
yep. it is
<ifreund>
ah I see the bug, thanks
* ifreund
finished this pretty late last night and didn't test *that* well yet
<tiosgz_>
at least you have already finished it
<ifreund>
tiosgz_: pushed a fix
<leon-p>
Hmm... I wonder if it would make sense to have a way to alert other clients of the screen locking. The protocol allows the compositor to still show surfaces, like for example status panels. The status panel could then switch to a mode where it will not expose sensitive information and not show things that don't make sense on a lock screen (like tag indicators). Android does something similar.
<ifreund>
yeah, I wanted to get the implementations done as quick as possible so that I can have the high ground in complaining about wayland-protocols being slow. Hopefully I won't need to though
<ifreund>
I guess we'll see when the 30 day discussion period runs out
<ifreund>
leon-p: I think i'd rather have the user configure river to show specific clients on the lock screen and make the user responsible for deciding what is sensitive or not
<ifreund>
having the clients decide doesn't seem right to me as everyone has different opiniions on what is "sensitive'
<leon-p>
I don't think that will cover all use cases. For example, a user might want a notification daemon that notifies while locked but only shows the actual message when unlocked
<ifreund>
leon-p: can't you run a 2nd instance that is configured differently while locked?
<leon-p>
probably, a bit hacky though IMO
<leon-p>
although I suppose you could implement such things in the locker
<ifreund>
Yeah I agree that it's a bit hacky, I want to avoid any kind of feature creep before this protocol get merged though
<leon-p>
that's fair
<leon-p>
although if the protocol doesn't do this, the Big Desktops™ will probably do it via a side channel, which will be DBUS. And then we all have to support that...
<ifreund>
I don't think gnome will even support this protocol
<ifreund>
they want GDM integration
<leon-p>
that's true
<leon-p>
I wonder if it would it make sense to specify what the compositor is supposed to do for screen capture / screenshots. I can see people arguing both for capturing the lock screen and the content "beneath" it.
<ifreund>
I think capturing the content "beneath" it would be insane
<ifreund>
screenshots capture what's on your screen, which is a lockscreen
<leon-p>
I don't think it makes much sense either, but it is not specified, so people will do it.
<Nulo>
So wait, there's a locker that implements the protocol already?
<ifreund>
Nulo: there's a PR open for swaylock :)
<ifreund>
I haven't found time to rewrite waylock yet
<Nulo>
ifreund, awesome I'll try it
<mon_aaraj>
Hey, I've posted this question just a couple hours before and I'm sorry if you've seen it already but I haven't got any response so I'll assume no one saw it: I seem to be having issue with the map command; running something like `riverctl map normal None Print spawn "grim \"$(slurp)\" - | wl-copy"` will just run the showed command, seemingly without even mapping it. I know I did something wrong,
<mon_aaraj>
I'm just not sure what it is. Thank you so much for helping and I'm sorry for the inconvenience!
<ifreund>
mon_aaraj: try single quotes on the outside instead of double quotes
<mon_aaraj>
Ah, I see! It seems to work, thank you very much once again!