On Fri, 2002-09-13 at 10:42, Shahms E. King wrote: > I'm assuming that URI chaining should be handled automagically by > gnome-vfs for supported MIME types (rather than, say, Nautilus or > another end-user app), and trying to get some opinions on the "right" > way to do this. It seems this information is probably best specified in > the MIME information/metadata for the file so that it can be queried by > an application in someway, but also that an "open_directory" call on a > file that has chained methods will simply "do the right thing" at the > GVFS level. > I'm tired of reading people complaints about this not working in > Nautilus, and I'd like to do something about it, but I'm not sure where > to start (and the MIME/metadata API is currently in flux, but I don't > know the intended direction or scope of the changes, so I'm at a loss > for how to begin/proceed). Man, this is a real bitch of a problem. I've been thinking about this for over two years. Like you pointed out in reply to my "capabilities" rant GnomeVFS should expose to an application that a tarball supports directory operations and should "magically" handle invoking the tar method. Well, I think so anyway. I made chained methods work while I was at Eazel but nobody ever came up with a decent UI. The problem was this, when a user opens an image file they can use the "Open with..." menu to switch between EOG, Nautilus' internal viewer and other future components designed to show images. With chained methods the way they work currently, the act of "activating" a chained URI will change the URI from file:///path/to/file.tar to file:///path/to/file.tar#tar:/ - And then they won't be able to switch to another view (such as a guitar component or something like that) because as far as the application is concerned this isn't a tar file, its a directory. Once we have some kind of has_directory_ops capability exposed through GnomeVFS we can try to work out how to allow methods to provide extra operations for resources of a given type. The whole thing is quite tricky because once you remove the magic character from the URI its hard to work out which parts of the URI are handled by which components. For example with this URI: file:///path/to/file.tar/foo/bar/baz.txt, its not clear that file.tar is a tarball rather than a directory till you try to look for the local file /path/to/file.tar/foo/bar/baz.txt and find its not there. Sure you can walk up the URI doing stats, but this will suck really badly for remote filesystems where even small operations are expensive. So I too am at a loss. I would love to hear anyone's ideas about this. This would be really cool to support well. AFAIK KDE don't support chaining at all, they just defined a magic tar:// uri scheme that only works for local files. I think thats a cop-out. Ian
Attachment:
signature.asc
Description: This is a digitally signed message part