Re: Proposal for new src/Imaging architecture

["Michael Wayne Goodman" <goodman m w gmail com>]

Thanks for your work, Silvano!

On Wed, Feb 27, 2008 at 9:17 AM, Silvano <silvanociru gmail com> wrote:
> I'm trying to contribute to resolve the bug 166038
>  (http://bugzilla.gnome.org/show_bug.cgi?id=166038), but while writing
>  a patch I realized that the architecture of the image handling part of
>  F-Spot (files in directory src/Imaging) doesn't fit for that matter.
>  That's why I want to propose some changes.
>
>  F-Spot's is focused on managing photos and the physical container for
>  a photo is mainly a single file. Therefore F-Spot in its present
>  architecture directly identifies a photo with a single file. Most
>  actions to be taken over a photo are taken through the ImageFile class
>  or one of its subclasses (JpegFile, for example), but some other
>  actions to be taken over a photo are directly taken over the file
>  containing the photo (like when a photo is copied to the directories
>  structure proposed by F-Spot). In the actual architecture of F-Spot
>  this assumption is simply right.
>
>  But what happens if we want a photo to be considered more than a
>  single file? For example, a photo with some associated sound. In this
>  case there is a file with the photo and another one (I'll call this
>  file "a backpack file") containing the sound.
>
>  I'm working on a patch with two things in mind:
>  - That F-Spot is able of managing photos that carry backpack files with them.
>  - Adding an extra abstraction level that enables F-Spot managing all
>  kind of files that a digital photo camera can generate (mainly photos
>  and videos).
>  Or simply said, resolving the bug 166038 :) And I would like to know
>  what do you think about it. As I already said, I'm working on it (but
>  very slowly) and I'll deliver the first draft as soon as it's ready.

While it would be somewhat trivial to add support for these backpack
files in F-Spot's internal ImageFile/MediaFile classes, I'm curious
about how it will be stored on disk.  Is it a field in the photo's
exif data?  Is it simply an audio file that has the exact same
filename (but different extension) as the picture it's 'attached' to?
other?  If anybody knows, please chime in.  If it's in the Exif data,
that would be convenient, however what do you do for images without
Exif, like png?  Do these ever have backpack sound files?  If it's
some file-naming scheme, we would either need to check the directory
for the existence of these files every time we want to do a file
operation on that image, or we could store the audio file's filename
in F-Spot's database entry for that image.

Regarding UI changes, these audio files should obviously not be
treated the same as regular MediaFiles, unless they are stand-alone
audio (ie without being attached to an image.  Does this ever
happen?).  By this I mean that they should not be given an entry in
F-Spots browser view.  Rather, we could put a little 'play' or speaker
icon next to images with audio, and have some button(s) for playback.

>  I suppose that some people don't agree with the idea of adding
>  video/sound support to F-Spot. Nevertheless, I want to give it a try,
>  if not for the trunk, at least for myself.

It would be cool if this could be implemented as a plugin, but to do
that we should refactor F-Spot so that ALL filetypes are plugins.
That could be a new feature-request.

>  Cheers,
>  Silvano
>
>  --
>  "Sólo hay una cosa imposible para Dios: encontrar algún sentido en
>  cualquier ley de propiedad intelectual y derechos de autor en todo el
>  planeta" - Mark Twain (1835-1910) autor de "Las aventuras de
>  Huckleberry Finn" y "Las aventuras de Tom Sawyer"
>
>  "Only one thing is impossible for God: To find any sense in any
>  copyright law on the planet." - Mark Twain (1835-1910) "Adventures of
>  Huckleberry Finn" and "The Adventures of Tom Sawyer" author
>  _______________________________________________
>  F-spot-list mailing list
>  F-spot-list gnome org
>  http://mail.gnome.org/mailman/listinfo/f-spot-list
>

Thanks again!  I look forward to seeing what becomes of this.  Take care

-- 
-Michael Wayne Goodman