Re: Changes to GtkFileSystem API

[Federico Mena Quintero <federico ximian com>]

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
:(

> >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.

GtkFileSystemUnix returns simply a non-null cookie for a volume, and
g_free()s it in the volume_free implementation.

In contrast, GtkFileSystemGnomeVFS always returns (casted) pointers to
GnomeVFSDrive or GnomeVFSVolume objects.  It always gets pre-reffed and
unique objects from GnomeVFSVolumeMonitor, so the volume_free
implementation simply does gnome_vfs_volume_unref() or
gnome_vfs_drive_unref().

The volume objects are intended to be short-lived in the actual
GtkFileChooser implementation --- you never keep them around, just get
them within a callback, extract the base path info, and free them right
there.

> >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);
  }
}

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.

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.

> 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.

The problem in the file chooser is, how would the user unmount things? 
Double-clicking on a volume to show it in the file list can
transparently mount the volume, as it does now; the user doesn't even
know that under the hood there is mounting going on.  But for
unmounting, I prefer to delegate it to the file manager or an
automounter; with the latter the GtkFileSystem implementation should be
able to emit the appropriate volumes_changed signal.

> 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.

> >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 :)

Sorry again for not replying to this before.

  Federico