Re: Fwd: Album Support

[Sam Barker <sam quadrocket co uk>]

On Thu, 2006-08-31 at 18:54 +0200, Ben Monnahan wrote:
> This was meant for the list.
> 
> ---------- Forwarded message ----------
> From: Ben Monnahan <monnahan gmail com> 
> Date: 31-ago-2006 18:50
> Subject: Re: Album Support
> To: wjbaird alumni uwaterloo ca
> 
> 
> 
> 2006/8/31, Warren Baird < photogeekmtl gmail com>:\
>         
>         I think that the consensus is that either Library or
>         Collection should
>         be used to refer to completely separate sets of photos with
>         their own
>         f-spot.db, and that Album should refer to a sorted collection
>         of photos.
> 
> 
> I don't think that has been decided at all.  Yes the different
> DB/Photos we are calling Libraries or Collections.  Album is still up
> in the air in my mind.  I see two definitions not counting the first
> (maybe its so vague that it barely means anything) 
> 
> 1. Warren + (cant remember who): Ablum is a sorted collection of
> photos (tag + sort items)
> 2. Ben + John: Album is a collection of photos that comes from an
> inherent grouping.  This allows us to use it as the dir under Photos.
> (tag + import dir) 
>  
> That being said, I don't necessarily see why we couldn't have both.
> Why not allow ordering for any tag for example?  Whatever we call each
> one, if it is album it will require some kind of explanation, because
> as we've seen there have been at least 3 different uses of Album. 

As has been said somewhere else a tag is an attribute of the photo not
of a collection/group/set (trying to avoid connotations here). Unless
you mean order by tag, in which case having a hierarchy works nicely.
I've been doing a lot of work recently with creating enumerations and
this sort of stuff is fun.

> 
> 
> 
> 
>         > At any rate, I don't know that I'd really use either
>         feature, to be 
>         > honest. Does anyone personally have a need for it? Maybe
>         calling it a
>         > 'slide show' would be more clear to people?
>         
>         I use the Library/Collection feature a lot - I implemented the
>         initial
>         patch, because I needed this functionality.
> 
> This is a more advanced feature, but useful to lots of people.
> Hopefully it will be visible for those who want it and nearly
> invisible for the rest.  Like Warren says we are renaming this
> feature. 
> 
> 
> 
>         If it was available, I'd love to be able to create a sorted
>         album of 
>         photos.   The one time I created a web gallery using f-spot,
>         it really 
>         annoyed me that I couldn't manually order the photos the way I
>         wanted.
>         When I upload pics to flikr, I have to do them a few at a time
>         to get
>         them on flikr in the order I want.
> 
> Is this and ordering you would want to keep around, or just for the
> upload?  I've never wanted anything but chronological ordering. 
> 
> 
> 
> 
> 
> Responding to previous emails (I'm without internet so my responses
> are a bit delayed)
> 
> Warren: Birthdays isn't an album in my view.  Thats a tag, just like
> Frank or Boston.  It doesn't describe its essence just something about
> it.  Why couldn't Birthdays just be a tag?  Would your use case be
> satisfied if we allowed ordering of all tags? (ordering defaults to
> chronological as now) 
> 
> Something to lighten the mood:
> Anyone else think its funny that flickr refers to an ordered
> collection as a 'Set'? :)
> 
> John: the reason we need to make it one album/whateverwecallit per
> photo is because that is how it would be stored on disk.  We could
> maybe workaround this somehow with symmlinks or the like. 
> 
> For those of you who like heirarchies:  Isn't the reason everyone is
> switching to tags to get away from them?  They don't always fit neatly
> into hierarchies because they would often go in 2 places.  Not to
> single out Sam, but his heirarchy for Photos looks like this:
> 
> 
> ~/Photos
>  |-- 2005
>  | |-- October
>  |-- 2006
>  | |-- August
>  |-- Birthdays
>  | |-- Sam's
>  | | |-- 2004
>  | | | |-- October
>  | | |-- 2005
>  | | | |-- October
>  | |-- 2006
>  | | |-- June 
>  | | |-- September
>  |-- Brian's Stag night
>  | |-- 2005
> 
> 
> 
> There are pictures from 2005 all over the place, yet there is a
> directory Photos/2005.  From my POV it would make the most sense to
> get rid of Birthdays (tag not album) then put "Sam's Bday" either at
> the top level or in 2004 (earliest photo is 2004).  I personally
> wouldn't lump all Sam's birthdays into one  album (I'd have separate
> albums for each and link with a tag if necessary)  because they are
> separate events, but I could see how some mike like it that way.
> Especially if they wanted albums by theme.  Flowers, Rivers, Lakes
> (again I think these are tags, but this would left to the user) 

I don't mind being singled out, I was trying to give a concrete example
as a straw man to be pulled apart. Its not how I would actually organise
things personally, but I was trying to illustrate how the album + Y/M
structure would work. 

As I see it there are two different ways to think of albums. 
1) A physical collection. I.e a folder on disk.
2) A logical grouping. 

1) Is good for those people who do not want to just view their photos
through f-spot but manipulate the file system directly. However as has
been pointed out several times a photo can only be in once place.

2) F-spot has a database, so let it do what it is really good at,
relationships. (I'm not familiar with the f-spot schema or code I
haven't found the time). I would have one table of photos, another table
of albums. The second table would contain things like a list of photos
used in that album (as references to the photos table) some ordering
mechanism for that album, and a name and description. Any other
interesting meta data, like say the last time the album was exported, or
used in a slide show. With this sort of solution (I didn't give the
table design any thought, again its just an example) the album doesn't
care how the photos are organised on disk. Each photo can appear in N
albums without any confusion. 

It is probably more sensible to have 1 table per album but that gets
awkward in other ways.

There is no reason why you can't have ordering in either solution, but I
think is important to see an album as more than just an ordered bunch of
photos. It should be a logically connected group, the connection is up
to the user but a great way would be to base it on tags.

So I could have a Family birthdays album which contained all photos
tagged as mum's birthday, dad's birthday (events), or dated 3rd of
October. If this sort of solution is implemented all sorts of funky
things happen for free, most of them we haven't thought of and might not
consider cool but user X does. My idea is that an album is like a
virtual folder in evolution. 
 

> 
> 
> All questions are serious (except the Set one) and not meant to be
> rhetorical.  I'm actually interested in the answers because I'd like
> to understand what people are looking for.
> 
> 
> (back to the land of no internet) 
> 
> My 2 cents
> Ben
> 
I'll second that, this is turning into a fascinating discussion.

Sam
> _______________________________________________
> F-spot-list mailing list
> F-spot-list gnome org
> http://mail.gnome.org/mailman/listinfo/f-spot-list