GdmFaceBrowser
Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.
Launchpad Entry: hardy-gdm
Packages affected: gdm
Summary
- Discuss and agree changes to our default greeter.
- Input from hardy-theme discussion
- Default should be a Face Browser, allowing users to click on
- their name
- Show face and/or name?
- Threshold for falling back to non-face greeter
- Implementation of face browser
- OK button on gdm non-face greeter (people don't think they can
- just hit ENTER)
- Username field alternative (hidden maybe?) on face browser,
- start typing and it appears
- "About Me" (eds) information?
- Session information (number of apps running, mails, etc.)
- remember "screensaver-mode" of face-browser after x minutes of inactivity
Release Note
The default layout of the gdm-greeter uses an OpenGL-based face-browser, if the underlying graphics-hardware and driver provide the needed support, in order to provide a more pleasing login-experience. User-selection happens either by clicking on a users image/photo/face or via text-entry.
Rationale
These days, with composited desktop-environments becoming more and more a standard feature, people expect their whole computing experience to be visually attractive and consistent across all parts of the system. Furthermore do we want to close the gap of visual attractiveness in the different parts of the overall desktop-experience (booting, login, desktop-usage, logout). Ideally the user should no recognize any kind of "gap" when using the computer. This attention to detail in terms of consistent look and behaviour helps give the user a more enjoyable desktop-system and improves a users confidence in the platform s/he is using.
Use Cases
The general advantage of a face-browser for login is the avoidance of superfluous typing. This helps speed up the login-procedure of all people, who are no touch-typists or experienced keyboard users. But even experienced users can enjoy the convenience of being lazy occasionally. It is still possible to login successfully without selecting an image at all just by typing in the login-name and password.
only one user on system: Since there is only one user (read: one real person, not a "user" in terms of unix-privileges) on the system, booting up the computer will automatically log that particular use in without asking for a password. Thus also not presenting the gdm-greeter/face-browser to the user. Only when the user logs out explicitly, s/he will be presented with the gdm-greeter/face-browser. This automatic login-upon-bootup can be disabled via gdm-setup.
multiple users on system (<=100): In this case a user can either just select her/his image to tell the computer their login-name or start typing the first few characters from her/his login-name and watch the face-browser filter the set of displayed images to fewer images in order to simplify locating their own image in the visible set of images.
multiple users on system (>100): Scalability-issues regarding texture-usage (especially on low-end graphics hardware) and network-latency (setups with that many users are hardly run of local harddisks) demand a fallback to a non-face-browser mode of the gdm-greeter. In that case plain text-entry widgets for login-name and password are used.
The threshold of a 100 users for automatic disabling the face-browser is something that needs to be properly tested during the beta-phase.
Assumptions
For the face-browser the following OpenGL-extensions will be required:
- rectangluar textures (GL_TEXTURE_RECTANGLE_ARB)
- fragment-shaders (GL_FRAGMENT_PROGRAM_ARB)
We currently assume that the newly rewritten gdm will be in a shippable state by the time HardyHeron enters beta. Should we forsee that this will not be the case, we will fallback to the old gdm and add the face-browser to the old version.
Design
The main workload for this spec will come from the OpenGL-based face-browser. There are currently two potential candidates for becoming the rendering library of choice, [https://code.fluendo.com/pigment/trac pigment] and [http://clutter-project.org clutter]. At the time of this writing both lack direct support for implicit-animations and shaders. These two features will have to be added to the API of choice, once that choice has been made. Going down that path will involve a lot of additional design-discussions and work not directly related to this spec.
There is another option for providing the needed OpenGL-boilerplate. That would be to use libgtkglext as windowing-system glue and implement all needed animation- and effects-features from scratch directly via OpenGL.
Theme-support was based on a XML-file in the old gdm. This should be taken over to the new gdm.
Implementation
This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:
Migration
Any theme and gdm-setup setting should just work with the new gdm.
During the installation of Ubuntu on a computer the user should be asked for a photo upon creation of the first account. This can either happen by offering the user a set of stock images, allow loading an image-file from an external data-source e.g. an usb-stick or web-page, take a picture with an application like [http://www.gnome.org/projects/cheese cheese] (if a supported webcam is found) or allow the user to create an abstract avatar-photo using a program like [https://edge.launchpad.net/memaker MeMaker]. All this of course requires a lot of additional integration work that easily exceeds the scope of this spec. It would require ubiquity, Ubuntu's installer tool, to be extended with support for cheese and MeMaker.
Test/Demo Plan
It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during CD testing, and to show off after release.
This need not be added or completed until the specification is nearing beta.
Outstanding Issues
This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.
BoF agenda and discussion
Suggestions:
- Add an option in GDM to disable the login sound (very useful when working in libraries)
Enable password-less connexions (i.e. users have a password but allow GDM to connect locally without using it)? Another feature we really need for home computers.KDM already has it, I opened a bug on GDM but it is really not active: http://bugzilla.gnome.org/show_bug.cgi?id=414862 Could there be a discussion about that? IMHO, it is essential. - Milan71
- Support pulling faces from LDAP jpegPhoto attribute
About the single user case autologin: This opens a security hole by default; it is not because you're alone on your machine that you don't need a password out of the box, the contrary would more likely be true. What about automatically starting the session but locking the screen, so the computer is immediately ready like when you return from hibernate? This would avoid all disturbances. This was discussed here https://answers.launchpad.net/ubuntu/+question/4443 and here http://bugzilla.gnome.org/show_bug.cgi?id=448345 with solutions.