Re: [Nautilus-list] Tar.gz view

[Maciej Stachowiak <mjs noisehavoc org>]

On 09Oct2001 08:16PM (-0500), Peter Snyder wrote:
> Nautilus hackers,
> 
> First off, let me say that I have very little programing experience.
> 
> I was thinking about a Tar.gz view (like half this list), and it seems
> like it should be very easy to impliment.  Couldn't the tar.gz'ed filed
> be copied to a temp dir, untared and gziped, and just point nautilus to
> there.  That seems like it would be very easy (though, like I said, I
> don't have too much experience).  If this seems fundamently sound, i
> will try to impliment it, but no promises on the results.
> 

gnome-vfs has some support 

Making that work well with Nautilus is high on Darin's priority list
and mine too.

In case anyone else besides me or Darin wants to work on this, here
are some notes I wrote for myself on one possible plan to make this
work:

----------------

* Clean up and debug the various modules that handle "tar:" and
"gzip:" and the like in gnome-vfs; the best way to do this is probably
to write a test suite first. In particular, the "tar:" module needs to
be improved to work on URIs that are not necessarily simple "file:"
URIs.

* Make gnome-vfs record the stackable URI schemes that can be applied
to a particular mime type in the mime database. For instance, the
"tar:" URI scheme can be applied to "application/x-tar". I think some
or all of this work may already be done.

* Introduce into nautilus a concept that there are URIs equivalent to
the one being viewed - URIs that represent the same location, but
viewed in a different way. For example, file:///some/file.tar.gz,
file:///some/file.tar.gz#gzip: and
file:///some/file/file.tar.gz#gzip:#tar: are all equivalent in this
sense. This mapping needs to be two-way, so that visiting any of these
URIs results in the same current URI equivalence class. Note, however,
that file:///some/file/file.tar.gz#gzip:#tar:/path/inside/tarball is
*not* equivalent to any gzip: or plain file: URIs.

* In the View As menu, merge the viewers that apply to any of the URIs
in the current URI equivalence class (and remember the specific URI
each should apply to).

* Figure out how to determine the right default viewer (should you get
the same default view visiting file:///some/file.tar as
file:///some/file.tar#tar:, or should you get the default tar file
viewer (if any) in the first case, and the default directory viewer in
the second case?)

* Determine whether it is appropriate to support browsing into
archives on remote filesystems like ftp: or http: (it's likely to have
quite poor performance),

----------------------


The end result will be that file://some/file.tar.gz will be viable
both by each of:

* a compressed file viewer specific to the gzip mime type (it might be
neat to have one and have it display stats about the compressed file
and offer the ability to uncompress it)
* an archive viewer specific to the tar archive mime type
* the regular directory views

In the case of a compressed tarball this might not be so useful, but
for RPMs, you probably _do_ want both a package-specific viewer, and
the ability to browse inside using directory views.


Regards,

Maciej