GNOME Bugzilla – Bug 414073
Support info.icon_name HAL property to get icons
Last modified: 2018-08-17 13:44:54 UTC
The info.icon_name HAL property is being added to the HAL spec for providing device-specific icon names. The attached patch utilizes this property to get the icon name when looking up the icon to use for volumes. It does not break compatibility, and falls back to the existing code if the property does not exist. Can we please get this in before code freeze on Monday?
Created attachment 83778 [details] [review] Patch to utilize info.icon_name property if available
Commited.
Actually, thinking about it, this is not going to work until we have all the names defined in the icon-naming-spec. The reason is this: suppose someone installs a new version of HAL (or more likely, our hal-info package) that sets the info.icon_name property. Now gnome-vfs will pass the icon name obtained from HAL, e.g. "drive-harddisk-usb" to e.g. Nautilus but the user don't this icon in his theme. And how could he? We're not even sure yet the name is going to be "drive-harddisk-usb". I'm afraid this will have to wait until 1. The icon names are well defined in the icon-naming-spec 2. All the base icons are in gnome-icon-theme - e.g. drive-harddisk but not necessarily drive-harddisk-usb or other very specialized icons. 3. GTK+'s icon theming code supports fallbacks so if Nautilus asks for drive-harddisk-usb and this is not available it will fallback to drive-harddisk. Rodney, did you have a bug reference for this? We could fix this if gnome-vfs itself would check whether the icon exists and if not, fall back to the way we compute icon names today. This is not possible however as gnome-vfs-daemon don't link to GTK+. So this is just going to break. Suggest to revert the patch.
Btw, one reason this is important to address right now is that the "blessed HAL" dependency for GNOME 2.20 is most likely going to be either - HAL 0.5.9 + recent hal-info snapshot that got the magic for setting info.icon_name; or - HAL 0.5.9.1 (0.5.9 + code to set info.icon_name drives) + recent hal-info snaphot Of course, vendors may patch this in themselves but I know for sure this is going to break for e.g. Fedora 7 since that will ship HAL 0.5.9 + hal-info that will contain info.icon_name for some devices (e.g. Nokia N800). So these devices will make gnome-vfs select an icon that is most likely not present in the icon theme. I think the end user result is Nautilus choosing the "unknown icon" and that's going to look ugly. For GNOME 2.20 we can fix this assuming points 1. through 3. in comment 3 is addressed.
Reverted in svn for now. Lets get this into 2.20. Any distro that wants it can patch it in manually, but its up to them to make sure the icons and stuff works then.
> 3. GTK+'s icon theming code supports fallbacks so if Nautilus asks for > drive-harddisk-usb and this is not available it will fallback to > drive-harddisk. Rodney, did you have a bug reference for this? > See bug #396901 (with patch)
Bumping. Above bug has been fixed (in a slightly different way) meanwhile. Trying to push this for GNOME 2.22 at least.
HAL is dead. This bug could be closed? :)
gnome-vfs got deprecated in 2008. gnome-vfs is not under active development anymore and had its last code changes in 2011. Its codebase has been archived: https://gitlab.gnome.org/Archive/gnome-vfs/commits/master gio (in glib) and gvfs are its successors. See https://developer.gnome.org/gio/stable/ch33.html and https://people.gnome.org/~gicmo/gio-migration-guide/ for porting info. Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Feel free to open a task in GNOME Gitlab if the issue described in this task still applies to a recent + supported version of glib/gio/gvfs. Thanks!