GNOME Bugzilla – Bug 538362
Get Win32 icons back in the file chooser
Last modified: 2008-06-17 22:02:46 UTC
by moving to gio the file chooser has lost the ability to show icons on win32. Code that was formerly in gtkfilesystemwin32.c now apparently needs to be split between gio (getting the GIcon, e.g. an identifier) and gtk+ (actually loading the icon and converting it to a pixbuf) Two patches which doing this are following
Created attachment 112746 [details] [review] build icon by looking up extensions in the registry * gcontenttype.c : build GIcon by names constructed from providing file and the resource index * glocalfile.c : simplify the version check for _MSC_VER so it can be compiled with older SDK
Created attachment 112748 [details] [review] the gtk+ part of win32 file chooser icons 2008-06-14 Hans Breuer <hans@breuer.org> * gtkfilesystem.c(gtk_file_system_list_volumes) : don't add the "File System" ("/") on win32, every drive has/is it's own root * gtkicontheme.c(choose_icon) : if not found in any theme try to extract the icon from a filename and index (how the are defined in the windows registry and given by GIcon) I don't completely like the choosen protocol but haven't had a better idea and at least it works. Ok to commit?
Thanks. Patches committed with minor changes. I added handling of REG_EXPANDED_SZ strings to gcontenttype.c's get_registry_classes_key(). I am not sure whether an icon theme should override an icon specificed in the Registry or not? Does it make sense to let a more generic themed icon override a more specific icon from the Registry? Is visual icon uinformity (as achieved by using icon theme icons if at all possible) more important than showing perhaps familiar icons (even if they are ugly and don't match the other icons from an icon theme)?
Thanks for applying. I'm wondering why you choose only this patch in the series provided to restore file chooser capabilities. At least for me there are no files shown at all without applying the patch from bug #538127 first. For further themability I don't have a strong preference for either of the cases. Even the mix as it was with my patches is fine with me;)
Hmm, odd. I do see files even without the patch in bug #538127. (Feel free to commit that one.) Do you have several drive letters, could that cause it? I have only one C: (and D: for the DVD drive), but I do have several mounted volumes.
Just tried again without my patch - it indeed works to access files but only for one drive, because there is no way to change to a different one. I don't understand what you mean by "have several mounted volumes"? My current understanding of the GIO terminology is: GDrive - a physical entity, e.g. hard disk, usb-stick, dvd-drive GVolume - aka. partitions, not mounted GMount - a 'mounted' volume, on windows mapped to a drive letter, on unix somewhere in the file system more in the other bug
> I don't understand what you mean by "have several mounted volumes" I meant "volume" in the Windows sense. You can have volumes (i.e. file systems, on separate hard disks, or partitions, etc) mounted on empty folders on Windows, too. I use that, I don't use drive letters. But anyway, yes, we both see the same then.