NOTE: This page is part of the Ubuntu Specification process. Please check the status and details in Launchpad before editing. If the spec is Approved then you should contact the Assignee, or another knowledgeable person, before making changes.
Launchpad entry: https://launchpad.net/distros/ubuntu/+spec/feisty-login
See also: UnifiedLoginUnlock
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.
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).
- A family with mum, 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).
This affects gdm obviously. Will likely introduce a new dependency of gtkglext to gdm.
- Get AIGLX/GL-based rendering working in the gdm's face-browser window.
- Add a GL-widget (via gtkglext) for displaying each users face/photo as texture on a GL-primitive (e.g. quad).
- User selection should either happen by hovering or clicking on a users photo.
- 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.
Use "load on demand" of photos/textures in cases when you have a really huge amount of users (> 100).
- The face-browser has to scale well with 100 user-photos or more.
- The face-browser has to fallback to the old existing code for non-AIGLX systems gracefully.
- 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.
- 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.
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)
These are mockups of how it should look in general:
Data preservation and migration
There are no issues affecting data preservation and migration.
- Is a face-browser really a security-issue for public installations (e.g. at companies)?
Accessibility issues have not been covered yet. See the AccessGDM spec
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 AccessGDM spec for details and use cases. -- HenrikOmma
Also in large organizations, etc, you need to worry about how this scales with number of logins. A university CS dept could have hundreds of students with access to a particular set of machines. A univeristy wide public lab could have thousands. Not only does this need to scale well performance wise, but usability wise as well. Probably the easiest / fastest way to address this is to make sure sysadmins can still disable the FaceBrowser, without adverse effects elsewhere in Ubuntu (ie removing ubuntu-desktop). --Justin Dugger
Could this be achieved by the two packages (new fancy greeter and old standard one) both providing the same "Provided packages". Also, they could conflict with each other to make them mutually exclusive. --MattRussell
In desktop installation there will be just some way to don't install opengl eyecandy, right? i am concerned with those that still uses an onboard video card in a relatively slow computer (microsoft don't cares about those, but we can do better!) (ps: actually the idea is very nice -- but only to people that has 3d acceleration! --EliasAmaral
- This should not be enabled by default but be available through the "Login Window" configuration menu. Mostly all users migrating to ubuntu can figure this out and enable it. This would take care of the problem with scalability and the business scenario and any possible security issues since admin password is required to change. -- Abbas Khan
- Many corporate environments disable showing the username of the last person logged in as this gives people some information they would need to gain unauthorised access to the system. By presenting the username you are giving the user part of the token they need to "hack" the desktop/laptop.