Re: gvfs status report
- From: nf2 <nf2 scheinwelt at>
- To: Alexander Larsson <alexl redhat com>
- Cc: "gnome-vfs-list gnome org" <gnome-vfs-list gnome org>, "gtk-devel-list gnome org" <gtk-devel-list gnome org>
- Subject: Re: gvfs status report
- Date: Mon, 19 Feb 2007 17:27:58 +0100
Alexander Larsson wrote:
The last month or so I've continued my work on a gnome-vfs replacement
called gvfs. Its still nowhere near finished, but its getting to a
state where it might be interesting for people to look at and give
some feedback. So, here is a writeup on the current design and
codebase.
If you haven't read my previous mail about the shortcomings of
gnome-vfs before I'd recommend you at least scan it before
continuing:
http://www.mail-archive.com/gnome-vfs-list gnome org/msg00899.html
The code is currently availible in a git repository at:
http://www.gnome.org/~alexl/git/gvfs.git
The gvfs code consists of three parts, a library "gio" which has the
API that applications use, a set of daemons handling access to various
file resources (only smb implemented atm), and a dynamic module that
(optionally) gets loaded into gio that communicates with said daemons.
Just a some ideas: I wonder if i would be nice to have some kind of
client side interface to 'jobs' - for instance to receive progress
callbacks. Even operations like 'g_file_get_info' can take long - for
instance if they have been queued by the daemon. Perhaps instead of the
GCancelable object, a GJob object could be registered with the
operations (or be returned by operations). GJob could then be used for
cancelation as well...
GFileInfo * g_file_get_info (GFile *file,
GFileInfoRequestFlags requested,
const char *attributes,
gboolean follow_symlinks,
GJob ** job,
GError **error);
g_job_register_progressHandler(GJob * job, void
(*progressHandler)(count, total, fields, units, stage));
g_job_register_cancelable(GJob * job, GCancelable *cancelable);
For instance in my "vio" thingie any operation can send progress
messages, which have a 'count', a 'total', 'valid fields', 'progress
units' and 'stage' fields. This could easily be displayed in a standard
progress widget (which might also have a "Cancel" button) to give the
user more info whats happening behind the scenes.
typedef enum
{
VIO_PROGRESS_VALID_NONE = 0,
VIO_PROGRESS_VALID_TOTAL = 1<<8,
VIO_PROGRESS_VALID_COUNT = 1<<9,
VIO_PROGRESS_VALID_BOTH = 1<<8 | 1<<9
} VioProgressValidFields;
typedef enum
{
VIO_PROGRESS_UNIT_NONE = 0,
VIO_PROGRESS_UNIT_BYTES = 1<<16,
VIO_PROGRESS_UNIT_PERCENT = 2<<16,
VIO_PROGRESS_UNIT_ITEMS = 3<<16 /* for direntries */
} VioProgressUnits;
typedef enum
{
VIO_STAGE_UNKNOWN = 0,
VIO_STAGE_AUTHENTICATION = 1,
VIO_STAGE_CONNECTING = 2,
VIO_STAGE_RECONNECTING = 3,
VIO_STAGE_DOWNLOADING = 4,
VIO_STAGE_UPLOADING = 5,
VIO_STAGE_WAITING = 6,
VIO_STAGE_COPYING = 7,
VIO_STAGE_READING_DIR = 8,
VIO_STAGE_QUEUED = 9,
VIO_STAGE_MOUNTING = 10
} VioProgressStage;
The other thing is the "shared VFS" (to be used by KIO as well).
Because GIO has a nice pluggable design, a cross-desktop VFS interface
like i'm trying to create with libvio
(http://www.scheinwelt.at/~norbertf/devel/vio/)
could also be plugged behind GIO...
regards,
norbert
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]