Re: GVfs status report
On Tue, 2007-09-25 at 00:11 +0200, Carlos Garnacho wrote: Hi!, On Fri, 2007-09-14 at 12:01 -0400, Matthias Clasen wrote: snip 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've began a gio/gvfs file system backend, it's still work in progress, but is already looking quite good, you can clone it from git://git.imendio.com/carlos/gtk-file-system-gvfs.git Excellent!!! Is it not possible for GtkFilePath * to be a GFile object? That would seem more natural. (Although i do remember that really just being a typedef:ed string.) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GVfs status report
Hi!, On Tue, 2007-09-25 at 09:02 +0200, Alexander Larsson wrote: On Tue, 2007-09-25 at 00:11 +0200, Carlos Garnacho wrote: Hi!, On Fri, 2007-09-14 at 12:01 -0400, Matthias Clasen wrote: snip 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've began a gio/gvfs file system backend, it's still work in progress, but is already looking quite good, you can clone it from git://git.imendio.com/carlos/gtk-file-system-gvfs.git Excellent!!! Is it not possible for GtkFilePath * to be a GFile object? That would seem more natural. (Although i do remember that really just being a typedef:ed string.) Effectively, it's a typedef'ed string, and its methods are defined in gtkfilesystem.h... at first I though too it'd make sense to pass around GFiles, perhaps that should be kept in mind for the future, being gtkfilesystem.h a semi private header, it might be certainly a possibility. Regards, Carlos ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GVfs status report
Hi!, On Fri, 2007-09-14 at 12:01 -0400, Matthias Clasen wrote: snip 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've began a gio/gvfs file system backend, it's still work in progress, but is already looking quite good, you can clone it from git://git.imendio.com/carlos/gtk-file-system-gvfs.git Regards, Carlos ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GVfs status report
On Fri, 2007-09-14 at 10:47 -0400, Havoc Pennington wrote: Hi, On 9/14/07, Alexander Larsson [EMAIL PROTECTED] wrote: Well, the same class is used on both unix and windows. Its the implementation of native files, and I don't see any need to split it out really. What differences would there be between the two? My impression is that ideally on Windows you use the native windows-looking file API, and that the file-descriptor-using API is some kind of weird emulation hack. But I could not comment intelligently on the details. I assume so. Its part of the libc runtime on windows. However, the question is, apart from one layer less, what are the other advantages? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GVfs status report
Alexander Larsson wrote: On Fri, 2007-09-14 at 10:47 -0400, Havoc Pennington wrote: Hi, On 9/14/07, Alexander Larsson [EMAIL PROTECTED] wrote: Well, the same class is used on both unix and windows. Its the implementation of native files, and I don't see any need to split it out really. What differences would there be between the two? My impression is that ideally on Windows you use the native windows-looking file API, and that the file-descriptor-using API is some kind of weird emulation hack. But I could not comment intelligently on the details. I assume so. Its part of the libc runtime on windows. However, the question is, apart from one layer less, what are the other advantages? Pygtk is currently unable to use GIOChannel because both Glib and Python use file descriptor API, but different C runtime libraries. Or something like that. Nobody knows for sure. Problem is, C library on windows is just some library, not the foundation on which everything is built. Plus, there is some fun with normal file descriptors and sockets. So you can have two integers corresponding to the same file, or you can have one integer corresponding to two different files. Best regards, Yevgen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GVfs status report
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
Re: GVfs status report
The issue is that file descriptors shouldn't be passed from a dll / exe using one C runtime to another using a different C runtime -- or if they are, they must be used only with functions from the appropriate C runtime. Use of file descriptors within a single dll is generally not a problem. That's correct, and a major complaint of people using gstdio's g_fopen() routine. The native win32 calls (CreateFile and others) probably has advantages, but I can't say whether a separate implementation would be desirable. As best as I can tell, most of stdio is just shallow wrappers around the native Win32 API. A major discrepancy (as I've said before) is that Windows places an artificial limit of 2k FILE*s or fd_ts per process. Wine even goes so far as to duplicate this madness. By not using the Win32 CreateFile/OpenFile functions, you unintentionally limit how many open files a user of your library might have. This comes up more than you'd think in real life. For example, here's a bug against Sun's JVM reported against JDK 1.1 and not fixed until JDK 1.5: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4189011 Cheers, Dom ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GVfs status report
On Thu, 2007-09-13 at 14:12 -0400, Havoc Pennington wrote: Hi, There's a lot of code to absorb here, a minor comment, I might expect GUnixFileInputStream/GWindowsFileInputStream rather than GLocalFileInputStream. Well, the same class is used on both unix and windows. Its the implementation of native files, and I don't see any need to split it out really. What differences would there be between the two? I haven't found the relevant code yet to see what it does, but a nice property would be to set close-on-exec by default for all streams. I guess we could do that. Can this ever be a problem, or can we just always do it without a way to disable it? A more macro thought, since there's so much code here, it would be worth spending some time to try and identify the parts an app (vs. a file manager) would usually use, and then somehow highlight those parts in the docs and/or header file organization. i.e. make it easy if I just want to read and write a file Yeah, that makes sense. For you typical application that wants to load and save files I think the following is the core API: Creating a new GFile (which is essentially an abstract filename object): from native filename: GFile * g_file_new_for_path (const char *path); from uri: GFile * g_file_new_for_uri (const char *uri); from commandline argument (absolute path, cwd relative path or uri): GFile * g_file_new_for_commandline_arg (const char *arg); from a filename/uri input entry (a utf8 string, filename, uri or iri): GFile * g_file_parse_name (const char *parse_name); Ideally one should also be able to get one from the file selector. Loading a file: synchronously: gboolean g_file_load_contents (GFile *file, GCancellable *cancellable, char**contents, gsize*length, GError **error); asynchronously: void g_file_load_contents_async (GFile*file, GCancellable *cancellable, GAsyncReadyCallback callback, gpointer user_data); In the callback you then call g_file_load_contents_finish on the GAsyncResult object to get the result of the operation: gboolean g_file_load_contents_finish (GFile*file, GAsyncResult *res, char**contents, gsize*length, GError **error); This is the async i/o API model, made so that all callbacks are the same type. Easy to remember, easy to bind. streaming: Use g_file_read or g_file_read_async to get a GFileInputStream. GFileInputStream is a GInputStream with added fstat and seek support. GInputStream allows both sync and async i/o calls. Saving a file: Similar to reading, there are sync and async versions of this: gboolean g_file_replace_contents (GFile*file, const char *contents, gsize length, const char *etag, gboolean make_backup, GCancellable *cancellable, GError **error); Its pretty obvious how to use, except the etag argument. Etags are similar to etags in http, and mtime tags in local files. You pass in one you got when reading or writing the file last time and if the file on disk differs from the passed in tag you get an error. (I notice here that the helper API sucks, because you can't get the new etag when writing a file, or when reading a file.) You can also do this manually with streaming by using g_file_replace() or g_file_replace_async() and writing to the output stream. Somewhat interesting to normal apps might be: GFileMonitor* g_file_monitor_file (GFile *file, GFileMonitorFlags flags); Call this an it returns an object that will emit the changed signal when the file changes. It uses inotify or fam/gamin, or falls back to a polling implementation if that isn't supported. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GVfs status report
On Fri, 2007-09-14 at 09:37 +0200, Alexander Larsson wrote: A more macro thought, since there's so much code here, it would be worth spending some time to try and identify the parts an app (vs. a file manager) would usually use, and then somehow highlight those parts in the docs and/or header file organization. i.e. make it easy if I just want to read and write a file Yeah, that makes sense. For you typical application that wants to load and save files I think the following is the core API: If anyone wants to see a non-trivial real world application they can have a look at my toy image viewer, Katachi. $ bzr branch http://burtonini.com/bzr/katachi Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GVfs status report
Hi Alex, On 9/14/07, Alexander Larsson [EMAIL PROTECTED] wrote: On Thu, 2007-09-13 at 14:12 -0400, Havoc Pennington wrote: Hi, There's a lot of code to absorb here, a minor comment, I might expect GUnixFileInputStream/GWindowsFileInputStream rather than GLocalFileInputStream. Well, the same class is used on both unix and windows. Its the implementation of native files, and I don't see any need to split it out really. What differences would there be between the two? Well, we'd probably want at least a Win32 implementation in terms of the native Windows file API. Windows limits the number of FILE*s or fd_ts to 2048 per process. The only way to get around this limitation is to use the native API. Cheers, Dom ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GVfs status report
On Fri, 2007-09-14 at 08:16 -0400, Dominic Lachowicz wrote: Hi Alex, On 9/14/07, Alexander Larsson [EMAIL PROTECTED] wrote: On Thu, 2007-09-13 at 14:12 -0400, Havoc Pennington wrote: Hi, There's a lot of code to absorb here, a minor comment, I might expect GUnixFileInputStream/GWindowsFileInputStream rather than GLocalFileInputStream. Well, the same class is used on both unix and windows. Its the implementation of native files, and I don't see any need to split it out really. What differences would there be between the two? Well, we'd probably want at least a Win32 implementation in terms of the native Windows file API. Windows limits the number of FILE*s or fd_ts to 2048 per process. The only way to get around this limitation is to use the native API. Thats mainly a problem with the input streams, but most of the GFile operations are things like rename, copy, move, etc. However, it seems that it might make sense for GLocalFileInput/OutputStream to have special implementations on windows. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GVfs status report - Sep 14
Since the last report I've mainly been working on the sftp backend, which now is mostly working. There are some minor details left which can be seen in the TODO list at the top of gvfsbackendsftp.c. To help with the sftp backend I also added GDataInputStream and GDataOutputStream to gio. These helper streams makes it easy to read and write binary data. I have also imported gio and gvfs into the Gnome subversion repository. gio is in the gio-standalone module (gio is an unrelated dead old module), and gvfs is in the gvfs module. The plan is to do releases from gio-standalone and have people start using it, and at some point when we feel ok with the API it will be moved over to the glib module, and the pkg-config file renamed from gio-standalone.pc to gio.pc and the API frozen. (It will be totally frozen by the time glib is released with it, but slushy frozen when moved to glib). I've also done some minor cleanup from responses to my latest status report. My ongoing plan is to branch nautilus next week, making one 2.20 branch, then head for 2.21 and a separate branch for converting nautilus to use libgio instead of gnome-vfs. Hopefully this will lead to: * Testing and bugfixing of gio and gvfs * Verification of the gio API being easy to use and having all the features needed * Integration of gio and its mount system with the desktop so that other apps can start using gio in a nice way ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GVfs status report
Hi, On 9/14/07, Alexander Larsson [EMAIL PROTECTED] wrote: Well, the same class is used on both unix and windows. Its the implementation of native files, and I don't see any need to split it out really. What differences would there be between the two? My impression is that ideally on Windows you use the native windows-looking file API, and that the file-descriptor-using API is some kind of weird emulation hack. But I could not comment intelligently on the details. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GVfs status report
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. 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 ? - 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 ? - what is native, exactly ? is there a difference between native and local ? 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. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GVfs status report
Le mardi 04 septembre 2007, à 11:03 +0100, Bastien Nocera a écrit : Hey Alex, On Tue, 2007-09-04 at 11:35 +0200, Alexander Larsson wrote: After some time away from GVfs I'm now back working on it. In order to get people to start looking at it I'm sending this status report. I'll also try to send more regular status reports in the future. snip 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. The latter woul mean some GNOME applications losing authentication support in the migration if they don't implement that portion of the code themselves. Would it be completely out of the question to have a GTK+ release for the sake of gio/gvfs? With the GNOME release team hat on my head: I think there's a big interest in using gvfs in 2.21, but it'd be nice to know at the beginning of the cycle whether we'll do it or not. So coming up with a plan soonish would be great from the GNOME point of view :-) (of course, the plan can be wait for 2.23) Vincent -- Les gens heureux ne sont pas pressés. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GVfs status report
On Thu, 2007-09-13 at 18:01 +0200, Vincent Untz wrote: Le mardi 04 septembre 2007, à 11:03 +0100, Bastien Nocera a écrit : Hey Alex, On Tue, 2007-09-04 at 11:35 +0200, Alexander Larsson wrote: After some time away from GVfs I'm now back working on it. In order to get people to start looking at it I'm sending this status report. I'll also try to send more regular status reports in the future. snip 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. The latter woul mean some GNOME applications losing authentication support in the migration if they don't implement that portion of the code themselves. Would it be completely out of the question to have a GTK+ release for the sake of gio/gvfs? With the GNOME release team hat on my head: I think there's a big interest in using gvfs in 2.21, but it'd be nice to know at the beginning of the cycle whether we'll do it or not. So coming up with a plan soonish would be great from the GNOME point of view :-) (of course, the plan can be wait for 2.23) We can always go for egg cut'n'paste for the applications that choose to use gvfs in their UI, and need auth support. I'd be happy to use it in Totem. -- Bastien Nocera [EMAIL PROTECTED] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GVfs status report
Hi, What about nautilus? At what point would it be ported, and are things going to be weird if an app is using gvfs and nautilus gnome-vfs, or vice versa? Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GVfs status report
On Thu, 2007-09-13 at 12:23 -0400, Havoc Pennington wrote: Hi, What about nautilus? At what point would it be ported, and are things going to be weird if an app is using gvfs and nautilus gnome-vfs, or vice versa? I plan to branch nautilus soon and start porting it to gio. Some time next week. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GVfs status report
On Thu, 2007-09-13 at 18:01 +0200, Vincent Untz wrote: Would it be completely out of the question to have a GTK+ release for the sake of gio/gvfs? With the GNOME release team hat on my head: I think there's a big interest in using gvfs in 2.21, but it'd be nice to know at the beginning of the cycle whether we'll do it or not. So coming up with a plan soonish would be great from the GNOME point of view :-) (of course, the plan can be wait for 2.23) I've now merged gio and gvfs into gnome svn (modules gio-standalone and gvfs). The plan going forward is to do external releases of gio-standalone and make nautilus and other apps work with that. At what point we will merge it into glib is not known right now. I think we needs to see how it works out in Nautilus a bit first. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GVfs status report
Hi, There's a lot of code to absorb here, a minor comment, I might expect GUnixFileInputStream/GWindowsFileInputStream rather than GLocalFileInputStream. I haven't found the relevant code yet to see what it does, but a nice property would be to set close-on-exec by default for all streams. A more macro thought, since there's so much code here, it would be worth spending some time to try and identify the parts an app (vs. a file manager) would usually use, and then somehow highlight those parts in the docs and/or header file organization. i.e. make it easy if I just want to read and write a file Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GVfs status report
After some time away from GVfs I'm now back working on it. In order to get people to start looking at it I'm sending this status report. I'll also try to send more regular status reports in the future. Yesterday I split the gvfs repository into two parts, gio and gvfs: gio is an architecture-independent library for file i/o that is targeted for inclusion in glib. It depends on gobject, and optionally on a few system libs like libselinux and libfam. The library contains interfaces and base classes for abstract file I/O, an implementation that works for local files, and a module system so that you can insert other implementations. gvfs is a plugin for libgio that extends the types of files gio can write to. The plugin uses dbus to talk to out-of-process daemons that implement the various kinds of file shares. Its designed for unix-like systems, and is not meant to work for e.g. Windows (which could instead implement their own libgio extensions for their native extended vfs:es). The repositories for these two are now: http://www.gnome.org/~alexl/git/gio.git http://www.gnome.org/~alexl/git/gvfs.git I've requested subversion modules for them, so eventually they will be in gnome svn. I think libgio is getting close to a final form. The API is pretty full, and the implementation is pretty fleshed out. Its lacking asynchronous versions of a few functions, and it doesn't have much docs yet. But otherwise there are just a few things in the TODO, and they don't really affect the API (in theory). It would be nice if people could take a better look at the API and try to use it for stuff. Even without the gvfs part it should be a nice API for file I/O. GVfs is a bit more raw atm. Its got the basic parts working, but quite a few calls are not implemented yet. There is also only one backend (smb). I think we want to spend some time adding a few more backends now, to validate the design for different types of protocols. If people are interested in helping out with this that would be cool. It might be time to start discussing how to merge gio and get gnome to use it at this point. Since libgio is supposed to ship with glib this would mean that the first public release of it would be in the next glib/gtk+ release, which is approximately in June 2008. This means we can't use gvfs in Gnome 2.21, which is unfortunate. 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? Anyway, please check out at least the gio module and have a look at it. Please. Pretty Please. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GVfs status report
Hey Alex, On Tue, 2007-09-04 at 11:35 +0200, Alexander Larsson wrote: After some time away from GVfs I'm now back working on it. In order to get people to start looking at it I'm sending this status report. I'll also try to send more regular status reports in the future. snip 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. The latter woul mean some GNOME applications losing authentication support in the migration if they don't implement that portion of the code themselves. Would it be completely out of the question to have a GTK+ release for the sake of gio/gvfs? Cheers -- Bastien Nocera [EMAIL PROTECTED] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GVfs status report
On Tue, 2007-09-04 at 11:03 +0100, Bastien Nocera wrote: Hey Alex, On Tue, 2007-09-04 at 11:35 +0200, Alexander Larsson wrote: After some time away from GVfs I'm now back working on it. In order to get people to start looking at it I'm sending this status report. I'll also try to send more regular status reports in the future. snip 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. The latter woul mean some GNOME applications losing authentication support in the migration if they don't implement that portion of the code themselves. Authentication is a bit different in gvfs vs gnome-vfs, but yes, that is one of the helper things that would be nice to have in Gtk+. It could be handled in a libeel kind of way though. Would it be completely out of the question to have a GTK+ release for the sake of gio/gvfs? I don't really have a say here... ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: VFS for legacy apps (was: gvfs status report)
On Thu, 2007-02-22 at 17:39 -0500, Sean Middleditch wrote: Just a reminder that : is the separator used in the PATH environment variable, and is thus a poor choice for use in directories. In all honesty, if the intended use case for reading the directory info is for FUSE and GVFS, I think it would be a lot cleaner to just put some kind of user-friendly name in ~/.mounts/, and then create a ~/.mountrc config file that maps the names to mount parameters which the FUSE fs and GVFS can use to recreate the mount points. Basically, it'd just be a per-user fstab replacement. I want to make sure this takes NFS mounted home directories into consideration. I think perhaps ~ is a very poor choice of location for this. Add in a few CLI utils to call mount with the right parameters for mounts in ~/.mountrc, and you'll have a pretty solid system for both modern GUI, legacy GUI, and CLI users. You're probably always going to need type, server and share though, so maybe you can make it a bit more readable: ~/.mounts/smb:$server:$share/dir/file.txt Extra options can go on the end. Also I'd probably avoid ';' just in case bash goes anywhere near it. Sure, those are requred. But say we have two optional things, like user and domain, as in smb:server:share:user:domain. But what do we then do if user is unset, but domain isn't. I guess one could do smb:server:share::domain. Still, it requires very specific handling of each type of share with a specified option order etc. A key=value approach is more generic. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gvfs status report
I was going over this old posting and wanted to add some commentary. In a perfect world, which we should try to achieve, of course, any such passed uris would be canonical and resolvable within scope of both machines. That is, full host names should be passed and both boxes should be able to resolve them properly. Now I recognize that this is a pie in the sky. But it is a good ideal to hope for, and within any single network, and on an Internet where everybody properly implements IPv6, probably ideal. Just make sure that converting a GFile into a uri string considers this. On Thu, 2007-02-15 at 18:57 +0100, Alexander Larsson wrote: On Thu, 2007-02-15 at 17:52 +0100, Xavier Bestel wrote: On Thu, 2007-02-15 at 17:45 +0100, Alexander Larsson wrote: While a laudable idea I'm not sure this is practical, at least not as the main approach. If I drag a directory from nautilus to some other apps, do you really want to transfer the full recursive copy of all files in the directory via X messages? Its not gonna be fast... Well, if the 2 apps don't sit on the same computer, what else could you want ? Of course, as an optimization if the 2 apps are local to each other, they should just use the current behavior. Actually, its more than a performance issue. What you really want is the file reference (i.e. filename), not the file contents. The app recieving the filename can do all sorts of things with it, not just read it. e.g. it could stat it, it could statfs() it to see what filesystem type it is on, it could traverse the filesystem up or down, or it could open the file and later save back to the same filename. All of these operations would have to be supported, and you need to be able to save the file reference persistantly, for say recent-files. All in all, that seems hard to do via X. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a scrappy umbrella-wielding werewolf looking for a cure to the poison coursing through his veins. She's a vivacious communist Hell's Angel who don't take no shit from nobody. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: VFS for legacy apps (was: gvfs status report)
Just a reminder that : is the separator used in the PATH environment variable, and is thus a poor choice for use in directories. In all honesty, if the intended use case for reading the directory info is for FUSE and GVFS, I think it would be a lot cleaner to just put some kind of user-friendly name in ~/.mounts/, and then create a ~/.mountrc config file that maps the names to mount parameters which the FUSE fs and GVFS can use to recreate the mount points. Basically, it'd just be a per-user fstab replacement. Add in a few CLI utils to call mount with the right parameters for mounts in ~/.mountrc, and you'll have a pretty solid system for both modern GUI, legacy GUI, and CLI users. You're probably always going to need type, server and share though, so maybe you can make it a bit more readable: ~/.mounts/smb:$server:$share/dir/file.txt Extra options can go on the end. Also I'd probably avoid ';' just in case bash goes anywhere near it. Sure, those are requred. But say we have two optional things, like user and domain, as in smb:server:share:user:domain. But what do we then do if user is unset, but domain isn't. I guess one could do smb:server:share::domain. Still, it requires very specific handling of each type of share with a specified option order etc. A key=value approach is more generic. -- Sean Middleditch [EMAIL PROTECTED] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: VFS for legacy apps (was: gvfs status report)
On Thu, 2007-02-22 at 12:49 -0600, Hans Petter Jansson wrote: On Thu, 2007-02-22 at 12:38 +, Damon Chaplin wrote: On Thu, 2007-02-22 at 03:10 -0600, Hans Petter Jansson wrote: However, the first method you describe: ~/.mounts/type=smb-share;server=$server;share=$share/dir/file.txt sounds perfect. It's rich (we can get back the mount info later), extensible (we don't have to figure out the entire set of potential mount options in advance) and fairly simple (the root nodes are all direct children of ~/.mounts). You're probably always going to need type, server and share though, so maybe you can make it a bit more readable: ~/.mounts/smb:$server:$share/dir/file.txt Extra options can go on the end. Also I'd probably avoid ';' just in case bash goes anywhere near it. Yeah - the actual syntax is still up in the air, but we need to define it carefully. Do you think ':' is a good separator? I'm not sure you'll always be accessing a share (subdirectory) on the server. I guess we could make the share be / in that case... In the current code browsing a share and browsing a server/workgroup is two different types, smb-share and smb-server. This is required to map correctly on the weird thing that is smb uris. So, this is not really a problem in this particular case. The problem of multiple optional options is still in the generic case though. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a deeply religious Jewish paranormal investigator who must take medication to keep him sane. She's a ditzy tempestuous wrestler descended from a line of powerful witches. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: VFS for legacy apps (was: gvfs status report)
On Thu, 2007-02-22 at 14:22 -0600, Hans Petter Jansson wrote: On Thu, 2007-02-22 at 13:51 +0100, Alexander Larsson wrote: On Thu, 2007-02-22 at 12:38 +, Damon Chaplin wrote: You're probably always going to need type, server and share though, so maybe you can make it a bit more readable: ~/.mounts/smb:$server:$share/dir/file.txt Extra options can go on the end. Also I'd probably avoid ';' just in case bash goes anywhere near it. Sure, those are requred. But say we have two optional things, like user and domain, as in smb:server:share:user:domain. But what do we then do if user is unset, but domain isn't. I guess one could do smb:server:share::domain. Still, it requires very specific handling of each type of share with a specified option order etc. A key=value approach is more generic. I suppose ~/.vfs/smb:$server:$share/dir/file.txt:option=$value:option=$value You mean ~/.vfs/smb:$server:$share:option=$value:option=$value/dir/file I assume? is a workable compromise. It might even be what Damon was indicating. Now that we're picking on details, I'd say that .vfs or .gvfs would be a better base directory than .mounts too. This would work, and would look better. It still requires specific code for each possible backend to map from path back to the mount info though. (i.e. you need to know that for smb the first two items are server and share.) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's an obese neurotic vampire hunter with acid for blood. She's an artistic psychic schoolgirl who inherited a spooky stately manor from her late maiden aunt. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: VFS for legacy apps (was: gvfs status report)
On Thu, 2007-02-22 at 14:51 -0600, Hans Petter Jansson wrote: On Thu, 2007-02-22 at 14:44 +0100, Alexander Larsson wrote: In fact, its likely they implement this by just stat()ing all the files in the recent list. This is a great example of where automounting would royaly screw things up. Given a traditional unix system there wouldn't be anything bad with a solution like that (in fact, it would be very nice to not show deleted files in the recent menu). However, if any stat can lead to indefinite blocking and displaying of random authentication dialogs you suddenly have to do something much more complicated in order to not suck. That's a good point. To make that suck less, you'd probably have to - Immediately deny any access to unmounted shares. - Pop up a dialog asking the user if it should be mounted (if the mount metadata could be converted to a more display-friendly string, such as a URI or even a chosen name, that would be great). - Optionally mount it. So, when the app reads the data for recent files and stats it, or does some other similar operation you'll pop up a dozen dialogs allowing you to mount things like ftp.gnome.org again. You click no several times, and two seconds later they all pop up again. Believe me, things like this happen, all the time. I have to be extremely careful in nautilus for example to never ever access (even get info about) things like history or bookmarks except when the user explicitly browse into them, otherwise we pop up dialog to left and right, when the user don't expect this at all. I much prefer a system where the app can either just ignore the failed stat (if it was an unimportant operation), or in case an open fails display an error that the pathname couldn't be opened, with a pathname that users can understand. Especially when said pathname is also likely to appear in the user interface (in the file selector). The bad part is that the application's access denied and the I think you're trying to mount something dialogs would pop up simultaneously. With gnome-keyring integration, this problem would largely go away, though. In most cases, gvfs could fetch the auth information transparently then go ahead and mount. Its unfortunate that due to todays stateless gnome-vfs that doesn't ever reuse server connections between processes we have to use gnome-keyring as a poor-mans connection-sharing. This is really not a good idea in general, as it means you tend to store all your passwords (like smb or sftp passwords that are often the same as your system password!) in gnome-keyring. Which is *not* recommended as good password hygiene. (i.e. anyone in front of your unlocked desktop, say when you're on lunch, can easily extract all your passwords from gnome-keyring. Handing out passwords is after all what gnome-keyring is designed to do.) Lets not propagate such use further. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a lounge-singing albino jungle king with a passion for fast cars. She's a chain-smoking cigar-chomping doctor who can talk to animals. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: VFS for legacy apps (was: gvfs status report)
On Thu, 2007-02-22 at 22:26 +0100, Nikolai Weibull wrote: On 2/22/07, Hans Petter Jansson [EMAIL PROTECTED] wrote: ~/.mounts/type=smb-share;server=$server;share=$share/dir/file.txt I just want to point out that there's a freedesktop specification for where things should be stored. Not many seem to respect it, but I, for one, really would appreciate it if people would, as the root of my ~ isn't a junkyard for files and directories. My OCD really needs it to be in order. http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html The basedir spec is for data and config files though. Whereas this is a mountpoint for user files. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a time-tossed albino waffle chef with a winning smile and a way with the ladies. She's a ditzy gold-digging hooker on her way to prison for a murder she didn't commit. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: VFS for legacy apps (was: gvfs status report)
On Thu, 2007-02-22 at 03:10 -0600, Hans Petter Jansson wrote: This won't work. We need to be able to extract all the mount information from the path, so that if the app stores the path across sessions, say, in recent documents, the FUSE layer will know what to do when it's accessed later. I'm just not certain this is true. I mean, we already have this problem with say filenames pointing to unmounted NFS shares, or to removable media. Is this a huge problem? You'll just get an error that the file is not there, go ah, yeah, click on the icon to mount the share and try again. Most URIs also look like total ass. It depends on what you're used to. And ass or not, being able to access a document on a remote share when it's launched with or dragged to a legacy app trumps it. I'm sure users of e.g. MPlayer or Acroread would thank us. There are also plenty of GNOME apps that never worked with non-local files :) In almost all cases where mplayer or acroread were involved things would work perfectly fine, as you're using a desktop to start said files, so the shares were already mounted. If the file was availible to the user to open, click on, dnd, cut'n'paste, etc then the filesystem is mounted, and there will be no problem. The only case where things get problematic is if a filename was stored in a config file (recent files being the typcial example), and the file is on a share that is not normally mounted in your day-to-day workflow. Also, you're saying that if we can't automount on pathname access then its not useful. However, this can lead to all sorts of problems because the mount operation can do things like open authentication dialogs. Such stateless behaviour is causing problems in gnome-vfs and is what we're trying to move from. For instance, the authentication dialogs will never have the right transient-to information and can easily get lost (especially if the app has a modal dialog up). And during the authentication the application will likely be blocked, not even redrawing its UI, which will look very broken. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a benighted arachnophobic vampire hunter living undercover at Ringling Bros. Circus. She's an elegant hip-hop cab driver with an incredible destiny. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: VFS for legacy apps (was: gvfs status report)
On Thu, 2007-02-22 at 03:10 -0600, Hans Petter Jansson wrote: However, the first method you describe: ~/.mounts/type=smb-share;server=$server;share=$share/dir/file.txt sounds perfect. It's rich (we can get back the mount info later), extensible (we don't have to figure out the entire set of potential mount options in advance) and fairly simple (the root nodes are all direct children of ~/.mounts). You're probably always going to need type, server and share though, so maybe you can make it a bit more readable: ~/.mounts/smb:$server:$share/dir/file.txt Extra options can go on the end. Also I'd probably avoid ';' just in case bash goes anywhere near it. Just a thought, Damon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: VFS for legacy apps (was: gvfs status report)
On Thu, 2007-02-22 at 10:33 +0100, Alexander Larsson wrote: On Thu, 2007-02-22 at 03:10 -0600, Hans Petter Jansson wrote: This won't work. We need to be able to extract all the mount information from the path, so that if the app stores the path across sessions, say, in recent documents, the FUSE layer will know what to do when it's accessed later. I'm just not certain this is true. I mean, we already have this problem with say filenames pointing to unmounted NFS shares, or to removable media. Is this a huge problem? You'll just get an error that the file is not there, go ah, yeah, click on the icon to mount the share and try again. As a further example of this I tried OSX. It has a system similar to the first proposal. I.E. When you mount smb://server/share in the finder it appears as the unix mount /Volume/server;share, and connecting to ftp://ftp.gnome.org/ gives you a /Volume/ftp.gnome.org mount. It handled the recent files case by not showing the recently opened file in the recent files menu when it was on a share that is no longer mounted. However, if I remounted it it appeared again. (Although i did have to restart the app, which is sort of crap.) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's an all-American guitar-strumming gentleman spy who dotes on his loving old ma. She's a mistrustful gypsy traffic cop from a secret island of warrior women. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: VFS for legacy apps (was: gvfs status report)
On Thu, 2007-02-22 at 12:38 +, Damon Chaplin wrote: On Thu, 2007-02-22 at 03:10 -0600, Hans Petter Jansson wrote: However, the first method you describe: ~/.mounts/type=smb-share;server=$server;share=$share/dir/file.txt sounds perfect. It's rich (we can get back the mount info later), extensible (we don't have to figure out the entire set of potential mount options in advance) and fairly simple (the root nodes are all direct children of ~/.mounts). You're probably always going to need type, server and share though, so maybe you can make it a bit more readable: ~/.mounts/smb:$server:$share/dir/file.txt Extra options can go on the end. Also I'd probably avoid ';' just in case bash goes anywhere near it. Sure, those are requred. But say we have two optional things, like user and domain, as in smb:server:share:user:domain. But what do we then do if user is unset, but domain isn't. I guess one could do smb:server:share::domain. Still, it requires very specific handling of each type of share with a specified option order etc. A key=value approach is more generic. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a hate-fuelled arachnophobic Green Beret who knows the secret of the alien invasion. She's a cynical out-of-work femme fatale from out of town. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gvfs status report
David Zeuthen wrote: Writing this patch and getting it into openssh sounds like great Google Summer of Code project for the D-Bus project. All the changes would be to openssh though. Probably a first step is just ask on the openssh mailing list. [1] : such as /var/lib/dbus/machine-id - btw, why isn't the function _dbus_read_local_machine_uuid() public? Wasn't one point of the whole uuid thing that people should use the machine uuid from D-Bus instead of making up their up hacks? You're supposed to use dbus_get_local_machine_id(): http://dbus.freedesktop.org/doc/dbus/api/html/group__DBusMisc.html Also there's a method on the bus to get the uuid of the bus's machine, iirc. Or maybe it's a general method on any peer. don't remember. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: VFS for legacy apps (was: gvfs status report)
On Thu, 2007-02-22 at 13:49 +0100, Alexander Larsson wrote: On Thu, 2007-02-22 at 10:33 +0100, Alexander Larsson wrote: On Thu, 2007-02-22 at 03:10 -0600, Hans Petter Jansson wrote: This won't work. We need to be able to extract all the mount information from the path, so that if the app stores the path across sessions, say, in recent documents, the FUSE layer will know what to do when it's accessed later. I'm just not certain this is true. I mean, we already have this problem with say filenames pointing to unmounted NFS shares, or to removable media. Is this a huge problem? You'll just get an error that the file is not there, go ah, yeah, click on the icon to mount the share and try again. As a further example of this I tried OSX. It has a system similar to the first proposal. I.E. When you mount smb://server/share in the finder it appears as the unix mount /Volume/server;share, and connecting to ftp://ftp.gnome.org/ gives you a /Volume/ftp.gnome.org mount. It handled the recent files case by not showing the recently opened file in the recent files menu when it was on a share that is no longer mounted. However, if I remounted it it appeared again. (Although i did have to restart the app, which is sort of crap.) In fact, its likely they implement this by just stat()ing all the files in the recent list. This is a great example of where automounting would royaly screw things up. Given a traditional unix system there wouldn't be anything bad with a solution like that (in fact, it would be very nice to not show deleted files in the recent menu). However, if any stat can lead to indefinite blocking and displaying of random authentication dialogs you suddenly have to do something much more complicated in order to not suck. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's an impetuous ninja cop who hangs with the wrong crowd. She's a vivacious hip-hop advertising executive in the wrong place at the wrong time. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: VFS for legacy apps (was: gvfs status report)
On Thu, 2007-02-22 at 12:38 +, Damon Chaplin wrote: On Thu, 2007-02-22 at 03:10 -0600, Hans Petter Jansson wrote: However, the first method you describe: ~/.mounts/type=smb-share;server=$server;share=$share/dir/file.txt sounds perfect. It's rich (we can get back the mount info later), extensible (we don't have to figure out the entire set of potential mount options in advance) and fairly simple (the root nodes are all direct children of ~/.mounts). You're probably always going to need type, server and share though, so maybe you can make it a bit more readable: ~/.mounts/smb:$server:$share/dir/file.txt Extra options can go on the end. Also I'd probably avoid ';' just in case bash goes anywhere near it. Yeah - the actual syntax is still up in the air, but we need to define it carefully. Do you think ':' is a good separator? I'm not sure you'll always be accessing a share (subdirectory) on the server. I guess we could make the share be / in that case... -- Hans Petter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: VFS for legacy apps (was: gvfs status report)
On Thu, 2007-02-22 at 13:51 +0100, Alexander Larsson wrote: On Thu, 2007-02-22 at 12:38 +, Damon Chaplin wrote: You're probably always going to need type, server and share though, so maybe you can make it a bit more readable: ~/.mounts/smb:$server:$share/dir/file.txt Extra options can go on the end. Also I'd probably avoid ';' just in case bash goes anywhere near it. Sure, those are requred. But say we have two optional things, like user and domain, as in smb:server:share:user:domain. But what do we then do if user is unset, but domain isn't. I guess one could do smb:server:share::domain. Still, it requires very specific handling of each type of share with a specified option order etc. A key=value approach is more generic. I suppose ~/.vfs/smb:$server:$share/dir/file.txt:option=$value:option=$value is a workable compromise. It might even be what Damon was indicating. Now that we're picking on details, I'd say that .vfs or .gvfs would be a better base directory than .mounts too. -- Hans Petter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: VFS for legacy apps (was: gvfs status report)
On Thu, 2007-02-22 at 14:44 +0100, Alexander Larsson wrote: On Thu, 2007-02-22 at 13:49 +0100, Alexander Larsson wrote: On Thu, 2007-02-22 at 10:33 +0100, Alexander Larsson wrote: As a further example of this I tried OSX. It has a system similar to the first proposal. I.E. When you mount smb://server/share in the finder it appears as the unix mount /Volume/server;share, and connecting to ftp://ftp.gnome.org/ gives you a /Volume/ftp.gnome.org mount. It handled the recent files case by not showing the recently opened file in the recent files menu when it was on a share that is no longer mounted. However, if I remounted it it appeared again. (Although i did have to restart the app, which is sort of crap.) In fact, its likely they implement this by just stat()ing all the files in the recent list. This is a great example of where automounting would royaly screw things up. Given a traditional unix system there wouldn't be anything bad with a solution like that (in fact, it would be very nice to not show deleted files in the recent menu). However, if any stat can lead to indefinite blocking and displaying of random authentication dialogs you suddenly have to do something much more complicated in order to not suck. That's a good point. To make that suck less, you'd probably have to - Immediately deny any access to unmounted shares. - Pop up a dialog asking the user if it should be mounted (if the mount metadata could be converted to a more display-friendly string, such as a URI or even a chosen name, that would be great). - Optionally mount it. The bad part is that the application's access denied and the I think you're trying to mount something dialogs would pop up simultaneously. With gnome-keyring integration, this problem would largely go away, though. In most cases, gvfs could fetch the auth information transparently then go ahead and mount. Sure, it'll block the calling application, but if it's using a blocking open(), it always blocks to some extent anyway. We could make the timeout fairly short (say, 10 seconds) when we know we're dealing with a legacy app. -- Hans Petter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: VFS for legacy apps (was: gvfs status report)
On 2/22/07, Hans Petter Jansson [EMAIL PROTECTED] wrote: ~/.mounts/type=smb-share;server=$server;share=$share/dir/file.txt I just want to point out that there's a freedesktop specification for where things should be stored. Not many seem to respect it, but I, for one, really would appreciate it if people would, as the root of my ~ isn't a junkyard for files and directories. My OCD really needs it to be in order. http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html nikolai ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gvfs status report
On Tue, 2007-02-20 at 21:46 -0500, David Zeuthen wrote: On Thu, 2007-02-15 at 16:54 +0100, Alexander Larsson wrote: Apps talk to the main daemon using the session bus, but most file operations are done using direct peer-to-peer dbus connections between the clients and the mount daemons. Just send a request over the session bus to set up such a peer-to-peer connection, then send normal dbus messages over that connection instead. In most cases this should be fast enough for normal use. However dbus isn't a good protocol for bulk data transfer, so when we're actually reading or writing file content we pass a unix socket fd over the dbus How do you actually pass a socket fd over dbus? (pretty sure it's not possible nor even desirable; see below) Neither is it there a way to set up a peer-to-peer dbus connection, so gvfs has to do this manually. It does so by having a method call that returns an address string that is then passed to dbus_connection_open_private(). (It looks like a typical DBUS_SESSION_BUS_ADDRESS env var value). Now, we actually pass two such strings, one we open with dbus, and the other we open manually to pass fds over. and use a custom binary protocol over that. This lets us do file transfers very efficiently. So one thing to keep in mind is that, just like we do for $DISPLAY, we want to forward $DBUS_SESSION_BUS_ADDRESS (possibly rewriting the address to use TCP like we do for $DISPLAY) when you ssh into another box. This means that applications, physically running on another box but display on your local screen can participate in e.g. inhibiting the screen saver / power management daemon and consume other session services too. Such as service from the VFS :-) Stepping a few steps back, I guess one interesting question is really what *should* happen. So here's a user story. Clearly, accessing file:/// should always access the local filesystem. However, there is nothing that says we can't have a mountpoint like rfile:/// (or whatever) that proxies normal paths from/to the system running the dbus session bus. In such a case we'd have to fall back not only to sending file contents over dbus, but to actually send it via the session dbus daemon instead of peer-to-peer. This will be insanely slow, because the kind of i/o done doesn't pipeline well with the large latency that this will give. For instance, the current gnome-vfs daemon uses peer-to-peer dbus for sending file contents, and gvfs is 250% faster than it when reading a file over smb:///. I imagine a similar 250% slowdown just going via the session bus, and many times slower going over a ssh encrypted tcp-ip connection. But still, it might be worth it in some cases, like in your usecase. On the other hand, in many usecases you're not interested in accessing the shares of the other computer, but want to instead e.g. access an smb host on the network of the logged-in-to computer. In this case the vfs forwarding will actually be hurting. Your examples show shares from both local and remote. That will be truly hard to do. How do you find the other gvfs-daemon if you can't just look at the session bus env var? How do you know which daemon to talk to for smb:///foo/bar? Plus, any global state in the gvfs system gets a lot more complex. Any solution would probably leak out heavily into the API making it cumbersome and complicated for a very limited usecase. Anyway, I think its definately possible to have gvfs fallback on pure dbus communication if local access is not possible, and add a way to access the files of the remote machine via rfile:///. It will be slow as ass, but work. (Of course, there isn't even a tcp/ip transport in dbus atm, so this will be in the star-trek future.) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's an ungodly amnesiac matador with a winning smile and a way with the ladies. She's a sarcastic psychic archaeologist from the wrong side of the tracks. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gvfs status report
On Mon, 2007-02-19 at 17:27 +0100, nf2 wrote:
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...
A stat() operation can take a long time too (say on NFS). But creating a
(probably heavyweight) job for each stat operation doesn't sound all
that useful to me. I think job tracking (when needed) should happen on a
higher level than the pure i/o operation level. All sorts of separate
i/o can be part of a single job (as the user sees it), and a higher
level API for job tracking would make it possible to track all such
different kinds of jobs in one place (i.e. a Mathusalem style gui).
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.
All the i/o operations availible in gvfs right now are lowlevel atoms
really, and don't really have a use for progress info. However, when
slightly higher level operations like file copy are added, some form of
progress info will be needed.
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;
Most of these states are for a stateless system (like gnome-vfs) where
any sort of operation (like authentication or connection) can happen on
any i/o operation (with the corresponding complexities). gvfs is
stateful, so such operations would only happen during mounting.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander LarssonRed Hat, Inc
[EMAIL PROTECTED][EMAIL PROTECTED]
He's a shy shark-wrestling vampire hunter looking for a cure to the poison
coursing through his veins. She's a man-hating belly-dancing pearl diver from
Mars. They fight crime!
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gvfs status report
(adding Havoc to Cc since there's a few D-Bus questions here. For context, the original questions about D-Bus and session bus forwarding is here http://mail.gnome.org/archives/gtk-devel-list/2007-February/msg00092.html On Wed, 2007-02-21 at 10:56 +0100, Alexander Larsson wrote: How do you actually pass a socket fd over dbus? (pretty sure it's not possible nor even desirable; see below) Neither is it there a way to set up a peer-to-peer dbus connection, so gvfs has to do this manually. It does so by having a method call that returns an address string that is then passed to dbus_connection_open_private(). (It looks like a typical DBUS_SESSION_BUS_ADDRESS env var value). Now, we actually pass two such strings, one we open with dbus, and the other we open manually to pass fds over. Clever. Anyway, I think its definately possible to have gvfs fallback on pure dbus communication if local access is not possible, and add a way to access the files of the remote machine via rfile:///. It will be slow as ass, but work. Right; my point was more or less that the gvfs API needs to expose enough information such that we can hack this into the file chooser / other bits if we want such a feature (I think we do). This includes things like rfile:/// URI's I suppose. (Of course, there isn't even a tcp/ip transport in dbus atm, so this will be in the star-trek future.) Actually, as mentioned on IRC, TCP/IP transport been in D-Bus for a long time, it's just not hooked up by default on the session bus nor forwarded by e.g. ssh yet. You asked about how auth will work; that's a good question... Havoc, can you shed some light on the D-Bus session bus forwarding over ssh situation? Thanks! David ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gvfs status report
Hi, David Zeuthen wrote: Actually, as mentioned on IRC, TCP/IP transport been in D-Bus for a long time, it's just not hooked up by default on the session bus nor forwarded by e.g. ssh yet. You asked about how auth will work; that's a good question... Havoc, can you shed some light on the D-Bus session bus forwarding over ssh situation? Thanks! The cookie in your homedir auth method should work fine for tcp/ip if you have a shared nfs homedir, you would just have to add a tcp listen address in session.conf so the session bus listens on tcp. If you don't have a shared nfs homedir, someone would have to add some kind of other working auth method like kerberos or a cookie on the X display. ssh forwarding would work for DBUS_SESSION_BUS_ADDRESS exactly as it does for DISPLAY, and would also encrypt/compress the protocol stream. The problem of course is that someone has to patch ssh. I don't see any good solution other than patching ssh, though. Unfortunately people are just hacking around things by using dbus-launch to give apps their own private bus on the remote system, which in most cases is all kinds of broken - it's just that few apps rely on dbus all that heavily yet, so it's possible to get by without patching ssh. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gvfs status report
On Wed, 2007-02-21 at 22:12 -0500, Havoc Pennington wrote: ssh forwarding would work for DBUS_SESSION_BUS_ADDRESS exactly as it does for DISPLAY, and would also encrypt/compress the protocol stream. The problem of course is that someone has to patch ssh. Yea, so this wouldn't even require the TCP/IP bits. I wonder how a server on the session bus would determine if a caller is remote; he probably wouldn't be able to since ssh would make this transparent. As such, the mechanisms employed by gvfs to set up peer to peer dbus connections / UNIX domain sockets would have to take machine uuid's [1] into account and fall back to session bus communication if server and client machine uuid's differ. I don't see any good solution other than patching ssh, though. Unfortunately people are just hacking around things by using dbus-launch to give apps their own private bus on the remote system, which in most cases is all kinds of broken - it's just that few apps rely on dbus all that heavily yet, so it's possible to get by without patching ssh. Writing this patch and getting it into openssh sounds like great Google Summer of Code project for the D-Bus project. David [1] : such as /var/lib/dbus/machine-id - btw, why isn't the function _dbus_read_local_machine_uuid() public? Wasn't one point of the whole uuid thing that people should use the machine uuid from D-Bus instead of making up their up hacks? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gvfs status report
On Wed, 2007-02-21 at 23:20 -0500, David Zeuthen wrote: On Wed, 2007-02-21 at 22:12 -0500, Havoc Pennington wrote: ssh forwarding would work for DBUS_SESSION_BUS_ADDRESS exactly as it does for DISPLAY, and would also encrypt/compress the protocol stream. The problem of course is that someone has to patch ssh. Yea, so this wouldn't even require the TCP/IP bits. I wonder how a server on the session bus would determine if a caller is remote; he probably wouldn't be able to since ssh would make this transparent. As such, the mechanisms employed by gvfs to set up peer to peer dbus connections / UNIX domain sockets would have to take machine uuid's [1] into account and fall back to session bus communication if server and client machine uuid's differ. It doesn't have to use uuids. It can just fall back to this when opening the peer-to-peer connection fails. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's an ungodly ninja cyborg who dotes on his loving old ma. She's a time-travelling nymphomaniac safe cracker living homeless in New York's sewers. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gvfs status report
On Mon, 2007-02-19 at 18:04 -0600, Hans Petter Jansson wrote: On Thu, 2007-02-15 at 16:54 +0100, Alexander Larsson wrote: A large problem with gnome-vfs is that applications not specially coded to use gnome-vfs will not be able to read non-local files. A nice solution to this would be to use FUSE to let such apps use normal syscalls to access the files. In general its quite tricky to map any URI to a FUSE file, but with the mountpoint + filename setup gvfs uses it is very easy to create a FUSE filesystem that lets you access all the current vfs mounts. Could we standardize the local file system paths for non-gvfs apps, so we can reliably DnD to them and have them receive local paths? E.g. ~/.mounts/protocol/server/path Consider also apps that receive these local paths, store them and reference them in future sessions. I think it would be wise to include such functionality, or at least specifications, if we're going to replace gnome-vfs anyway. It would save worlds of pain in scenarios involving legacy or 3rd party apps. Having these paths map 1:1 to URIs (with translation functions?) would be excellent. It seems you've given it some thought - what are the tricky parts? Its in general very tricky to use non-path properties from the mountpoint as a path. I tried really hard to get it in some sane fashion, but didn't succeed. The main problem is that there is a lot of optional things, but paths don't allow that. Lets take smb for example. It sounds so simple to just go with ~/.mounts/smb-share/$server/$share/dir/file.txt. However, the devil is in the details. What if you specify a different port? a different user? a different domain? For the case where user is specified you might get ~/.mounts/smb-share/$server/$share/$user/dir/file.txt. How do you recognize this form as opposed to the previous case, but with dir being $user. One solution for that would be to enforce a number of path elements enough for all the possible optional settings for the protocol type. Of course, you can't have empty dir names, so you need a magic marker (say *) for that. So, you'd get ~/.mounts/smb-share/$server/$share/$user/$domain/$port, where a typical example would be ~/.mounts/smb-share/$server/$share/*/*/*/dir/file.txt. Not only is this extraordinary ugly, it also have various problems. For instance, what is in these directories? What happens if you try to rename the * to something else. How do we add options to a mountpoint type after we've deployed with some max number of options? Also, things get slightly tricky when parts of the prefix are shared between different mounts. In general, the way mountpoints work in unix is that they are mounted over *one* directory, and don't mix things up with other mounts, so I think the best solution would be to have each mountpoint be one subdirectory under ~/.mounts (or whatever). The question is then, how do we name these subdirectories. I've come up with two plausible versions. One, we use the full mount specification and encode it (with escaping) in the mountpoint name. So, you'd have ~/.mounts/type=smb-share;server=$server;share=$share/dir/file.txt. Two, each mountpoint generates a display name that is used in the gui for the mountpoint. An example for smb would be $share share at $server. This is weakly unique[1] on the same machine. We can make it guaranteed unique in the daemon and use this as the mountpoint name. Like this ~/.mount/$share share at $server/dir/file.txt. The second method isn't really possible to map backwards to the original source of the mountpoint if the mountpoint is not mounted. However in almost all cases where we access a file from it, it will be mounted already, and thus mapped in the same place. So this isn't really a problem in practice, especially since the desktop itself natively handles gvfs mounts. And if its not mounted you can easily display a warning that $share share at $server isn't mounted which is nice and readable. This isn't really all that different to traditional unix mounts. For instance you can't map from a nfs mountpoint like /mnt/bigserver to the exact nfs details of the mounpoint (if its not mounted). The advantage of method one is that you can actually take such a path and extract enought information to mount the path. On the other hand, it looks like total ass. Pray that it doesn't show up in the UI somewhere. [1] I say weakly, because with an example like music share at bigserver as user alex could conflict if you have a server called bigserver as user alex. In that (rare) case we can prepend a number in the daemon, making things really unique. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's an impetuous crooked messiah whom everyone believes is mad. She's a radical snooty bounty hunter with only herself to blame.
Re: gvfs status report
On Thu, 2007-02-15 at 16:54 +0100, Alexander Larsson wrote: Apps talk to the main daemon using the session bus, but most file operations are done using direct peer-to-peer dbus connections between the clients and the mount daemons. Just send a request over the session bus to set up such a peer-to-peer connection, then send normal dbus messages over that connection instead. In most cases this should be fast enough for normal use. However dbus isn't a good protocol for bulk data transfer, so when we're actually reading or writing file content we pass a unix socket fd over the dbus How do you actually pass a socket fd over dbus? (pretty sure it's not possible nor even desirable; see below) and use a custom binary protocol over that. This lets us do file transfers very efficiently. So one thing to keep in mind is that, just like we do for $DISPLAY, we want to forward $DBUS_SESSION_BUS_ADDRESS (possibly rewriting the address to use TCP like we do for $DISPLAY) when you ssh into another box. This means that applications, physically running on another box but display on your local screen can participate in e.g. inhibiting the screen saver / power management daemon and consume other session services too. Such as service from the VFS :-) Stepping a few steps back, I guess one interesting question is really what *should* happen. So here's a user story. Suppose I'm at host foo and log into host bar over SSH with both X / session bus forwarding (this is perhaps just clicking an icon that my sysadmin set up). Perhaps I log into this host because I need to run some app which requires lots of computational power and host bar has 1024 CPU's and host foo is my workstation / laptop. Now, let's assume my app on bar is using the latest and greatest GNOME stack and so is my laptop foo. I run my simulations (say I'm a scientist) and wants to save a file with a digest / report of the simulations. I hit the save icon. Now the file chooser comes up. What does it look like? Right.. well, according to your proposal the app on host bar will start talking to the gvfs daemon over the session bus. In this case this will be forwarded over TCP/IP since the gvfs daemon lives at host foo. So the list of volumes returned will include, most probably, just the local volumes available on host foo. This might include say the user's USB stick. This is actually beneficial for the user in this specific example; he wants to save the 100kb report from the simulation. (Implementation-wise, passing fd's over dbus is now no longer technically possible (doubt it's possible even in the local case) so I guess your implementation needs to fallback to doing I/O over D-Bus.) Actually I think this is desirable. Surely the file chooser on the app on bar needs to be aware of this and perhaps show these volumes on the list on the left Volumes on foo (the computer you're in front of - slow!) Sandisk Cruzer 40MB USB stick Super NAS on bar (SMB) Desktop File system Volumes on bar (the remote computer this application is running on) --- Super NAS Desktop File system (need to trim down the text in parenthesis above - but the message is very important to show so the user can make an informed choice of where to save his report) Of course all this involves marshaling I/O over TCP/IP. That might be slow. But such is life. (bonus question: can we automatically detect that Super NAS on bar (SMB) is actually a local file system if the app running on bar wants to save to it? Cuz that would be somewhat nice!) Btw, I don't think this use-case is at all weird and I think shiny new gvfs should be able to at least have a story for it. Of course, one option is to hide the GVFS D-Bus service under a library that just refuses to talk to the D-Bus service unless it's local. But that's hardly optimal either. Anyway, this is probably a difficult question. Sorry. David ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gvfs status report
On Fri, 2007-02-16 at 09:13 -0500, Dimi Paun wrote:
On Fri, February 16, 2007 02:45, Alexander Larsson wrote:
[ about new API names ]
I'd like to second this -- it's the smart thing to do IMO.
Other well known APIs (Java, .NET, Win32) use a similar naming
pattern, and despite it's functional shortcomings, seems to
be what people prefer.
Oh, I don't know that people _prefer_ it, as such, but people are *used*
to it.
I remember when I first java.io.{*Stream} and friends. I had to struggle
for a short while to learn the various constructs involved. But like
everyone else, I got it eventually. And now, like most of the rest of
working with the standard Java libraries, it's just idiomatic.
And it's usually best to go with the flow for such subjective matters.
I would ordinarily aver to such a statement, as I am squarely in the
camp of not wanting to slavishly copy other environments at the cost of
limiting our freedom to innovate.
In this case, however, I entirely agree with you. A usable pattern is
set, so {shrug}, go with it.
I am, obviously, quite biased about all this, and I accept that, but my
mission in life at the moment is to open our little piece of open source
to new crowds of potential contributors who have, to this point, been
entirely outside of GNOME space. There are zillions of people with Java
expertise, and I'm hoping we can become welcoming to them. While this
should not in any way be the deciding factor in our design choices, if
we can along the way benefit from or integrate with existing experience
bases, then I we will reduce barriers to entry to GTK for GNOME and
that's definitely all to the good.
AfC
Sydney
signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gvfs status report
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,
gbooleanfollow_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 = 18,
VIO_PROGRESS_VALID_COUNT = 19,
VIO_PROGRESS_VALID_BOTH = 18 | 19
} VioProgressValidFields;
typedef enum
{
VIO_PROGRESS_UNIT_NONE = 0,
VIO_PROGRESS_UNIT_BYTES = 116,
VIO_PROGRESS_UNIT_PERCENT = 216,
VIO_PROGRESS_UNIT_ITEMS = 316 /* 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
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gvfs status report
On Thu, 2007-02-15 at 16:54 +0100, Alexander Larsson wrote: In general I think that we will still use URIs to pass file references between apps when doing things like DnD, cut-and-paste or when saving filenames in config files. It seems hard to change this at this time, and it has some advantages in that other applications also understand such URIs (to some extent, vfs uris aren't always exactly like web uris). However, internally in gio we immediately map the URI to a mountpoint spec (which might not be mounted yet) and a path, and all path operations happens in this form. Think of URIs like a serialization form. The mapping from uri to mount spec is done by custom backend-specific code. I arrived at this model after several false starts, and I think its pretty nice. It means the backends and the client implementation get a very clean view of the world, and all the weirdness of strange URI schemes like smb is handled totally in one place in the client library code. A large problem with gnome-vfs is that applications not specially coded to use gnome-vfs will not be able to read non-local files. A nice solution to this would be to use FUSE to let such apps use normal syscalls to access the files. In general its quite tricky to map any URI to a FUSE file, but with the mountpoint + filename setup gvfs uses it is very easy to create a FUSE filesystem that lets you access all the current vfs mounts. Could we standardize the local file system paths for non-gvfs apps, so we can reliably DnD to them and have them receive local paths? E.g. ~/.mounts/protocol/server/path Consider also apps that receive these local paths, store them and reference them in future sessions. I think it would be wise to include such functionality, or at least specifications, if we're going to replace gnome-vfs anyway. It would save worlds of pain in scenarios involving legacy or 3rd party apps. Having these paths map 1:1 to URIs (with translation functions?) would be excellent. It seems you've given it some thought - what are the tricky parts? -- Hans Petter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gvfs status report
On Fri, 2007-02-16 at 08:35 +0100, Alexander Larsson wrote: On Thu, 2007-02-15 at 19:32 +0200, Stefan Kost wrote: Hi Alex, GCancellable GFile GInputStream GInputStreamSocket GFileInputStream GOutputStream GFileOutputStream GOutputStreamSocket GSeekable GFileInfo GFileEnumerator GMountOperation GVfs Just one thing - is this okay with the GLib to use 'G' as a prefix and not e.g. 'GVFS' or 'GIO'? Its certainly nothing new. It goes with the general glib naming of things like GMutex, GThread, GModule, GIOChannel, GArray, etc. Why shouldn't it be ok? If these objects are strongly associated with each other, and not very useful without each other, it would be helpful for them to have common prefixes so they look like part of a sub-system, rather than getting lost in the rest of glib. If they are generally useful individually, ignore this. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gvfs status report
On Fri, February 16, 2007 02:45, Alexander Larsson wrote: I guess this makes some sense. The disadvantages is that its not as obvious which implementations of an interface there are (its not as easy as GInputStream*), but its clearly much easier to read. I'm fine with changing this. What do other people think? I'd like to second this -- it's the smart thing to do IMO. Other well known APIs (Java, .NET, Win32) use a similar naming pattern, and despite it's functional shortcomings, seems to be what people prefer. And it's usually best to go with the flow for such subjective matters. -- Dimi Paun [EMAIL PROTECTED] Lattica, Inc. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gvfs status report
On Thu, February 15, 2007 10:54, Alexander Larsson wrote:
One thing that I'm especially unsatisfied
with is the naming. There is just way too many vfs, daemon and
dbus all over the place.
Speaking of which:
GInputStream
GInputStreamSocket
GFileInputStream
GOutputStream
GFileOutputStream
GOutputStreamSocket
You probably thought about it already, but why not GSocket{Input|Output)Stream?
In general I think naming works good if the interface is named with the
abstract concept, and the implementation is named:
ImpConcept
For example:
interface: GInputStream:
implementations : GFileInputStream, GSocketInputStream,
GByteArrayInputStream, etc.
Consistency help.
That being said, I think a more practical naming would be:
ConceptImp
e.g.
GInputStreamFile, GInputStreamSocket, etc.
that would allow easier completion in IDEs such as Eclipse.
But at the end of the day I would go with Java/.NET naming,
I don't think it's worth going against the grain of what people expect.
--
Dimi Paun [EMAIL PROTECTED]
Lattica, Inc.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gvfs status report
On Thu, 2007-02-15 at 16:54 +0100, Alexander Larsson wrote: In general I think that we will still use URIs to pass file references between apps when doing things like DnD, cut-and-paste or when saving filenames in config files. It seems hard to change this at this time, and it has some advantages in that other applications also understand such URIs (to some extent, vfs uris aren't always exactly like web uris). I don't think gvfs is the right layer to deal with that, but systematically using URIs for DnD is wrong: when you have a window from a foreign computer (after all X11 is networkable), DnD from this window should use some kind of transport-by-X11 protocol, not just transfer the filename. Xav ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gvfs status report
On Thu, 2007-02-15 at 11:19 -0500, Dimi Paun wrote:
On Thu, February 15, 2007 10:54, Alexander Larsson wrote:
One thing that I'm especially unsatisfied
with is the naming. There is just way too many vfs, daemon and
dbus all over the place.
Speaking of which:
GInputStream
GInputStreamSocket
GFileInputStream
GOutputStream
GFileOutputStream
GOutputStreamSocket
You probably thought about it already, but why not
GSocket{Input|Output)Stream?
In general I think naming works good if the interface is named with the
abstract concept, and the implementation is named:
ImpConcept
For example:
interface: GInputStream:
implementations : GFileInputStream, GSocketInputStream,
GByteArrayInputStream, etc.
GFileInputStream is actually an abstract subclass that adds interfaces,
not an implementation. But your point stands.
Consistency help.
That being said, I think a more practical naming would be:
ConceptImp
e.g.
GInputStreamFile, GInputStreamSocket, etc.
that would allow easier completion in IDEs such as Eclipse.
But at the end of the day I would go with Java/.NET naming,
I don't think it's worth going against the grain of what people expect.
Yes. I've thought about this a bit. Or at least noticed it. I'm not sure
what approach is best here.
We already have classes like:
GtkCellRenderer(Text,Toggle,Pixbuf), GtkFileSystem(Unix,Win32)
But we also have things like:
Gtk(H,V)Scrollbar, Gtk(Check,Image,Radio)MenuItem
So, we're not exactly consistent on this atm. I don't know what the best
solution is, but we should decide on something and then stick to it for
all new Gtk+ APIs.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander LarssonRed Hat, Inc
[EMAIL PROTECTED][EMAIL PROTECTED]
He's a world-famous neurotic cat burglar with a winning smile and a way with
the ladies. She's a vivacious Bolivian lawyer with the soul of a mighty
warrior. They fight crime!
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gvfs status report
On Thu, 2007-02-15 at 17:31 +0100, Xavier Bestel wrote: On Thu, 2007-02-15 at 16:54 +0100, Alexander Larsson wrote: In general I think that we will still use URIs to pass file references between apps when doing things like DnD, cut-and-paste or when saving filenames in config files. It seems hard to change this at this time, and it has some advantages in that other applications also understand such URIs (to some extent, vfs uris aren't always exactly like web uris). I don't think gvfs is the right layer to deal with that, but systematically using URIs for DnD is wrong: when you have a window from a foreign computer (after all X11 is networkable), DnD from this window should use some kind of transport-by-X11 protocol, not just transfer the filename. While a laudable idea I'm not sure this is practical, at least not as the main approach. If I drag a directory from nautilus to some other apps, do you really want to transfer the full recursive copy of all files in the directory via X messages? Its not gonna be fast... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a world-famous crooked farmboy who must take medication to keep him sane. She's an enchanted streetsmart archaeologist operating on the wrong side of the law. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gvfs status report
On Thu, 2007-02-15 at 17:45 +0100, Alexander Larsson wrote: On Thu, 2007-02-15 at 17:31 +0100, Xavier Bestel wrote: On Thu, 2007-02-15 at 16:54 +0100, Alexander Larsson wrote: In general I think that we will still use URIs to pass file references between apps when doing things like DnD, cut-and-paste or when saving filenames in config files. It seems hard to change this at this time, and it has some advantages in that other applications also understand such URIs (to some extent, vfs uris aren't always exactly like web uris). I don't think gvfs is the right layer to deal with that, but systematically using URIs for DnD is wrong: when you have a window from a foreign computer (after all X11 is networkable), DnD from this window should use some kind of transport-by-X11 protocol, not just transfer the filename. While a laudable idea I'm not sure this is practical, at least not as the main approach. If I drag a directory from nautilus to some other apps, do you really want to transfer the full recursive copy of all files in the directory via X messages? Its not gonna be fast... Well, if the 2 apps don't sit on the same computer, what else could you want ? Of course, as an optimization if the 2 apps are local to each other, they should just use the current behavior. Xav PS: there has been a few comments on the subject at http://bugzilla.gnome.org/show_bug.cgi?id=171655 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gvfs status report
On Thu, 2007-02-15 at 17:52 +0100, Xavier Bestel wrote: On Thu, 2007-02-15 at 17:45 +0100, Alexander Larsson wrote: While a laudable idea I'm not sure this is practical, at least not as the main approach. If I drag a directory from nautilus to some other apps, do you really want to transfer the full recursive copy of all files in the directory via X messages? Its not gonna be fast... Well, if the 2 apps don't sit on the same computer, what else could you want ? Of course, as an optimization if the 2 apps are local to each other, they should just use the current behavior. Actually, its more than a performance issue. What you really want is the file reference (i.e. filename), not the file contents. The app recieving the filename can do all sorts of things with it, not just read it. e.g. it could stat it, it could statfs() it to see what filesystem type it is on, it could traverse the filesystem up or down, or it could open the file and later save back to the same filename. All of these operations would have to be supported, and you need to be able to save the file reference persistantly, for say recent-files. All in all, that seems hard to do via X. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a scrappy umbrella-wielding werewolf looking for a cure to the poison coursing through his veins. She's a vivacious communist Hell's Angel who don't take no shit from nobody. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gvfs status report
On Thu, 2007-02-15 at 17:32 +0100, Alexander Larsson wrote:
You probably thought about it already, but why not
GSocket{Input|Output)Stream?
In general I think naming works good if the interface is named with the
abstract concept, and the implementation is named:
ImpConcept
For example:
interface: GInputStream:
implementations : GFileInputStream, GSocketInputStream,
GByteArrayInputStream, etc.
GFileInputStream is actually an abstract subclass that adds interfaces,
not an implementation. But your point stands.
Consistency help.
That being said, I think a more practical naming would be:
ConceptImp
e.g.
GInputStreamFile, GInputStreamSocket, etc.
that would allow easier completion in IDEs such as Eclipse.
But at the end of the day I would go with Java/.NET naming,
I don't think it's worth going against the grain of what people expect.
Yes. I've thought about this a bit. Or at least noticed it. I'm not sure
what approach is best here.
We already have classes like:
GtkCellRenderer(Text,Toggle,Pixbuf), GtkFileSystem(Unix,Win32)
But we also have things like:
Gtk(H,V)Scrollbar, Gtk(Check,Image,Radio)MenuItem
So, we're not exactly consistent on this atm. I don't know what the best
solution is, but we should decide on something and then stick to it for
all new Gtk+ APIs.
I think that the past naming pattern (and the one which should be used
all the time) is what the english grammar requires (I am not fond of
english but this is really a convention about naming stuff using the
english language). i.e., GInputSocketStream should probably be renamed
to GSocketInputStream because this is a Socket Input Stream.
regards,
Mathieu
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gvfs status report
On Thu, 2007-02-15 at 19:32 +0200, Stefan Kost wrote: Hi Alex, GCancellable GFile GInputStream GInputStreamSocket GFileInputStream GOutputStream GFileOutputStream GOutputStreamSocket GSeekable GFileInfo GFileEnumerator GMountOperation GVfs Just one thing - is this okay with the GLib to use 'G' as a prefix and not e.g. 'GVFS' or 'GIO'? Its certainly nothing new. It goes with the general glib naming of things like GMutex, GThread, GModule, GIOChannel, GArray, etc. Why shouldn't it be ok? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a notorious crooked sorceror haunted by an iconic dead American confidante She's a virginal extravagent mechanic with the power to bend men's minds. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
