Re: RFC: preview files

[Alexander Larsson <alexl redhat com>]

On Fri, 2008-10-17 at 08:07 -0400, David Zeuthen wrote:
> On Fri, 2008-10-17 at 10:33 +0200, Alexander Larsson wrote:

> > In my initial design of GIO/GVFS I thought about a similar but not
> > identical case: custom icons. Take a http location with a favicon set
> > for instance. You want to specify that the location has an icon, and you
> > want to allow the file manager to do the I/O required to get the bits
> > required to render the icon. In some backends the icon is not
> > expressible as a uri, and the plan in this case would be to return a
> > custom GIcon object implementing GLoadableIcon, that internally contains
> > some sort of gvfs-backend-side-specific id. If you then call
> > g_loadable_icon_load() we'll open a direct stream to the icon bits.
> 
> Or maybe, for specialized backends, they use the yet-to-be-written
> GPayloadIcon that contains the icon data in the actual object (maybe
> having such a class is a terrible idea, think serialization etc.).

Such an icon could be useful, and having it derive from GLoadableIcon it
should work for all current renderers. However, its not generally a good
idea to use it, as just creating such an icon would require doing i/o to
load the whole icon data, and then passing it via some (generally
inefficient) marshalling.

> > This could be used for previews too, thus avoiding pollution of the
> > filesystem with virtual files.
> 
> Sounds like a pretty nice idea and looks like the file attribute stuff
> already supports icons as an attribute. So we'd just have a
> preview::icon attribute of type GIcon?

Yeah. That should work.

> I think, for gphoto2, it will just point to the URI of the file appended
> with #gvfs-gphoto2-preview or something. Then I just make lookup_info()
> and read() handle it in my backend.

I don't see any reason for it to have a URI at all. Generally we try to
avoid using uris in the backend, and use mounts and pathnames on that
mount. We should just have a GVfsIcon type that contains some string
identifier parsed by the backend and a new separate vfs operation to
open a stream to said icon identifier. For the gphoto backend it would
just give the filename as the identifier.

> Btw, how do we ensure this attribute isn't copied when using
> G_FILE_COPY_ALL_METADATA? Do we need G_FILE_ATTRIBUTE_INFO_NEVER_COPY?

As long as the target doesn't say it supports writing the attribute it
will never be copied. And i don't think writing to preview::icon makes
sense ever.