[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [E-devel] discussion: desktop lock functionality

On Fri, 17 Feb 2006 15:47:12 +0000 Aleksej Struk <astruk@gmail.com> babbled:

> Hi all,
> I think of starting a new app/module for e17. Actually, I want to
> write a desktop lock app/module. However, I still do not know what to
> start from and what functionality to implement.
> My idea is to have a separate program, like KDE does, which will lock
> the desktop. I think that it should behave as follows :
> 1. Create a new fullscreen window.
> 2. Disable all keybindings.
> 3. Disable all mouse bindings.
> 4. disable window menu.
> 5. disable a possibility to switch desktop
> 6. something else...
> Unfortunately I do not know how to implement desktop locking and what to
> start from. Actually I tried to investigate xlock program, but I a
> little bit confused with it. If somebody knows something about desktop
> locking,or can provide some refs to documentation, please write me.

NB: this is from the view of doing an e17 module.

you can create a fullscreen window using e_popup and then just fill it with
some edje object. check the e_popup.h for api. you can create an input only
window and grab the mouse and keyboard to that window alone - this way you have
taken control of all input devices and sent their input to a particular window
(see e_exebuf.c or e_winlist.c for examples). they both do this trick and ONLY
process keybindings selectively themseleves, if they desire. now u have stolen
they keybo9ard and mouse, overlayed the screen with a big popup (just use a
very high layer like 10000 for the popup layer) so you can't see anything
(remember - you probably want to go thru the list of all managers, then each
container per manager, then each zone per container (each of these list their
sub-components so u can just walk this list easily), you want to create a popup
PER zone that exists and maybe only put a "blank" or "disabled" object on all
zones except 1 where you will accept some unlock mechanism (for now i suggest
you just put a button u press and wait for a signal from teh edje object when
the thing is unlocked, also just handle the Escape key to abort)). now u have
the basics of snarfing control of the screen - ALL screens (dont forget that -
there may be multiple managers, multilple containers per manager and multiple
zones per container), you have the NEXT stage - how do you unlock? well - u
need a way to accept some authorization. youc an do this 2 ways. 1. traditional
password entry - you will need a working entry box (in fact you can just do
this yourself with key down events - see e_exebuf.c for an example) and just
display "*" chars instead of what was actually typed (for texting you are going
to want to see the thigns u type though). now u have a password - you will need
to authenticate this using pam - this is where the nastiness comes in - dealing
with pam. see entrance code :) 2. DIY userspace. don't use the users password
but implement another system - the user can set a SPECIAL unlock password or
pin # e stores it in its own files and just matches it. its much simpler than
pam - and you will need a way for the user to SET it - but maybe this would be
a good first cut (just open ~/.elockpw file thats a text file with your
unlock/lock password).

> regards
> aleksej
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@rasterman.com
Tokyo, Japan (東京 日本)