GNOME Bugzilla – Bug 550704
Volume Icons Should Fall Back to drive-harddisk
Last modified: 2011-03-31 19:44:22 UTC
Currently, if the GIcon determined for a volume is a GThemedIcon and references an icon which is not available in any theme in the currently selected hierarchy, and no fall back icons are either, the ugly old curled paper gets used. For volumes, we should be falling back to the drive-harddisk icon. The attached patch adds checks in the several areas where this happens, and falls back to the drive-harddisk icon.
Created attachment 117949 [details] [review] Patch to fall back to drive-harddisk for volume icons
Confirming and setting 2.24 target. this is really ugly when it happens.
> For volumes, we should be falling back to the drive-harddisk icon. A quick test revealed that for a CD-ROM medium, the following icons are used: media-optical-cd-r, media-optical-cd, media-optical, media So shouldn't it be enough to design a “media” icon as a generic volume fallback, and a “drive” icon as a generic drive fallback [cf. drive-harddisk-usb]? You can check out the icon names for all drives and mounted volumes using gvfs-mount -l -i
(In reply to comment #3) > > For volumes, we should be falling back to the drive-harddisk icon. > > A quick test revealed that for a CD-ROM medium, the following icons are used: > media-optical-cd-r, media-optical-cd, media-optical, media > > So shouldn't it be enough to design a “media” icon as a generic volume > fallback, and a “drive” icon as a generic drive fallback [cf. > drive-harddisk-usb]? No. The "media" icon should never be looked up. If "media-optical" isn't found, then there's a problem in the icon theme. However, nautilus may also not be aware of the media type of the drive, and so falling back to media-whatever may not be possible either. Currently, this really will almost never happen. However, with the patch I sent to gvfs-list last week, this may happen more often. http://mail.gnome.org/archives/gvfs-list/2008-August/msg00007.html For example, if the metadata file has Icon=golgotha, and none of the themes in the currently selected theme hierarchy has the icon, we end up with the curled paper. This patch resolves that problem by falling back to "drive-harddisk" instead. Optimally, we would want to fall back to the appropriate media type icons, but I think there should be some refactoring in the nautilus code first, and we need to be able to actually determine the drive/media type in nautilus somehow. Until then, I think my patch is a sufficient bandage over the wound.
Can I commit this to SVN?
This should probably use nautilus_icon_info_is_fallback(), which Alex added recently, instead of manually poking at the GtkIconTheme.
Wow, that's a lot of copy and paste code that looks nightmarish to maintain. Isn't there a better / more proper way to do this? Can't you implement your function once in some library and call it elsewhere?
Is this still valid, I just took a look at the places sidebar and they're using g_mount_get_icon().
Reopening then.
This should never happen in 3.0.