New Prototype Screen Lock Program: zedlock

[Dennis Wollersheim]

Nice!  Thanks.

Dennis

Clarke Wixon wrote:
> I have put together a proof-of-concept "screen lock" prototype 
> intended to prevent unintended touchscreen inputs while the phone is 
> pocketed, against your ear, etc.  The program is called "zedlock" and 
> it's available at my wiki page:
>
> http://wiki.openmoko.org/wiki/User:Quicksand#zedlock
>
> There are also screenshots there.
>
> The prototype requires python, pygtk, and pycairo, but the final 
> version will be in C.
>
> I'm interested in comments and thoughts from the community.
>
> The README follows:
>
> ---
>
> Zedlock 0.0.1 PROTOTYPE
> Copyright (C) 2007 Clarke Wixon
>
> How it works
>
> This is a screen-lock program in prototype form. To run it, just run 
> zedlock.py from a terminal in the directory where it's installed.
>
> It's really simple. To unlock, just trace a large 'Z' with a single 
> stroke of your finger or stylus, anywhere on the screen. It must be 
> BIG ENOUGH (about half the smallest screen dimension in both height 
> and width, approx. 2cm on the Neo), it must be drawn in the CORRECT 
> SEQUENCE (from top-left to bottom-right), and it must be QUICK ENOUGH 
> (completed in less than one second). Within these parameters, a fair 
> amount of variation (i.e., sloppiness) is tolerated. (As a result, you 
> can make some non-Z patterns that fool it.)
>
> Who's Zed?
>
> Zed's dead, baby, Zed's dead.
>
> No, really, why Zed?
>
> There are a bunch of things out there already called "zlock" or the 
> like. I selected the 'Z' glyph because it's fast and easy to make 
> without looking, and its four points are easy to pull out of a stream 
> of touchscreen data -- they are simply the maxima and minima of the 
> functions (x+y) and (x-y). I don't need to keep a linked list of 
> intermediate points or anything like that; these points are updated 
> on-the-fly.
>
> Why would I want this?
>
> You don't need to be looking at the screen to unlock it. It is pretty 
> unlikely to unlock accidentally (by your face while you are on the 
> phone, in your pocket, etc.). But it's simple and fast enough to 
> perform frequently and easily, and to become second-nature.
>
> Plus it looks nice: gtk+ and cairo are used for fluid anti-aliased 
> graphics. Visual feedback is provided after a stroke is completed: an 
> openmoko-orange line shows where you made your stroke, and if it finds 
> the 'Z' pattern, it is highlighted in white for a moment.  If your 
> stroke doesn't meet the criteria, you get a big red 'X' on the screen 
> and a three-second lockout.
>
> With the iPhone and the Qtopia phone platform, you need to be looking 
> at the touchscreen to unlock it. Their sliders and animated keys are 
> cool, but this is better.
>
> Remember, this is a prototype
>
> To install it, copy zedlock.py and zedlock.png to your home directory 
> (or a subdirectory), make sure zedlock.py is executable, and run it 
> from the directory you installed it in. The program depends on 
> python-pygtk and python-pycairo. Note that it doesn't actually do 
> anything all that functional yet -- it is simply a demonstration 
> program. This prototype doesn't actually lock or unlock anything; it 
> just clears the screen after each stroke (and the subsequent visual 
> feedback) so you can try it again and again and again.
>
> The program should be more-or-less QVGA-friendly (well, almost, just 
> change two global variables) and orientation-friendly already, but YMMV.
>
> Yes, it's slow, especially to start up. But that's embedded python for 
> ya. Plus I had to do some weird hacky things in cairo to get it to 
> render predictably. This is my first cairo project and my first python 
> program, SO DON'T GIVE ME ANY GRIEF! There are probably terrible, 
> ugly, spaghetti-code-monsters in there if you care to look. They'll go 
> away over time.  :)
>
> Future Plans
>
> After the featureset solidifies a bit more, I will rewrite it in C 
> (which I'm much more comfortable with), optimize it (a lot!), and add 
> some features:
>
> 1) It will be rotationally insensitive so you don't need to look at it 
> to determine portrait vs. landscape before you unlock. This will be 
> pretty easy to add.
>
> 2) The text on there is statically-coded right now, and fixing that 
> will be trivial, so don't complain about it now. It doesn't actually 
> tell you the GSM/GPRS status or even the real time of day. Yes, wise 
> guy, IT'S ALWAYS 5:35 pm HERE.
>
> 3) Eventually it will get a battery/charging state icon, GSM signal 
> strength bars, and a ringer volume indicator, so you can see those 
> things while the screen remains locked. I don't want to make the 
> interface too cluttered, but those items seem essential.
>
> 4) Ideally this will slip right into the OpenMoko power management 
> scheme. Preferably neod and/or the dialer will *lock* the screen and 
> require an unlock program (such as zedlock) in the following 
> circumstances:
>
>  * immediately after an incoming call is answered
>    (to prevent touchscreen input from the user's face or ear)
>
>  * immediately after an outgoing call is dialed
>    (ditto)
>
>  * on request
>    (via a lock button or menu, before you put it in your pocket)
>
>  * upon an automatic return-from-suspend
>    (e.g., a datebook alarm, incoming phone call, SMS, etc.)
>
>  * but *not* following a manual return-from-suspend
>
> Note that this concept of screen-lock is different from the 
> power-management concept of screen blanking. Screen LOCK should 
> probably occur more often, and is intended primarily to prevent 
> accidental user-interface manipulation while the touchscreen is 
> against the user's face, in the user's pocket, or otherwise subject to 
> spurious inputs. It is not intended to save power.
>
>