Re: File selector talk writeup



On Sun, Feb 16, 2003 at 11:16:43AM -0500, Ettore wrote:
> On Sun, 2003-02-16 at 01:54, Jody Goldberg wrote:
> > On Sat, Feb 15, 2003 at 12:28:17PM -0500, Ettore wrote:
> > > Maybe there is a way to push the MIME type handling part of GNOME VFS
> > > down the stack so GTK can depend on it?  Maybe it could go into GLib?
> > 
> > Pushing sniffing that far down has some nice elements, but will
> > create tension with the different use cases.  For something like
> > nautilus you can trade accuracy for speed, it absolutely must be
> > able to churn through lots of files.  For document-centric apps the
> > trade off is reversed.  The application needs to make the best
> > possible guess about what type of file it needs to open.  It can do
> > plenty of preprocessing for that single data blob.
> 
> I don't understand this objection; the file manager and the apps must
> have absolutely the same view of what type a certain file is.  Also, the
> consistency between the file selector and the file manager must be
> total.  Or not?

Ideally yes they would be consistent.  However, there are several
considerations that work to separate things.

- Some formats are not especially amenable to fast type sniffing.
  Particularly the compound file based formats.

    MS Office : apart from extension most files look the same to fast
		sniffers, they are 'OLE' files.  You need to look at
		the OLE directory (at a variable position in the
		stream) to tell them apart.
    OO : Its a zip file with some potential to sniff based on the a
	file type.  You can work around this to some extent with
	good internal file names, but it is not guaranteed.

- Another area where needs diverge is when handling more amourphous
  or generic formats.

    Raw XML : figuring out _whose_ xml can involve some work.
	    Eg is it gnumeric or MS Excel XP

    Gzipped stuff (eg XML) : Alot of the gnome-1.4 era formats are
    	still just gzipped xml which does not sniff nicely.

    Text based formats : CSV, TSV.  Gnumeric needs to make
    	intelligent guesses about this stuff, expecting the file
	browser to do it is probably too much.

None of this is impossible, or even terribly hard.  However, it does
add complication to an already complicated interface.  Don't get me
wrong, I'd love to see something like this done.  If we have the
resources to take this on now thats great, I'll do what I can to
help.



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