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

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



On Tue, 21 Feb 2006 16:45:26 +0000 Aleksej Struk <astruk@gmail.com> babbled:

>   Hello raster,
> 
>   Thanks for a great tutorial how to implement a desktop locking
>   windows. However, it is already exists. It was really easy!.
>   Moreover I learned edje interfaces as well. :)

:)

>   Now I have the following question. First of all I decided to
>   create a possibility to set a personilized desktop locking password.
>   However, I want to implement it through a config dialog. I want
>   to put some options in this dialog that will allow to enter the
>   password. Since, everybody would like to have this passwd permanent,
>   I thinkg to store int inside E configuration. More precisely in 
>   e_config datastructure.
> 
>   How I understand, I have to insert a new field into this
>   structure(e_config.h). Moreover, as I remmember, after changing the
>   config structure, E required to redo my desktop config, since the
>   version of configuration file was increased.
> 
>   My question is : if I insert new data fields into config, should I 
>   increase a version number of config ? or I can leave everything
>   as it is ?

that depends. by default if you add new fields, the old config will have nothing about this in it. it will default to 0, or NULL. if this is a safe/useful/normal value for the config value you do not need to increase the config file version. if the config value NEEDS to have some sane value to work, then you do need to increase the version. the idea is that during development we will be playing with the config all the time - and we simply dump old config if its incompatible. in between releases 0.17.0 - 0.17.1, 0.17 -> 0.18 etc.) we will KNOW what fields have been added between the old config revision and the current one and thus can sanely fill in the missing fields and thus "upgrade" the users config transparently. there is no need to add such code during development as it simple makes the code bigger, longer and harder to manage.

>   Second, after I finish with personal desktop lock password I will step
>   to sys wide auth through the pam. However my idea is to have both

for now its looking good. i suggest cleaning up the config though. personally i don't think setting the desklock bg is that useful and it complicates the config dialog a lot. (as desklock is mostly active when you are not AT the machine - does it really matter much? and by the time u wandered away long enough the screen will have blanked and you won't see it anyway). anyway - i'm dubious if the code and maintenance and fixing etc. is worth it atm. ( i need to revamp the whole bg selecting thing so its centralised in 1 place and not copy & pasted around). also i think i need to add separators/headers to ilist to partition/segment the lists.

>   auth possibilities. However, I think to introduce some sort of
>   auth precedence. So, if the personal passwd is set, then  pam is not
>   used. And vice versa, if personal passwd is not set, then pam will be
>   used.

sure. that make sense. the hardest bit is all the pam build, detect, etc. etc. etc. code.

>   regards,
>   aleksej
> 
>  
> // 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).
> 


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