Display of system users: Selecting the face

Friedrich W. H. Kossebau Friedrich.W.H at kossebau.de
Thu Jul 7 17:16:39 BST 2005

Hi Oswald, :)

Am Donnerstag, 7. Juli 2005 11:58, schrieb Oswald Buddenhagen:
> On Thu, Jul 07, 2005 at 03:22:53AM +0200, Friedrich W. H. Kossebau wrote:
> > This could be done by downscaling from one given picture with the
> > largest size needed, like 140x140 or 300x300.
> no way this is going to work:
> - slow. oh, well, on-demand loading would help - hmm, actually, the user
>   list should do this anyway.

Another (additional) solution would be to do the scaling once (when adding the 
face) and save the results to disc. 

> - downscaling a big image by such a factor makes it almost certainly
>   unrecognizable

Well, tiny images are always close to unrecognizable if they don't have simple 
shapes. Still it helps to identify an item (see attached image, faces from 
planetkde, scaled to 16x16). 

So I see this working. Upscaling an image gives uglier results than 
downscaling, that is why I propose to take the largest size (for photos) as 

> > 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.
> while kdm currently has code that setuids to the owner of the image, a
> comment (i mean, _a comment_ - in _my_ code!! :) clearly indicates that it
> is supposed to run as nobody. actually, i could/should change this right
> away - no need for the entire greeter to run as nobody for this.
> ergo, inaccessible image -> no image - without exceptions

I do not really get what you say here? Go with nobody or don't?

> > * E.g. by taking them from the address book.
> that's no option for kdm anyway as long as there is no desktop-agnostic
> address book standard.

Well, actually there is, see the GECOS field in posix-style accounts ;) Sadly 
POSIX misses user pictures AFAIK, so you had to add them.

For public visible displays simply addressbooks won't be usable. For apps run 
as superuser, nobody or the like this feature won't be available, for other 
apps it has to be cared for in the code (special KUserFaceLoader constructor)

> > But might this put danger on security? What if someone manipulated
> > one's addressbook and therefore the system displays the wrong person?
> you can do this with the .faces as well. that's one of the reasons why
> the *Admin* variants still exist.

Okay. So we could allow users to set up their own set of faces and names for 
the other users and enable the admin to outkiosk that, then. 

> > 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
> yes, but consider the distinction between the *Admin* and *User*
> variants.

Sure. While I miss to see the need for UserOnly ;)

> > 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),
> eek, yet another variant ...
> where to store this image? 

Like the .default.face.icon, along with the face images. Needs prefixes to 
separate from user faces, perhaps "." or "@". Or in some parallel directory, 
perhaps called "groupfaces". 

> who is allowed to change it?

The one who is able to change faces, no?

> > 5. Support for LDAP etc.:
> danimo wanted to force me into adding this ages ago, but without success
> so far. :))))

Great, so I know whom to ask for alliances ;)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: SmallFaces.png
Type: image/png
Size: 9586 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050707/32d8c08d/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050707/32d8c08d/attachment.sig>

More information about the kde-core-devel mailing list