@pixelherodev @RL_Dane
Hmm, OpemBSD is a new one to me too. XD
Okay, so swaybg is great and all, and there are good tools for wayland (like clipman), but I *despise* swaylock. Maybe it's just me. I've never liked it, though the reasons are always shifting. The primary one has always been that it's far less customizable than i3lock was. For example, I can't find an option to passthrough media keys so that my bluetooth headset's controls work when my laptop is locked.
@pixelherodev @RL_Dane
Not gonna lie, swaylock alone has had me considering going back to i3.
…but then I'd have to give up foot as my terminal, which I love. It's a tough choice.
@benjaminhollon @pixelherodev
Isn't there something analogous to foot in the #X11 world?
Also, is swaylock the only locking program available? That would stink.
I only use i3lock on a single machine, just because it's the one I used first. It's kinda basic.
On this FreeBSD box, I use simple old xlock, which seems to be decent subset of the venerable #XScreensaver
@RL_Dane @pixelherodev
1) I mean, there are other terminal emulators, but I like foot specifically. Fits my needs exactly.
2) I think I saw a couple others? I know there's swaylock-effects which is a fork, but it doesn't add the features I want. Part of the problem is that to my understanding wayland only recently got a proper locking protocol. Perhaps things will be getting better as lockers update with the new protocol.
3) I used i3lock-color. Pretty great and super customizable.
@benjaminhollon @pixelherodev
I didn't know about i3lock-color until this moment!!!
> Part of the problem is that to my understanding wayland only recently got a proper locking protocol. Perhaps things will be getting better as lockers update with the new protocol.
I wonder what @jwz would think about Wayland's locking protocol. He's the author of #XScreensaver and I recall he was quite critical of the dodgy locking mechanism that Gnome was using a few years back
@RL_Dane @benjaminhollon @pixelherodev
I have basically ignored Wayland entirely, since it is incompatible with XScreenSaver. See section "The Wayland Problem" in the manual: https://www.jwz.org/xscreensaver/man1.html#17
I suspect the Wayland developers will take the GNOME approach and write their own locker. If you're lucky, it will actually work. If you're super extra lucky, they'll make their locker able to run XScreenSaver hacks. But I wouldn't hold my breath on either point. See also: https://www.jwz.org/blog/2021/01/i-told-you-so-2021-edition/
@jwz @benjaminhollon @pixelherodev
Thanks for the info, and for replying!
Pity there isn't some kind of kernel-level lock that bypasses all of the hacky bits in X11, Wayland, or the various toolkits.
Does xlock use any xscreensaver code? I noticed that it has a lot of the older Xscreensavers that I loved, like Galaxy
@RL_Dane @benjaminhollon @pixelherodev
A few of the very old savers originated in xlock or its descendant xlockmore. None of the locking or blanking logic was shared.
@jwz @benjaminhollon @pixelherodev
Ah, ok. :)
@RL_Dane @benjaminhollon @pixelherodev
To be clear, locking is a privileged, OS-level task and so it is right and proper for Wayland to build that into the OS (by which I mean the layer that includes the window manager, video drivers and kernel). X11's ancient design forced us to try and do an OS-level task as a user app, with predictably terrible results.
However, the Usual Suspects do not have a good track record of getting this right, so I expect comical disasters to continue unabated.
@jwz @benjaminhollon @pixelherodev
Aye. Security is hard. Just ask the poor saps the developed WEP. XD
@RL_Dane @benjaminhollon @pixelherodev
Before #foot I used #sakura terminal. It was good for my #i3 use.
@inigo @benjaminhollon @pixelherodev
I've heard good things about #Sakura.
@benjaminhollon There's a flag you can add to your key bindings in your sway config that will pass them through swaylock. It works for my keyboard media keys, I assume Bluetooth keys work the same.
@moddedbear
There is??? What's the flag? I couldn't find it anywhere when I looked.
@benjaminhollon Had to check. Just add --locked after the bindsym command. I'm not sure how recent it is but I've had it for a while.
@moddedbear
Ooh, okay. I would've expected it to be a flag of the screenlocker. I never even realized bindsym *accepted* flags. Good to know, thank you much! I will update my config now. :)
@benjaminhollon Yeah it's a little unintuitive but it's nice that you don't have to add separate key binds for the locker. I know there's a couple other flags like --release, but I think --locked is the main one.
@moddedbear
Yeah, I'm gonna have to check through it.
Worked out nicely for my config since I group bindsym commands like so:
bindsym --locked {
# Media
XF86AudioPlay exec playerctl play-pause
XF86AudioPrev exec playerctl previous && ~/.bin/notify-playing
XF86AudioNext exec playerctl next && ~/.bin/notify-playing
}
@benjaminhollon Oh cool I didn't know you can organize binds like that. I guess we both learn something haha
@moddedbear
Unfortunately, vim's syntax highlighting doesn't seem to be aware that I can organize binds like that either, so the whole section is highlighted in red. :P
@moddedbear
Hmm, it's causing some visual weirdness where swaylock's indicator is showing it as a keypress, but functionally it works. Very nice!
@moddedbear
There's also a bit of glitchy-looking-ness, might be caused by wob running behind the scenes. Eh, not a huge deal.
@benjaminhollon Hmm. I also use wob but don't remember getting anything weird.
@moddedbear Hmm, okay. Probably not that then.