Re: icon naming spec and gnome-vfs

[David Zeuthen <david fubar dk>]

On Mon, 2006-07-31 at 18:06 -0400, Rodney Dawes wrote:
> On Sat, 2006-07-29 at 21:32 -0400, David Zeuthen wrote:
> > I found something in fd.o CVS so here's a patch for what we need in the
> > spec. Please apply and/or comment - I had to make some decisions on
> > inheritance which I think are sane but others may disagree.
> 
> As I've said many times in different forums, the Icon Naming spec is not
> intended as a canonical list of icon names for use in the desktops. It
> is a base specification upon which the desktops may build other specs if
> desired, and may build additional icon names from them.

So you want GNOME and KDE to both individually come up with the icon
name for e.g "Compact Flash media" because... you don't want that kind
of detail in the spec? That's broken.

> > Also, looking at gnome-icon-utils I see that you deleted a bunch of
> > icons. That's bad, I wish you had looked at the gnome-vfs code on how we
> > do the icons. Then we could have avoided this rush. Anyho, to avoid
> > regressions in gnome-vfs with gnome-icon-theme [1] I estimate that we
> > need the following icons, all mentioned in the attached patch
> 
> I did look at the list of icons in that code. And there are an
> astonishing number of duplicates, and icons where the difference between
> the generic icon, and the specific icon, were minimal. 

Yes, some artists and designers only gently hint the fact that e.g. a
hard disk is connected via USB. I think that's a well-known methodology
in design. I'm not an expert on the subject though.

> Although, this
> also goes along with the fact that the spec is not meant to be a
> canonical repository of names.

The spec could be smart about it. I see no reason why the spec shouldn't
be useful and say e.g.

Name:    drive-harddisk
Meaning: The icon used for a connected hard disk
Notes:   Connection-specific icons are suffixed by connection type.
         Defined bus types: usb, 1394, ata, sata, ...

if your worry is the size of the spec. It might be a bad idea because it
makes the spec harder to read.

The last thing we want is for the desktops to come up with e.g.
media-removable-kompaktflash and media-removable-gnompactflash because
the icon-naming-theme maintainer is too stubborn to add these to the
spec. That would be broken.

> >  - drive-harddisk-usb
> >  - drive-harddisk-1394
> >  - drive-removable-media-usb (could be the same as drive-harddisk-usb)
> >  - drive-removable-media-1394 (could be the same as drive-harddisk-1394)
> >  - media-harddisk [2]
> >  - media-harddisk-usb
> >  - media-harddisk-1394
> 
> The USB/IEEE1394/etc... stuff is in the spec, actually. Not explicitly,
> but the method for falling back from specific to generic icons, is most
> certainly in the spec. 

So it's OK that the KDE programmer writes "drive-harddisk-firewire" and
the GNOME programmer writes "drive-harddisk-1394"? Of course not, that's
broken, why are you opposed to having this in the icon-naming-spec?

<snip>

> OK. So, redundancy is exactly what we want to avoid in naming things.
> We also want to be verbose in naming, unless there is sufficient reason
> not to. So using "mcard" as an abbreviation is something we shouldn't
> do. 

OK, minor thing, noted.

> As I mentioned, there is a bug on bugs.fd.o requesting flash media
> to be in the spec in some manner. There was also a related thread on the
> XDG list about it. Both of these have died down, and I don't feel any
> consensus was reached on what to call these. It would be nice to have
> this thread started up again, so we can come to some consensus and get
> these names ironed out.

OK.

> > There may be more; I know when things are in the spec and I can write
> > the patch to gnome-vfs. Thanks for looking into this.
> 
> I think I said this in my other reply to your previous mail, but the
> code is going to need changes beyond simply changing the icon names in
> use, to Do The Right Thing (TM). The code should be handling fallbacks
> if an icon doesn't exist in the theme, not the theme itself.

Ideally GtkIconTheme would do this for you in GNOME. Or did you think of
something else?

> I will fix the inappropriate symlinks tomorrow. These links have been
> this way since the incarnation of icon-naming-utils, and this is the
> first that anyone's complained about them. But looking at it now, after
> you pointed them out, it makes sense to link them to something else.

OK, sounds good. Since you are adamant about having agreement in the
spec you probably want to provide icons with that name.

> > [2] : I have no idea how you think that we could get by without this -
> > gnome-vfs, after much debate, indeed shows the user the distinction
> > between mounted and unmounted media. That's what I call "available
> > media" in the spec. Yes, it kinda sucks, but that's UNIX for you.
> 
> A hard disk is both the media and the drive, always. Even if it is
> unmounted, it's still the same thing. I don't feel we need a special
> case icon for hard drives to differentiate between mounted/unmounted.
> The system is supposed to seamlessly mount the disk and open the root
> path on the partition, when the user clicks on it anyway, no? The only
> issue is when the user doesn't have permission to mount the disk. In
> this case, I think we should know before-hand if the user can mount the
> partition, and if not, add an emblem to the disk showing they can't
> access it, and perhaps popping up the root password auth dialog, if they
> try to mount/access it, rather than just popping up an error saying that
> they can't.

That's a pretty big change in GNOME VFS (that surely won't make 2.16)
and is probably best discussed on gnome-vfs-list in a new thread.

(for what's it worth I don't disagree with you and I think it's an
interesting idea worth exploring in the next release.)

    David