Re: GMountOperation issues

[David Zeuthen <david fubar dk>]

On Fri, 2009-02-13 at 00:07 -0500, Matthias Clasen wrote:
> >  - What should happen if the resource that the user is trying to mount
> >   is removed while the authentication dialog is being shown?
> 
> I think the best behaviour depends on what kind of mount we are
> talking about. For a local device like a usb stick, making the dialog
> just go away
> is right. For a network device that may disappear 'spontaneously', it would
> probably be better to show an explanation before instead of just hiding
> the password dialog.
> Just leaving the password dialog up is wrong in any case :-(

Yeah, if a backend want that to happen they can return something other
than G_IO_ERROR_FAILED_HANDLED. It's probably worth elaborating in the
docs.

That said, I don't think we currently watch NetworkManager events for
networked backends and I remember Alex saying something about that we
shouldn't; instead we should just return IO errors (something about the
loss of network would be a transient thing). I don't know.

> >  - GtkMountOperation hardcodes the word "Connect" in the user interface.
> >   This is not really helpful for things like LUKS devices where a
> >   better word would be "Unlock" or "Decrypt" or something else. It's
> >   also sort of a detail so I don't know if we want to throw API at
> >   fixing this.
> 
> Hmm. What kind of api would you envision for this ?
> One option would be to pass some additional hints via
> GAskPasswordFlags, like G_ASK_PASSWORD_DEVICE_IS_ENCRYPTED.  But I
> agree, it seems like a detail.

I'm not really sure. It would have to be abstract since we don't really
know how the concrete GMountOperation is going to work. So games like
passing a localized string is not going to work.

Btw, I think it's probably a mistake / hack to use a GVolume for
encrypted block devices and overloading the mount() method with
decrypting/encrypting it. Especially since the effect is that the
GVolume that you just "mounted" disappears since we want to show the
cleartext GVolume instead.

Maybe it would be better to have a GEncryptedVolume interface with
methods like

 unlock_volume (GUnlockOperation op)
 lock_volume ()
 change_passphrase ()
 has_saved_passphrase ()
 forget_saved_passphrase ()
 get_name ()
 get_icon ()
 is_unlocked ()
 GVolume get_unlocked_volume ()

since it would allow much richer integration into a file manager. E.g.
you would be able to provide context menus, cluebars etc. to provide
easy access to managing pass-phrases.

Then on the GVolumeManager class you'd want

 get_encrypted_volumes ()
 ::encrypted_volume_changed
 ::encrypted_volume_added
 ::encrypted_volume_removed

Then again all this is a bit specialized and, perhaps, over engineered.
I can't really imagine other users than encrypted block devices.

And it's probably to late to do this for 2.25/2.26 but we can do it for
2.27/2.28.

> > Btw, another feature from gnome-mount that I need to teach the
> > DeviceKit-disks GVfs backend about is showing a notification if
> > unmounting turns out to be taking a long time [2].
> >
> > The naive solution here is to just make the volume monitor process poke
> > the notification daemon using D-Bus. However, I'm wondering if we want
> > move this functionality to Nautilus or maybe throw some API at it? I
> > don't know.
> 
> It would be nice to show the warning message inside the nautilus
> window where the unmount was initiated. But the most common case is
> probably unmounting from the desktop. And for that case, the bubble
> should be fine.

There's also other users to care about

 - the panel
 - gedit
 - volume mount applet
 - gtk+ file chooser

and they would all need to implement this as well. I don't know.

    David