Re: [E-devel] discussion: desktop lock functionality
On Tue, 21 Feb 2006 16:45:26 + Aleksej Struk [EMAIL PROTECTED] 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 1 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
Re: [E-devel] discussion: desktop lock functionality
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 ? 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 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. 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 1 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). --- 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=lnkkid=103432bid=230486dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] discussion: desktop lock functionality
On 2/21/06, Aleksej Struk [EMAIL PROTECTED] wrote: 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 ? 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 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. 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 1 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). --- 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=lnkkid=103432bid=230486dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel Doesn't it need to implement too XScreenSaver extension into ecore ? -- Beber [EMAIL PROTECTED] --- 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=lnkkid3432bid#0486dat1642
[E-devel] discussion: desktop lock functionality
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. 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=lnkkid=103432bid=230486dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] discussion: desktop lock functionality
On Fri, 17 Feb 2006 15:47:12 + Aleksej Struk [EMAIL PROTECTED] 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 1 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=lnkkid=103432bid=230486dat=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)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) --- 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=lnkkid=103432bid=230486dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
