FaceBrowserLogin

Revision 10 as of 2006-11-07 13:33:01

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

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)?
  • How well scales the loading and creation of, e.g. 100, user-photos?
  • What should the face-browser look like on non-AIGLX systems (fallback)?
  • Should the fallback just use the existing code of gdm's current face-browser?
  • Accessibility issues have not been covered yet.

BoF agenda and discussion

Here follows a quick cutNpaste from the meeting at USD. This will be cleaned up today...

Face browser vs. name/password fields

  • A big company with many users. Each person has his own photo. Maybe flick through pages of users?
    • -- Mixed mode: face browser show only recents users and permit write in textbox other users name
  • Face browser useful only for small groups of people, e.g. family.
    • -- Obvious solution: show face browser when number of users < limit and not otherwise -- Problem can possible be solved for many users with autocomplete on username field

Login effects

Goal: Reduce the number of transitions

  • Currently too many
  • Leave the login screen there for a while after login, to reduce the perceived delay (maybe add something so we can see we are currently loging in, like the firefox page loading logo)
  • Login session and session on different X servers? [consistent-login spec]
    • - Every user's session needs to run on a different X server - login window should not have its own X server (nothing Xgl-ish again) - therefore switching users requires two X server switches, argh - X server switches are anti-blingy.
  • Modify gdm-theme
    • ability to create a canvas and define transition effects
    • gdm theme defined using SVG
    • SVG+DOM for animations? (rsvg still doesn't do DOM yet)

Easy to achieve effects:

Add support for GL animations in gnome-session, so the time after login can have interesting stuff

  • If background for login window is the same as the default background for the desktop, that makes transitions easier
    • otherwise fade from one to the other
    • if an X server transition is required, maybe fade to black instead?
  • gdm themes are currently a weak programming language
    • Why not replace it by a more powerful programming language?
      • Allow the background to be animated, by giving complete control to a separate function or process? Composite the regular gdm theme on top of it, with transparency or shadows?
      • For extra points, allow gdm to provide ongoing data to the "animation theme", with information such as the position of UI elements (such as the username entry box, so it can move its stuff out of the way) or the current mouse position (for playful follows-mouse stuff)
  • Slow, subtle changes in background of login window?
    • This might be annoying in a lab full of machines.
    • Needs simple compositing manager in gdm
      • -- Probably not, since GDM is the only process running, it can do compositing on its own
    • Currently using gnome-canvas (port to goocanvas API/drawing-model might be scary.)]
      • Needs to support aRGB?
    • Needs compositing manager in GDM (Fun work for Mirco?) maybe needed, not sure
    • Needs OpenGL support in GDM. (Mirco plans to hack on this?) absolutely
    • Is it possible to have GDM retain the root window until nautilus starts and takes over ([http://bugzilla.gnome.org/show_bug.cgi?id=355190 desrt has a patch])

      • This also allows determinate login process to be shown in the login window
    • Security considerations: If GDM (running as root) can be made to display user-selected images, that might turn a buffer overflow in an image library into a local user privilege-escalation attack (Can we run gdm as a user, not as root, and only use root for some part of the actions (like with a sudo or something like this) )? Probably difficult to do securely, since GDM decides who gets to login. It's sort of like saying that sudo should run as a user process and another root process to actually raise privileges
    • Another security consideration, running another process while GDM is running *might* allow it to steal keystrokes
  • Artists, where are you?
  • Support for the logging-in session to notify the greeter of its progress:
    • The greeter screen sets a property ("_GDM_GREETER_WINDOW") on the root window
      • with its XID.
    • gnome-session (or some other process in the session) finds the greeter window
      • by this mechanism.
    • gnome-session then sets the propery of the same name on the greeter window to
      • be a login progress indication (from 0 to 0xffff).
    • the bling uses this information to somehow let the user know. currently, it
      • is just a progress bar....

Comments

  • Let's combine the face browser with an input box for the user name. So the list of pictures gets filtered while a user name is entered. Makes the selection in an environment with many users a charm. --AndreRuediger

  • I think in terms of usability it's also important to have a login button. So newbies don't have to search for it for 5 minutes before realising that they just have to press Enter. --AndreRuediger