Rework discussion

[bew]

Hello, I'm opening this issue to try to regroup discussion about the rework you want to do @PandorasFox.
If you don't want to open the discussion on this, feel free to close this issue.

I started to think about a flexible widget description structure, where we would be able to store the description (from the user) of a given widget (indicator, text, ... rectangle?). This is not intended for the runtime state of a given widget, only it's description.
Here is the current diff of my branch: c85ced6...bew:introduce-widget-description-in-arg-parser

What do you think?

What are your ideas about the rework and how to do it?

[PandorasFox]

Ooh, that's actually pretty close to what I was thinking. I've been working on tinkering with argp some here and I'm going to try and work on nailing down config parsing next there.

That's pretty close to how I was thinking of setting up drawing different parts of the screen - a sort of widget system that's compartmentalizable/independent of one another. What you have is pretty close (actually, a bit better than) what I was thinking of doing.

I actually kinda feel like the better (overall/eventual) solution would be for a rewrite for... most everything, since at the end of the day, i3lock just isn't really meant to be very customizable, so what started out as a quick hack of i3lock at 8am has uh, kinda grown way beyond what I thought it would.

• this fork has a bunch of arguments, most of which usually don't change from run to run.
  • usually you'd do that with a config file
• since the config is rarely updated (and parsing a config file might take a bit of time), it might be best to just park the script as a background daemon that raises itself when needed
  • this has the added benefit of sticking to a valid config if there's an error parsing a config/argument
  • this can be indicated with a widget so that it's clear something happened, but so that the lockscreen still looks roughly as it should

I also kinda feel like some of the stuff (i.e. the clock) aren't ever really going to work well with how i3lock is set up, since i3lock isn't meant to really redraw regularly, which is something that I feel would be nicer if it's designed around that

i3lock also wasn't really designed with having large blurred backgrounds or whatever that's constantly drawn over, so with the knowledge of the widgets, we can just clear their area and then re-rended them instead of redrawing the entire screen, which should also make things seem a bit smoothere.

I guess kinda - I feel like there's a lot of places where this can be improved, so I'm going to go write a toy screenlocker to experiment with a few different things before I come back and work on i3lock. What I'm thinking will probably happen is that I'll build up velock to be at least of feature-parity with i3lock-color (i.e. clock, rings, colors, bars, etc) and then maybe archive this repo or something. I'm not really sure I want to work on i3lock specifically for much longer, but I love the niche that it fills and love tinkering with it.

[PandorasFox]

One of the other problems I've encountered is that as a fork, it's a bit hard to really make packages or anything that stand any chance of ever making it into actual repos, which makes supporting stuff a bit awful. Again, something I didn't really consider when I started this project out 2 years ago in one of my 8am lectures...

[teamdandelion]

Just an idea, although it might be hard to implement: I would love the ability to design the frontend using a well-defined spec, e.g. SVG (or html&css). Particularly if it were then possible to define custom animations or logic for the unlock and verify processes, so that the ring-unlock or bar-unlock are not hardcoded into the program, but are just particular configurations.

I think if you take this idea and run with it, you wind up with something like using Electron for the frontend. Then getting a super slick custom designed lock screen could be as easy as npm installing it. I have no idea how screen lockers are implemented so I don't know if this is feasible. :)

[PandorasFox]

The weird underlying stuff is mostly just grabbing the X root window and grabbing the input device(s), then popping up our own window over all others.

I think my main concern with Electron in a screen locker is that the end goal is to make really reliable/hard to crash so that the session is securely locked, so pulling in more deps is a bit counter to that.

Some (most?) screen lockers just raise themselves when invoked, like i3lock. I think that the gnome screenlocker has a daemon parked in the background, then when invoked it just raises itself.

I think that if I were to use electron for that, it'd be something like:

• background daemon (probably written in C) that holds config/etc and does the screen grabbing and stuff.
• background daemon creates a blank white screen (or, optionally, blurs the screen or something).
• background daemon raises an Electron process that draw over of the window it drew. This way, if the electron process crashes/has an error, security isn't compromised.

A couple (potential?) upsides of Electron is that it might be possible to design some widgets that sit on it that, say, read from spotify's dbus interface, and maybe let you control spotify from your lockscreen (honestly been one of the big annoyances with i3lock for me, since all the media key events are eaten by i3lock, with good reason).

The downsides of it is that it'll be a bit harder to sandbox (i.e. I guess a malicious theme could have a hidden terminal/kill button that drops a pkill i3lock or something?), and that I think it'd be a bit harder to pull off any hardware-accel, like the blurring in i3lock. I guess that's sorta the point of it, but I do really like the idea of quick, in-house blurring in a screenlocker.

I think I might go poke some at working with my toy screenlocker and fleshing it out some this weekend, since a good standard like that would make pretty / extensible lockscreens fairly easy.

I hadn't actually considered electron before now, but that could be a pretty good way to go forward. I don't think it'd be terribly difficult to be able to supply some sort of DBUS interface for the screenlocker - maybe the electron front-end would register a few methods (i.e. getKeyStrokeUpdate, getBackspaceUpdate, etc - essentially callbacks) that get called by the parent daemon (which can also supply a few funcs of its own, i.e. things that expose how many characters you've entered into your password).

I think my only other concern with that would be like, the async nature of it all might sorta mess with animations in the front-end and stuff (i.e. what happens if there's one keypress animation going on and then another gets kicked off?). If I provide an NPM package / interface that acts as the receiver for DBUS stuff and queues stuff to keep it synchronous before it invokes callbacks in the users' electron themes, then that might work.

That seems like it'd be a pretty good way to go forward, although I've no experience with Electron so I'll definitely have to do some work on that to get used to it.

[PandorasFox]

Oh yeah, my other concern would be cursor events: those would be grabbed with the X screen and whatnot, so pointer events wouldn't really happen. However, I could probably rig that up to also pass click events into the electron stuff - or I could not grab the pointer, maybe? I know i3lock has a thing for drawing the pointer, but going down that road seems a bit weird/hard to handle safely.

I think realistically, I might be able to get the X cursor to still show, and I could pass click events through dbus, but mouseover-y stuff wouldn't really be able to work well.

But then again, I haven't worked with Electron ever, so I dunno what kinda interfaces they have for that stuff.

[PandorasFox]

I've come to the conclusion that there's no realistic way to jail things in a screen locker sufficiently to keep it secure. I can think of some good models, but nothing with a sufficient amount of easy customization will ever really simultaneously easy to maintain from a security standpoint, and isn't really worth doing because of that.