Re: Getting the icons used by GtkFileChooser

[Owen Taylor <otaylor redhat com>]

On Tue, 2004-03-02 at 12:58, Michael Natterer wrote:
> Hi,
> 
> I realize my mail is a bit late in the API freeze process but then the
> GtkFileChooser was hacked so badly the last few days (and I also
> hacked badly to follow the changes) that I realized this issue not
> earlier than today.
> 
> With the new automatic backend choosing of GtkFileChooser most people
> will sooner or later use the gnome-vfs backend without even knowing
> it, let alone explicitely linking against gnome-vfs.
> 
> The file chooser will then use nice icons for all kinds of
> mime-types. What I hacked up for GIMP looks like this:
> 
> http://mitch.gimp.org/filechooser/chooser-shot-5.png
> 
> You'll notice the preview of the selected file is exactly the same as
> in the file tree view.

Hmmm, I think we could definitely have a UI debate over whether what
you are doing there is a good idea... 

>  To render the icon, I can safely use the
> semi-private GtkFileSystem API (if I #ifdef enough to be safe against
> API changes).

I think it would be very unfortunate if installed versions of the GIMP
stopped working when users upgraded GTK+.

> However I have no way of getting the GtkFileSystem that is used by the
> GtkFileChooser and hiding that detail from evil hackers like me is
> perfectly OK.
> 
> IMHO the app should be able to use exactly the same icons as the file
> system backend does (for GUI consistency), so I see 3 ways of doing
> this:
> 
> (1) use _gtk_file_chooser_get_file_system().
> (2) link against libgnomeui and use gnome_icon_lookup().
> (3) add API like gtk_file_chooser_render_icon_from_filename() and _from_uri().
>
> (1) is what I do in GIMP now and is absolutely impossible because it
>     only works because libtool is broken.
> (2) is not an option because the app should not be forced to link
>     against gnome just to use the same icons GtkFileChooser uses.
> 
> The only remaining option seems (3), maybe in a slightly more
> sane way that involves GtkFileInfo.
> 
> This is IMHO an important issue since the writer of a GTK+-only
> program (like GIMP is) should be able to hack a consistent GUI even
> though GTK+ implicitely dynamically dlopen()-links against gnome-vfs.
> 
> Please consider this small API addition even though the
> deadline is over...

 A) It's possible to add later for GTK+-2.6
 B) The UI limitation (you can't display large versions of icons as
    previews?) is far from show-stopper

So I'd be quite opposed to any change here for GTK-2.4.

Thanks,
						Owen