Re: [Gramps-devel] [Gramps-users] Matching sources and media files

[Nick H. <nic...@ho...>]

Benny Malengier wrote:
> 2009/12/11 Brian Matherly <br...@gr...>:
>   
>> Doug,
>>
>>     
>>> Gerald had an interesting question on
>>> the gramps-users list (below),
>>> and it made me think that we might be doing something
>>> wrong. So, I'm
>>> following up on gramps-devel regarding a related technical
>>> point.
>>>
>>> Currently, we use the file system to store media, and I
>>> think that
>>> that is the right thing to do.
>>>
>>> But, we also require people to manage where those files
>>> are, and how
>>> they are named, and that seems to me to be the issue. (See
>>> the
>>> gramps-user thread for what people are doing).
>>>
>>> What if we continued to use the file system to store the
>>> files, but
>>> Gramps was (optionally) responsible for the naming and
>>> location? For
>>> example, I imagine putting a file "into" Gramps means that
>>> it (or a
>>> copy) is taken, renamed and put into a directory location
>>> of its own
>>> design. Perhaps a flat organizational space, or a more
>>> meaningful
>>> hierarchy. (BTW, we are going to be dealing with this soon
>>> with the
>>> gramps web application).
>>>
>>> Everything would remain the same, but users no longer need
>>> to name and
>>> place the file.
>>>
>>> The downside to this is that if Gramps lost that
>>> association, you
>>> would have no idea what was in the photo. But one could
>>> write an
>>> "exporter" that would save the images by giving them names
>>> based on
>>> title, source, etc. into some directory.
>>>
>>> Does this sound like a viable solution to this issue? I am
>>> just
>>> starting to get my images associated with my gramps data,
>>> so I'm
>>> personally interested in a good solution too.
>>>       
>> I've wished for a long time that Gramps would manage my media files for me. I would be perfectly happy with a flat file repository if I never have a need to look at it.
>>
>> Here are a couple of variations of your idea worth considering:
>>
>> A) Make the media file name start with the the GrampsId or Handle, followed by a delimiter (like an underscore), followed by the title. The name would maintain the human understandable file context, and it would be easy to problematically call up for use in Gramps.
>>
>> B) In addition to storing information about the file in the Gramps database, it could also be stored in the EXIF data for the file.
>>     
>
> Some notes:
> 1/media in Gramps can be jpg, bmp, video, pdf, .... . Tagging is not
> available for all those. Well one could require nepomuk in KDE, but I
> assume that is a dependency that is not wanted :-)
>
> 2/even if Gramps does the filename, the user can still create issues
> by changing directories and filenames. So we remain vulnerable there,
> but that is not different from today and not something we should worry
> about.
>   

I like the ability to store files in a hierarchy that I define and with 
file names that I choose. I can then access them easily from outside 
gramps as well as using gramps.

If I want to protect the files I can always change the permissions on them.

> 3/I would have a look at the workflow of application like F-Spot or
> digikam. I only know digikam myself. You have a directory you set
> where your 'Pictures are', that directory is scanned, and everything
> present is also present in digikam, importing pictures places the
> pictures directly in a directory where you want it according to some
> present naming scheme (for pictures normally date-hour related).
> Applying this to Gramps:
> */the relative media path is where the media are
> */one can request a scan of it, every media present obtains a media
> object entry. Not sure this is a good idea
> */one can 'import' media into Gramps, which moves a copy into the path
> Gramps stores them.
>
> Note further that with the general treeview, we could make a sorting
> of media so as not to see a flat list in the media view, but instead a
> treelist that looks more like how you would organize media on your
> directory. This could be a top grouping on media type.
>   

This is a good idea. We could display the media as a tree - the root 
would be the relative media path.

We could display files in the path that are not media objects in a 
different colour and make it easy for the user to add them into gramps.

We could also highlight media objects that are not below the relative 
media path.

Nick.

> Benny
>   
>> ~Brian
>>
>> ------------------------------------------------------------------------------
>> Return on Information:
>> Google Enterprise Search pays you back
>> Get the facts.
>> http://p.sf.net/sfu/google-dev2dev
>> _______________________________________________
>> Gramps-devel mailing list
>> Gra...@li...
>> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>>
>>     
>
> ------------------------------------------------------------------------------
> Return on Information:
> Google Enterprise Search pays you back
> Get the facts.
> http://p.sf.net/sfu/google-dev2dev
> _______________________________________________
> Gramps-devel mailing list
> Gra...@li...
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>
>
>