Dan Winship wrote: >>As a consequence of the stateful model we don't need the stateless >>properties that URIs has as identifier. To avoid all the problems >>comming from the use of URIs we use a much simpler form of >>identifier. Namely filenames > > We still need to support URIs too at least in some places, because of > '%u' in .desktop files. If GNOME apps switched to using '%f', then > konqueror (and old versions of GNOME) wouldn't be able to pass remote > files to them any more. Likewise, if nautilus/libgnomedesktop didn't > support using URIs for remote files any more, then they wouldn't be able > to pass remote files to KDE apps.
I think URI should still be used to refer to resources "from outside" and to contact the appropriate backends. But internally GFile or GFilePath objects should be used. That is, the user types in an URI, the library resolves the URI to a GFile and passes a serialized form of the GFile to the daemon. For example, in the Xfce file manager, we use a path object exactly this way, where an URI like trash:///something-0/file would be resolved to the following path object: path(file) -> path(something-0) -> path(trash root) using refcounting to keep parents only once if possible. Each path object has a parent pointer (which is NULL for the root of an URI scheme), a refcount (excluding the upper bits for the URI scheme) and the name of the path item. Determining the parent path or resolving a relative path is easy then, as you don't need to unescape/escape URIs, but work on path objects with well defined semantics. This way, the possible gvfs would still be compatible with the existing specs (i.e. the thumbnail spec, desktop entry spec, ...), but internally the applications/backends would use the easier to handle path objects and don't need to care about escaping/unescaping of URIs. Not to mention that this would also help to save some memory. Benedikt _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
