Icon names vs. emblems

[Matthias Clasen]

It turns out that it is desirable to be able to specify icon+emblem
combinations in many places. E.g. when returning icons for disks, a
backend may want to return a harddisk icon with a padlock emblem to
represent an encrypted harddisk.

This could certainly solved with a drive-harddisk-encrypted-locked
icon in this instance, but there are diverse other devices that might be
encrypted, leaving us with a plethora of <device>-encrypted-locked
icons (and also <device>-encrypted-unlocked, and other variants).

One intriguing possibility to solve this is to use some kind of escape
in icon names, and do something like 

  drive-harddisk+encrypted-locked

which is currently not an allowed icon name (since the + is not allowed
in icon-naming-spec-compliant icon names). It would be interpreted as 

  If you can't find an icon for drive-harddisk+encrypted-locked, 
  find the drive-harddisk icon and combine it with the 
  emblem-encrypted-locked emblem. 

This has the advantage that it nicely interacts with fallback (ie if the
specific icons are missing, you may still get the drive icon with the
encrypted emblem), and allows themes to provide pre-composed icon/emblem
combinations. 

If people think this is a good idea, here is patch that adds suitable
language to the icon naming spec (the patch is against 0.8, since I
couldn't find the source repository for the latest spec...).


Matthias

-------------- next part --------------
A non-text attachment was scrubbed...
Name: naming-spec.patch
Type: text/x-patch
Size: 1522 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20080616/74b24c35/attachment.bin