Suggestion for name specification for extra drive and media icons
drzeus-list at drzeus.cx
Mon Jan 23 20:28:39 EET 2006
Rodney Dawes wrote:
> On Mon, 2006-01-23 at 17:52 +0100, Pierre Ossman wrote:
>> Shaun McCance wrote:
>>> Perhaps all the media-dvd-* types should fall back to
>>> media-dvd. This would allow people to have a generic
>>> DVD icon. If a media-dvd icon isn't provided, they
>>> would still end up falling back to media-cdrom.
>>> It would be rather silly to have a normal DVD show up
>>> with a special DVD icon, but to have a DVD+R show up
>>> with a normal CD icon.
>> Definitely. The problem with recursive fallbacks is the added complexity
>> to the applications that need to handle this. This would probably be
>> something that should be decided early so noone does an implementation
>> that wouldn't allow recursion.
> I suggest you read the Icon Naming Specification again, where it
> comments on the use of "-" as the word separator. The purpose of this is
> to make it easy for icon theme implementations to fall back recursively
> to a point, in cases where it makes sense, such as for device icons,
> where you have a large hierarchy of types. This is why the iPod icons in
> tango-icon-theme-extras are named the way they are.
Ah. I have to admit I didn't read through the spec that carefully.
Figured it was merely a list of names. As always, assumption is the
mother of all... :)
This would solve the issue for many things, but not all. E.g.
drive-removable-media-flash-smartmedia or media-cdrom-dvd-dvdrwminus
aren't that nice. The first would also create a conflict between the
drive (the "reader") and the actual media.
> For MIME types, we want to use the generic fallback specification stuff
> that Alex Larrson has been working on, by letting the MIME type XML
> files specify the fallbacks. This allows the MIME type icons to use the
> generic version in the user's theme, rather than specific versions that
> may exist in themes inherited from. I don't know if we want to do a
> database similar to the MIME types database, for device icons as well or
> not. We can probably just specify some fallbacks through HAL, and let
> the apps query it for what icon to use. HAL can then provide a list of
> icons like "drive-dvd-video,drive-dvd,drive-cdrom" to look for, and the
> implementation/application can fall back through the list, to the one
> that exists in the current theme, before falling back to specific ones
> in themes inherited from.
It would be nice if we could make a system that wouldn't require
something as complex as HAL. Going through HAL could be a way of having
one, central implementation. But having it defined as the required way
Perhaps all we need are a few more base icons upon which we can do
-more-specific-names. media-cdrom could be replaced with media-disc (as
in any optical disc media). A generic media-removable could be the base
for most other types.
More information about the xdg