Re: GVfs status report

[Alexander Larsson <alexl redhat com>]

On Fri, 2007-09-14 at 12:01 -0400, Matthias Clasen wrote:
> On 9/4/07, Alexander Larsson <alexl redhat com> wrote:
> 
> > If we want to use gvfs in Gnome 2.21 there are two possibilities:
> > 1) Release next glib before the next Gtk+ release
> > 2) Temporary ship gio in a separate module, which we later move to glib
> >   (pkg-config should magically make this work for users as long as the
> >   packages etc conflict properly)
> >
> > Both of these have the disadvantage that we can't use gio in
> > Gtk+. There are a bunch of UI helper dialogs etc that would be nice to
> > have there, but they are not critical.
> >
> > Opinions?
> 
> I think doing a glib release for 2.21 with gio is at least worth discussion,
> but as was already mentioned, it would probably be good to have some
> real-life experience with the api in the form of nautilus and file-chooser
> ports before committing to the api as part of glib.
> 
> I don't really know what to do about the GTK+ parts; having them in a
> libegg-like gvfs library until the next GTK+ release would not be the
> end of the world; imo.

This sounds like a reasonable plan.

> > Anyway, please check out at least the gio module and have a look at
> > it. Please. Pretty Please.
> >
> 
> Here are some very initial impressions:
> 
> - why do the GAppInfo launch functions take filena,es/uris, but not generic
>  arguments ?

You mean a call that takes GFile args? 

There is one issue related to this, and that is that GFiles are
generally limited to a subset of web uris. For instance, a mailto: uri
isn't generally something that makes sense wrt file management, whereas
it makes sense to pass such a uri to evolution. 

I think the reason the API is as it is currently is because it was just
designed around what a desktop file is, and it was done before GFile was
designed much. I think having a call that takes a list of GFiles makes
total sense, however for the above reason it is also good to have a
direct uri version of it.

> - there is a g_app_info_set_as_default_for_type(),  but there seems to be no
>   way to let an app hande a content type without being the default ?

Yeah, this would be useful for e.g. the open with tab in the nautilus
permission dialog. I added it to the TODO comment in gappinfo.h

> - what is "native", exactly ? is there a difference between native and local ?

The term "local" is in general bad for files. For instance, is a file on
an NFS share local? Is the file "trash:///some-trashed-file.txt" (which
is backed by a file in ~/.trash/) local? Some people thinks it means
that the uri starts with "file://", some that its fast, some that its
not on the network, etc.

We've had problems with it in gnome-vfs, so I decided to avoid this
problem in gio by using the term "native" to refer to files that are
expressed in the platform-native filename format (i.e. c:\windows
\foo.dll or /usr/bin/ls). And then I've tried to avoid having other
types of "locality" in the API at all, because its generally not useful
due to the limited amount of info it gives you (i.e. a lan network share
is not local, but can be faster than the local disk).

However, I partially failed in this since i used "local" as part of the
type names for the implementation of native paths :(. This is not
visibile in the public API, but we should probably still fix that up.

> Playing around with the demo programs a bit, I did
> 
> touch foo
> ./gio-cat gio-cat.c | ./gio-save --backup foo
> 
> which yields
> 
> Error closing: Error removing old backup link: No such file or directory
> 
> and leaves a .goutputstream-6VXKYT file behind.

Ah, it got an ENOENT error when removing the possibly existing old
backup file. I've fixed this in svn.