FaceBrowserLogin

Revision 17 as of 2006-11-11 00:14:39

Clear message

Summary

In order to extend the embellishment of the visual experience for a user early on, make use of GL-accelerated transitions in the face-browser of gdm. Aside from just providing bling-ified looks, the handling of the face-browser in gdm should scale nicely on installations with many users.

Rationale

On a computer capable of running the OpenGL-based compositing/window-managers (e.g. compiz) the visual feel of the system should be consistent. There should be no conceived "visual gap" (effects-wise) between the login-window and the normal desktop-session. As with all things bling, a systems that looks good (right from the start... at login) is more fun to use. It also helps to increase the "me too"-factor of any possible bystanders early on. The face-browser only really makes sense for systems used mainly be people who are too lazy to type (or at least try to avoid to type as much as possible), are generally very bling-fond or cannot remember their login-name (hopefully they are able to recall their accounts password).

Use cases

  • A family with mom, dad, daughter and son (all non-technical people who like to just look, point and click instead of read text) share a single computer. Each of them has a photo setup for their user-account. They are lazy and want to avoid typing text as much as possible. The face-browser allows them to just point at their photo on the login-screen and the password-entry widget changes accordingly requesting them to enter the password for the user the mouse is currently pointing at.
  • A company has many employees and offers them to login at any workstation in the offices. An enabled face-browser would allow quick identification of the employee wanting to login. Seeing the photos of their fellow co-workers is a way to make the working environment get a more personal and human touch (bit of soap-box I admit).

Scope

This affects gdm obviously. Will likely introduce a new dependency of gtkglext to gdm.

Design

  1. Get AIGLX/GL-based rendering working in the gdm's face-browser window.
  2. Add a GL-widget (via gtkglext) for displaying each users face/photo as texture on a GL-primitive (e.g. quad).
  3. User selection should either happen by hovering or clicking on a users photo.
  4. Should the number of photos (threshold e.g. 9) not fit on the screen, moving the mouse to the left/right of the stack of photos should gradually scroll the stack to the left/right revealing additional user photos.
  5. Use "load on demand" of photos/textures in cases when you have a really huge amount of users (> 100).

  6. The face-browser has to scale well with 100 user-photos or more.
  7. The face-browser has to fallback to the old existing code for non-AIGLX systems gracefully.
  8. The face-browser will need to be connected to the input-box for the user-name. Thus the list of pictures gets filtered, while the user enters his/her name. Optionally for more bling the face-browser just can scroll very fast to the first matching photo.
  9. A normal "Login"-button will need to be provided so users, not knowing that just hitting the return-key will continue the login-process, have a visual clue on how to proceed once they fully entered their name.
  10. To preserve the most consistent look and feel with SlickBoot and usplash the art-resources from those packages have to be used in the same way. This will make the transition from the usplash-screen to the face-browser/gdm-screen as smooth as possible. (The next more refined mockup will take this into account)

This is a quick mockup of how it may look in general:

[http://macslow.thepimp.net/shots/face-browser-mockup.png http://macslow.thepimp.net/shots/small_face-browser-mockup.png]

Implementation

tba

Data preservation and migration

There are no issues affecting data preservation and migration.

Unresolved issues

  • Is a face-browser really a security-issue for public installations (e.g. at companies)?
  • Accessibility issues have not been covered yet. See the [:Accessibility/Specs/AccessGDM:AccessGDM spec]

Comments

  • Remember to keep an eye on this https://launchpad.net/distros/ubuntu/+spec/consistent-login-screen for consistency across screen/mode changes.

  • In large organisations and public terminals you also have to cater to disabled users. A user needs to be able to activate assistive technology features with a standard keyboard or mouse gesture. See the [:Accessibility/Specs/AccessGDM:AccessGDM spec] for details and use cases. -- HenrikOmma