Re: Getting the icons used by GtkFileChooser

[Michael Natterer <mitch gimp org>]

Federico Mena Quintero <federico ximian com> writes:

> On Tue, 2004-03-02 at 11:58, Michael Natterer wrote:
>
>> 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

Please don't judge from the size and look of the preview, this is just
a quick proof-of-concept mockup and not planned to look that way
finally.

>> You'll notice the preview of the selected file is exactly the same as
>> in the file tree view. To render the icon, I can safely use the
>> semi-private GtkFileSystem API (if I #ifdef enough to be safe against
>> API changes).
>
> I don't think applications should display a preview for files they
> *really* know they cannot open.  That is, the GIMP shouldn't display a
> big socket icon as a preview for a Unix socket.  A text editor shouldn't
> display a preview for image files, etcetera.

We don't "preview" these files (even though the frame says preview ;-),
but rather see this as meta-information for the currently selected
file. It's just the same thing nautilus does: show the preview if it's
available, and show an icon otherwise. Seeing the same icons in the
file dialog as in the file manager should be in no way confusing
to the user.

This does not only apply to GIMP. I don't see what's wrong in using
the preview widget for displaying whatever meta-information for the
currently selected file (or files). The GtkFileChooser API may call
this "preview_widget", but it shouldn't restrict its use to be
preview-only. It should rather assume the widget being used for any
kind of file-related information. That's also why I asked for an API
to disable the preview label, sometimes it just is not a preview but
something else.

So even if what GIMP does is wrong and makes people shudder, an API to
get an icon to visually enrich the meta-info with something people
know from the file manager is something very useful.

> This is precisely what gtk_file_chooser_set_preview_active() is for.  In
> your ::update_preview() callback, you call that function with FALSE if
> you can't generate a preview for the file in question.  The file chooser
> will hide the preview widget in that case.

This is really questionable IMHO. I find the constant showing/hiding
of the preview annoying and ugly (but that's clearly debatable in all
length).

> As for thumbnailing in the GIMP, which is what we discussed on IRC:
>
> 1. There is no guarantee that the user will have the gnome-vfs backend
> installed, so Nautilus or thumbnail-spec thumbnails may not be
> available.  In that case, displaying a plain mime-type icon in the
> preview as a fallback is useless to users.

The preview frame will, apart from the useless icon, still show the
meta-info mentioned above. It will also e.g. say "cannot create
preview", or even "permission denied" instead of just hiding the
preview widget and leaving the user wondering why this single PNG
cannot be previewed.

> 2. The GIMP should *really* have a way to generate thumbnails
> automatically, without waiting for the user to click on the Preview
> button first --- at least for JPEG files which are ultra-common and
> allow for quick generation of thumbnails.  I know you told me that this
> is planned :)

That would clearly be nice to have :) but is in no way related to the
request of getting icons from the file chooser.

> I really fear that exposing data from the internal GtkFileInfo will lead
> to all sorts of questions around GTK+/glib not providing a VFS interface
> of its own.  This is beyond the scope of GTK+, and is rather a
> Freedesktop.org issue.

Totally agreed. I don't want GTK+ to expose a VFS-like API, I just
want to be able to get these icons rendered.

ciao,
--mitch