Questions for users, about vfs support
- From: <tpgww@xxxxxxxxxxx>
- To: emelfm2@xxxxxxxxxxxxx
- Date: Sun, 27 Aug 2006 09:38:09 -0400
Hi all
I'm seeking feedback about the merits of adding vfs capabilities to emelFM2.
Again, for those not too familiar with the jargon, this means the ability to
display the contents of virtual (as opposed to local, mounted) directories in
e2's file-lists. And it generally covers 2 categories - inside file archives,
and non-local directories accessed by ftp etc.
Tooar's original roadmap for e2 did include vfs capabilities. Some
(www.softpanorama.org/OFM/index.shtml) would say that all file managers like e2
should handle vfs.
But if this is to be added to e2, it's not without cost: some disruption to the
UI, fatter code, slower operation (probably not noticeable for "normal"
operations though), dependency on some other library(ies) which support the
protocols for interacting with a vfs. Not to forget - time and effort and bugs,
before it all works properly.
My questions for you are:
1. How strongly do you feel about adding this capability to e2 ? Other
application(s) can be used for the same functionality, and custom applications
typically have more features.
2. How acceptable is it to create a dependency on gnome-vfs ? It seems that the
vfs-mechanism being developed within the freedesktop.org community works on top
of gnome-vfs (at least). Gnome vfs is being actively developed, its API is well
documented (unlike some other candidates), recent versions (IIRC >= 2.15.4)
have reduced further dependencies e.g. bonobo is gone.
3. Linux and one? of the BSD's (etc??) support fuse. Does anyone have any
experience using fuse for archive and/or remote directory processing? Is it
worth looking into ?
4. How unpleasant is it to use the current unpack plugin ? That roughly
substitutes for archive-vfs, the difference being that the archive is actually
unpacked and repacked, which is slower, and not necessarily possible for all
archive-types, but does allow comprehensive "manipulation" of archive contents.
Regards
Tom
--
Users can unsubscribe from the list by sending email to
emelfm2-request@xxxxxxxxxxxxx with 'unsubscribe' in the subject field or by
logging into the web interface.
Other related posts:
