Re: Changes to GtkFileSystem API

[Hans Breuer <Hans Breuer org>]

At 12:55 23.01.04 -0600, Federico Mena Quintero wrote:
>On Sun, 2004-01-04 at 09:40, Hans Breuer wrote:
>
>Hi, Hans,
>
>I'm terribly sorry; I don't think I ever replied to this mail of yours
>:(
>
No problem, take your time - I need mine often enough as well ;-)

>> >void (*volume_free) (GtkFileSystem        *file_system,
>> >		     GtkFileSystemVolume  *volume);
>> >
>> The method name makes me shudder, but of course I only need to 
>> implement and not call it ;-)
>> But serious : wouldn't it be much cleaner to make GtkFileSystemVolume
>> a gobject or do you think it's overkill ?
>
>Hmm, I'm not sure.  Things like language bindings are not going to ever
>see this, as these are internal APIs.  If for Windows you think it would
>be better to have it refcounted, I can turn it into a GObject.
>
Currently it seems not to matter much, but I haven't looked into
issues like GtkFileChooser is open and displays a directory from
a CD which than gets removed while the dialog is still open.

> [...]
>> >gboolean (*volume_mount) (GtkFileSystem        *file_system, 
>> >			  GtkFileSystemVolume  *volume,
>> >			  GError              **error);
>> >
>> The win32 (as the Unix) imlementation simply return FALSE here. Maybe
>> with 'Network Volumes' there could be done something useful here.
>> Dynamic mounts are done automagically on windoze, so I'll probably need
>> to take a deeper look into the volumes_changed signal, if I unterstand
>> it's use case correctly ...
>
>The idea is this:
>
>populate_volume_list ()
>{
>  list = gtk_file_system_list_volumes();
>  foreach (v in list) {
>    if (is_mounted (v))
>      put_volume_in_gui (v);
>    else
>      put_grayed_out_volume_in_gui (v);
>  }
>}
>
What I meant was the following use case :
- File Dialog is open
- Users tries to locate some file on CD or at a pluggable harddisk
  and changes them until found.

The common windows pattern is to simply eject the CD and enter
a new one. So it might be handy if the file system implementation
could emit a signal to tell the GUI that some of the volumes
have changed (invalidated). And the GUI could magically update
to the new conditions.

>And when you activate a volume by double-clicking on it in the GUI, it
>calls gtk_file_system_volume_mount().  The GnomeVFS implementation would
>attempt to mount a floppy, for example.  I guess the Windows version can
>always consider local volumes to be mounted, so volume_mount() will
>never be called at all.
>
Again another example :
- User has saved a bookmark to an external USB drive which is not
  plugged in during a subsequent file dialog opening.
- The bookmark could be displayed as 'not mounted' and may even
  give a hint what device to plug-in

>I don't know how Windows handles network shares; please do tell me if
>the GtkFileSystem API does not play well with the way they are handled.
>
There are two different approaches. The older one being to map a network
path to a drive letter. This one already works with the current
implementation (and even shows the new network icon).

But the newer one simply uses UNC pathes of the form

\\server\share\some-directory

I started to look into the required win32 api for at least displaying
them in the volumes list. But to really support those there probably
need to be some changes on the GLib _and_ application level. Not sure
if it's worth the trouble ...
 
>> For API symmetry shouldn't there be a volume_umount as well. With say an
>> usb harddisk there could be done something useful on win32, though I'm
>> not sure it's worth the extra hoops require.
>
>I thought about that, but I don't think even the Mac allows you to
>unmount a drive from the file chooser dialog.  People will have to
>unmount things from elsewhere in the desktop, presumably the file
>manager.
>
At least on osx 10.3 there is a little eject button for 'umount-able'
volumes in the file dialogs, see :


[...]
>> GtkFilesSystemWin32 does work again, too. With one regression :
>> The currently win32 only (easily shareable in source) ~./gtk-bookmarks
>> implementation is not working anymore. Appears to be related
>> to the shortcuts_add_bookmarks/shortcuts_append_bookmarks change
>> in gtkfilechooserdefault.c
>
>Owen says that Windows may have its own way to handle bookmarks for its
>file dialog.  If this is the case, GtkFileSystemWin32 should use that
>Windows API, not its own ~/.gtk-bookmarks.
>
There indeed seems to be such an API [starting from 
SHGetSpecialFolderLocation(.. CSIDL_FAVORITES ..)] but at least 
I did need about 5 Years to even notice there are 'bookmarks' in
some win9x (98se) file dialogs already.

Also really using it would force us to use some Explorer COM interface
which would involve either COM programming in C (urghh). Or some
C++ files in Gtk. For me neiter of these options looks like worth 
the trouble - just to enable an IMHO questionable feature (sharing
favourites with IE and other windoze programs).

>> >I have not removed the "list_roots" method and the associated signal
>> >because I still need to convert GtkFileSystemModel.
>> >
>> I'm looking forward to this change to remove some ugly code duplication
>> in gtkfilesystemwin32.c.
>
>Done :)
>
Thanks,
	Hans

-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to 
get along without it.                -- Dilbert