On Fri, 2007-09-14 at 12:01 -0400, Matthias Clasen wrote: > On 9/4/07, Alexander Larsson <[EMAIL PROTECTED]> 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. _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list