Re: RFC: preview files



On Fri, 2008-10-17 at 10:33 +0200, Alexander Larsson wrote:
> On Wed, 2008-10-15 at 22:04 -0400, David Zeuthen wrote:
> > Hey,
> > 
> > So one interesting feature of digital cameras is that they're capable of
> > generating thumbnails on the device side. This is actually pretty useful
> > when importing photos; instead of downloading hundreds images (each
> > 5-10MB on my Canon EOS 5D DSLR) for the import dialog, one can download
> > the previews (typically ~10KB of size 160x120).
> 
> I think this is a nice feature. However, I think its somewhat ugly to
> expose the preview as a separate file in the namespace. For instance if
> you do a recursive copy of the directory with the files in it you'll get
> a copy of the thumbnail files. 

Yeah, good point, I didn't think of that.

> 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.).

> 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?

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.

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?

> Btw. Your uri generation code is wrong, you need to escape the directory
> names, etc.

Nice catch, thanks.

     David




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]