Important

This is not the page you are looking for. Go to GTK+/GtkFileChooserInternals instead.

Please don't insert your pet rants about the file chooser here unless you intend to contribute with code, usability tests on real users, or otherwise useful work.

Cleanup

Bugs

Last updated: 2007/01/25

Last bug number in the gtk+ "GtkFileChooser" component in bugzilla when this was updated: 348289

Last bug number in the libgnomeui "file-chooser" component in bugzilla when this was updated: 314280

Crashes/leaks/major stuff:

Access to remote files:

Bad GUI behavior:

Sizing issues:

GUI fine-tuning:

Niceties that we don't have:

Documentation:

Missing APIs:

Desktop integration:

RecentFilesAndBookmarks:

Filename entry, interactive search ("typeahead"):

Federico's list of annoyances: http://primates.ximian.com/~federico/news-2005-05.html#24

Morten's follow-up: http://blogs.gnome.org/view/mortenw/2005/05/25/1

Unfiled issues:

Performance:

Miscellaneous:

Recent folders

Imagine that RecentFilesAndBookmarks were revised, finished, and implemented.

What if we eliminated the Add/Remove buttons for bookmarks, and had the left pane in the file chooser have two columns like this: 

[bmk][Name                   ]
 [X]  Bookmarked folder 1
 [X]  Bookmarked folder 2
 [ ]  Recently-used folder 1
 [ ]  Recently-used folder 2
------------------------------
      Home
      Desktop
      Blah blah

That is, there would be a "keep"/"don't keep" column which you can toggle. The things displayed in that pane come from the recent-folders list, which is automatically maintained. You can "lock" folders in place by toggling them on in the first column; with that, they won't be pushed off the list if more recently-used folders come in.

With this I think we could eliminate the Add/Remove buttons, and get a bookmarks system that is more obvious to use (and requires less maintenance, since your working set of folders is kept by the recent-stuff machinery automatically).

Update 2006/Oct/19: Shit, I should have patented that. Office 12 now does this with push pins, more or less.

Thumbnail spec

<jrb> I have a patch to add thumbnailing to evince
<jrb> (it's file chooser)
<jrb> and it's too much code
<jrb> we should get that stuff into the filechooser
<federico> generic thumbnailing for images/pdfs?
<jrb> code to handle thumbnailing in general, and the thumbnail spec in particular
<federico> hmm, the thumbnail spec
<federico> yeah
<federico> how should it work?
<federico> gtk_file_chooser_install_thumbnailer (char *mime_type, ThumbnailFn callback)?
<federico> and then gtk_file_chooser_just_use_the_thumbnail_spec(chooser);
<jrb> something like that
<jrb> or maybe just gtk_file_chooser_set_preview_widget (filechooser,
gtk_file_chooser_thumbnailer_new (filechooser));
<jrb> to get stock behavior
<jrb> and if you want a callback

API: drop-down with types for opening/saving

This is bug 135901

Mailing list thread

We need this:

How do we deal with API explosion? See Havoc's mail. We can probably have a GtkFileChooserFileFormat object onto which we can add more API later if needed.

How do we make the GUI scale to apps like Gnumeric or OOo, which support zillions of formats? See Jody's mail on this.

Remembering settings

This is 153828

Stuff we will remember:

See also

Fixed bugs

Please put fixed bugs here, so that we can easily find them later.

Fixed but frequently reported (possibly from 2.4.x users):

Please use the patches in the SRPMS here; they fix many of these issues after the last 2.1.14 tarball was released: SRPMS for Novell Linux Desktop 9

GtkFileChooser (last edited 2008-06-19 22:52:59 by ThiloPfennig)