Display of system users: Selecting the face

Friedrich W. H. Kossebau Friedrich.W.H at kossebau.de
Thu Jul 7 02:22:53 BST 2005


as written for an enhanced display of system users I would like to reuse the 
user pictures shown by the display manager(s), also known as "face"s.

State of art:
At least KDM and GDM offer the option to display some faces along the system 
users. Such faces seem not to be part of the system user description in 
standards like POSIX. So the programmers of the dms obviously invented their 
own faces extensions and developed some quite complex configuration system 
for sources of faces.
There are two principle sources of faces: 
* one global, filled by the admin
* local ones, a file per user in his home directory. 
Which one to take is controlled (in KDM) by a setting with the following 
* AdminOnly: only take faces from global dir
* PreferAdmin: first look for a face in the global dir
* PreferUser (standard in GDM): first look for a face given by the user
* UserOnly: only take the face given by the user
If no face is found a default face will be used. 

Two picture sizes are supported:
* 48x48 icon: named $LOGINNAME.face.icon in global dir, .face.icon in $HOME
* 300x300 image: named $LOGINNAME.face in global dir, .icon in $HOME
Format should be anything loadable by Imlib and Qt, usually is jpg or png.
The small icon is used as user symbol. The image is "used only as a fallback 
and is scaled down, but in the future it might be displayed full-size in the 
logo area or a tooltip." (from kdebase/kdm/config.def)

Special support for systems with management by LDAP etc. is unknown to me.

1. Size:
For comparison other places where faces/avatars are in use:
* xfaces in news/mails, also 48x48
* KAddressbook: support for face pixmaps up to 140x140
* Blogs, Bulletin boards:
  * phpBB: 81x81
  * kde-look.org: 50x50
  * others: up to 100x100 or above
So there seems not be to be some broader standard for the typical size of a 
face. As the faces are about to be used like icons the typical sizes from 22 
to 128 should be supported. This could be done by downscaling from one given 
picture with the largest size needed, like 140x140 or 300x300. No idea 
whether other image ratios than 1:1 have use cases and should be standarized.

2. Source of faces:
Enabling users to provide their own face as a file in their home dir works 
with display managers. They usually are run with superuser rights (or have 
some helper demons which are), so they can access all files. But with plain 
applications run by other users this can fail, depending on the rights. To 
circumvent this a special demon would be needed, which is suboptimal.

3. Type of faces:
Both (cropped) photographs and symbolic icons (pixel and vector) seem to be 
popular as user symbols. So both should be supported. While photographs have 
to be scaled anyway symbolic icons might be used prerendered for better 
quality, where possible.

4. Public/Private faces:
Displayed faces can have different publicity. Those on login/lock screens are 
possibly viewed by more people than those used in one's normal apps. 
Customization is one strength of Free Software so the demand can be perceived 
to enable each user to use his personal faces for the other users (perhaps 
even displayed names?)*. If private faces are enabled it has to be made sure 
they are not shown in public displays. Since some public visible displays are 
run by plain user's (e.g. the lock screen) this has to be reflected in the 
api for faces.

* E.g. by taking them from the address book. But might this put danger on 
security? What if someone manipulated one's addressbook and therefore the 
system displays the wrong person?

1. Admin only faces:
For a start only faces installed by the admin should be used. Per user 
customizations with private faces etc. should be delayed until security 
related problems have been cleared out. 
User given faces might be used if the files are readable to other user and 
allowed to be used. In fact we rip out the controlling of faces from the 
display manager and plant it to the user management (there are other things 
that should follow BTW).

2. Fallback icons:
For users with no own face two fallback faces are used: First the one of the 
primary group the user is in (e.g. users), if none is found, then a global 
one. So in opposite to the dm schemes there is an additional fallback icon 
per primary group.

3. Size: 
For a start the sizes and types used by the display managers should be 
overtaken. In the long run it might get some rethinking.

4. API:
For consistency the face loading should be designed along KIcon* classes. Some 
convenience functions with KUser might be liked, too. The experimental face 
using implementations I did proposed the following API to be a good start:

// size 0 results in original size/group default
// policy left out for now
class KUserFaceLoader { // singleton

  QImage loadFace(const KUser &user, int size = 0,
    KUserFaceLoader::Policy policy = KUserFaceLoader::Private*/);
  QPixmap loadFaceIcon(const KUser &user, 
    KIcon::Group group, int size = 0, int state = KIcon::DefaultState/*,
    KUserFaceLoader::Policy policy = KUserFaceLoader::Private*/);

  QIconSet loadFaceIconSet(const KUser &user, 
    KIcon::Group group, int size = 0/*, 
    KUserFaceLoader::Policy policy = KUserFaceLoader::Private*/);

class KUser  {
  QImage face(int size = 0/*, 
    KUserFaceLoader::Policy policy = KUserFaceLoader::Private*/) const;

  QPixmap faceIcon(KIcon::Group group,
    int size = 0, int state = KIcon::DefaultState/*,
    KUserFaceLoader::Policy policy = KUserFaceLoader::Private*/) const;

  QIconSet faceIconSet( KIcon::Group group, 
    int size = 0/*, 
    KUserFaceLoader::Policy policy = KUserFaceLoader::Private*/) const;

5. Support for LDAP etc.:
I don't know how faces might be supported by LDAP/SMB/etc. managed systems but 
the backend should transparently use it if available. Implementation details 
will surely arrive, once the basic infrastructure is done.

Waiting for your comments/suggestions, please :)


More information about the kde-core-devel mailing list