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: Only one image/photo will be visible on the screen. That one image will be rendered occupying a large part of the screen, thus making it very easy to hit it with the mouse-pointer (or a finger on a touch-screen).
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
Design
You can have subsections that better describe specific parts of the issue.
Implementation
This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:
UI Changes
Should cover changes required to the UI, or specific UI that is required to implement this
Code Changes
Code changes should include an overview of what needs to change, and in some cases even the specific details.
Migration
Include:
- data migration, if any
- redirects from old URLs to new ones, if any
- how users will be pointed to the new way of doing things, if necessary.
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
Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.
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