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

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 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).