On Thu, 2007-05-03 at 10:14 +0200, Alexander Larsson wrote:
> The way a normal application uses gvfs is by the gio apis. Essentially
> you hand over a uri, and this uri is parsed by custom uri-type specific
> code into a mount specification (info about a gvfs mountpoint) and a
> path into it. Each operation on this mount is sent to the right mount
> daemon for the particular mount, and if its not running it will just
> give a NOT_MOUNTED error.
Thanks for the explanation. Do you expect apps using the gio API's to
save the URI's (for e.g. recent files or a media database)? If so, they
need to handle NOT_MOUNTED the next time they start up and load the URI
from recent-files etc...
> In the case when the media was not mounted one would get
> NOT_MOUNTED errors from gvfs. These errors are normally handled by the
> file manager or the file selector and
Is there utility API so these apps (and both the file chooser and
Nautilus) can use the same code [1]? The implementation of such
(blocking) utility API should probably just be an D-Bus session bus
service [2] (that would/could be activated on demand) under the hoods..
David
[1] : One of the things I dislike about current gnome-vfs is that apps
themselves get to display the error dialog which is a source for
inconsistencies... For example, the one used by Nautilus and the one
used by gnome-vfs-daemon don't look the same.... which is annoying.
[2] : Since mounting/connecting the "media" might require asking for
credentials you really want the code asking for this to be in a separate
process... much like how gnome-keyring works ... in the future that
helper process can be labeled with a trusted security context (or on
non-SELinux you can look at exe paths) which means you can protect that
window from input-event-stealing and even apply fancy WM decorations
etc.. e.g. all the XACE work.
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
