Alexander Larsson wrote:
> 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).
>
Perhaps application developers could be made aware of this mounting
issue by providing special functions in the gvfs api (to make
automouting possible, but in a controlled way).
if (!g_file_is_on_mounted_fs(GFile *f ...))
g_file_try_async_activate(GFile *f...); // will pop up the login
dialog and mount
// ... work with the file ...
Btw, how would you deal with the "operation queued" case, which causes
similar problems...
I tend to understand now why KIO provides async methods only ... (or a
pseudo synchronous, which keep the main-loop iterating). This protects
developers from using the synchronous api and freeze their GUI...
norbert
_______________________________________________
gnome-vfs-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
