[KPhotoAlbum] order criteria for a family photo collection

[Heinz Kohl]

Am Dienstag 06 Februar 2007 12:33 schrieb jedd:
> On Tuesday 06 February 2007 3:20 am, Heinz Kohl wrote:
>  ] - A main collecting criterium of me is the scan number of the photo.
>  ]   I've maintained it as part of the file name ..
>  ]   It should be possible to seek and sort for this collection criterium.
>
>  I suspect part of the problem - outside of you wanting to use an
>  arbitrary sorting mechanism that few other people have need to
>  adopt - is that your most significant data, within the filename, is
>  located at the wrong end of the filename.

No, the first.
A file is a self supporting entity, here for a photo, which I want to give 
away alone or in different collections.
Main goal of the filename is therefore human readibility of the file name,
and the natural ordering should be devoted to human needs.
No visitor of my collection but me will see any necessity to look for a scan 
number.
A very bad restriction is the max length of 60 chars for usual DVD file name 
storaging.
Because of that its necessary to crimple down the information to file names 
like Kreilenborg29.3.1955OmiTLeniOHeinrichRobertBernd-1354.gif
It would be strange to see another file mainly devoted to Kreilenborg, but 
scanned as number 2137, far away in directory order.

No, the second.
I want only to make use of the usual sorting and key building mechanisms.
Here it's a databank problem:
A databank is needing a main key, and it is allowing secondary keys.
Sorting is a totally other problem than keying.
Data should be keyed using a problem oriented key.
Not all, in fact nearly no databanking is done following a primary key bound 
to time.

No, the third.
Time is nothing but an arbitrary key, and as a key sometimes without the 
primary key feature unambiguity.
Showing all photos is following the primary key, and that's fixed to time in 
KPhotoalbum, even when time data aren't showing the necessary sequential 
structure.

No, the forth.
KPhotoalbum is at last following the directory ordering - scan numbers at the 
beginning would lead to a crazy succession - I've scanned unordered 
negatives.

As an IT man I say: 
It's definitely the wrong way for humans 'to help the computer' - goal of 
computer programming is to help humans.
Trivial operations have to be machine operations.
Base data should be:
1.) human oriented in a best possible way
2.) human oriented in a best possible way
3.) including the possibility of EDV use with strict respect to 1. and 2.
Think about a former colleague, say Ohm, who was naming his variables, 
constants and functions Ohm1, Ohm2, ... , Ohm3475, ...
On the sight of a computer this is absolutely equivalent.

If, some days later, your grandchild is seeing a collection of files named 
000001.jpg to 999999.jpg on a blue ray disc - do you really expect, he will 
realize to have found the lost family photo album?

>  I'd encourage you to play around with KPhotoAlbum a bit more and
>  become comfortable with the various other powerful features of
>  the application, before you finish evaluating it.  It's possible that
>  it can't / won't do what you want, ..

I've analyzed the structure of the index file, that's totally enough for this 
goal.
This structure, though obviously a bit too fixed and somewhat thin, is more 
one of the better sides of KPhotoalbum, but could be much more worth without 
the unnecessary fixations.
O.k., there is a big bag of nice features (wanted to look for some, but I had 
to port the directory to another temporary disc place because of space 
limitations, and now I've to help KPhotoalbum manually to find the new 
location without destroying the index file - o.k., 'same procedure as every 
year').

I'd be happy with it, if the human interface would be as good as the idea and 
the conception. But I'd need at least 3 totally different installations of 
KPhotoalbum - one for the tiny historical archive (a 2050 pictures, index 
file, now 1 MB estimated to grow to 10MB), one for my very modest analog 
album waiting for scan (a 30 000 pictures) and some for different series of 
digital photos (there's less than no benefit to mix inbetween macro photo 
archives, family archives, art collections and landscape archives).
Sorry, even a very tiny 2000 photo album is setting up some efficiency problem 
- but more than that severe organisatorial and handling problems devoted to a 
theoretically sufficient interrogation management with no respect to an 
optimised man-machine interaction beginning at the stage of (sub-)window 
management.
Take a look to professional CAD programs: every handling step is evaluated, 
the trained CAD engineer isn't even looking for a button - he's feeling where 
to go with the mouse having eyes only for his construction just like a car 
driver, who's never busy in seeking the actual place of brake or steering 
wheel - he's just looking to the ongoing landscape photo show.