Re: A few problems with GtkFileChooser



On Mon, 2003-11-17 at 17:02, Owen Taylor wrote:
> On Sun, 2003-11-16 at 10:18, Dave Malcolm wrote:
> > On Sun, 2003-11-16 at 14:06, iain wrote:
> > > I've been trying out the file chooser in my program and have come
> > > against a few issues
> > > 
> > [snip]
> > 
> > > 4: When you select a filter, say "All PNGs" all the directories
> > > disappear too.
> > 
> > I'm trying from fairly-up-to-date CVS, and when I select a mime-based
> > filter _everything_ disappears, files and directories.  I did a bit of
> > digging, and my mime types seem a bit hosed, all files are coming out as
> > "application/octet-stream", and all directories as NULL.  (I'm going to
> > investigate further...)
> 
> I think you need the XDG mime information installed for the Unix backend
> MIME type detection to work properly. I'm not sure what we'll do about
> this for the final GTK+-2.4 release... probably just make it another
> dependency of GTK+ :-(
> 
>  http://www.freedesktop.org/software/shared-mime-info


Thanks - I was building using jhbuild, which didn't handle this.  I've
filed a bug against jhbuild for this (bug #127319), with a patch to add
the shared-mime-info 0.12 tarball as a dependency.  I haven't touched
GTK's configure.in yet though.

> 
> Though perhaps directories all just show up with a NULL mime type.

Yes; I've got sane mime types coming through now, but directories all
appear with NULL strings for their mime type; hence they disappear for
me when I select a MIME-based filter (as in Iain's original post, item
4, above), unless I apply my patch.

> 
> > Do we have to specify "x-directory/normal" in the list of mime types for
> > the filter in order to see folders?  This only makes sense if we're
> > intending for the user to select a directory itself.
> > 
> > Perhaps we need to always list folders; attached is a patch to the
> > default widget's list model filter which does this (plus a bit of
> > useless debug code as I track down my MIME issues).
> 
> If you make it only do that when the filechooser isn't in directory
> mode, looks fine to commit. (Without the debug spew, of course.)

The widget implementation maintains two separate child GtkTreeView
widgets: one for "folder mode", with a tree-style model (uses a
GtkFileSystemModel), and one for "non-folder" mode with a list model
containing the filtered content of the current directory.  

I believe the patched routine is used solely by the latter, so it should
safely apply only to the non-folder case as is.

Attached is a tidied version of the patch, which makes folders always
visible in "non-folder" mode, allowing the user to navigate into them.

OK to commit?

-- 
David Malcolm
http://www.davemalcolm.demon.co.uk
Index: gtk/gtkfilechooserdefault.c
===================================================================
RCS file: /cvs/gnome/gtk+/gtk/gtkfilechooserdefault.c,v
retrieving revision 1.37
diff -p -u -r1.37 gtkfilechooserdefault.c
--- gtk/gtkfilechooserdefault.c	4 Nov 2003 01:56:56 -0000	1.37
+++ gtk/gtkfilechooserdefault.c	18 Nov 2003 23:53:06 -0000
@@ -1457,6 +1457,10 @@ list_model_filter_func (GtkFileSystemMod
   if (!impl->current_filter)
     return TRUE;
 
+  /* We always display folders in the list, regardless of the filter, so that the user can navigate into them: */
+  if (gtk_file_info_get_is_folder (file_info))
+    return TRUE;
+
   filter_info.contains = GTK_FILE_FILTER_DISPLAY_NAME | GTK_FILE_FILTER_MIME_TYPE;
 
   needed = gtk_file_filter_get_needed (impl->current_filter);


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]