[KPhotoAlbum] a working photo interface

[Heinz Kohl]

> To all of the other participants in this thread, I would like to say that I
> applaud your restraint.  Heinz has been sufficiently aggressive with his
> criticism that on many lists someone would have responded with a flame. 
> It's very nice that the KPA community doesn't act like that.
>
> 	Shawn.

Sorry, it's not my interest to be boring, sorry, if I'm acting as aggressive.

It's time for me to show a working user interface.
Just to show, what's possible.
I'm hoping, this will work better.

Of course, what I'd suggested is much, much simpler, but look at 
    http://www.fkohl.de
just to see some impression.

That's a one man project. Software and pictures.
The author didn't  find any usable tool on the market.
It could be your turn to change that.
You would make me glad, if I could help you to go in this direction.

What about this man machine interaction?
How many windows flowing around do you see?

Sorry, but now back to KPA.
Don't be depressed.
Not anybody is wanting to work so hard to present his data.

Your tool shouldn't be positioned for people like him but also for those like 
me accepting low standards in presentation.
And it should work as if they had higher standards.
That's not easy.

O.k., the theoretic concept of KPA is working and o.k.
I was expecting, that the remaining main weaknesses of the concept would have 
been removed soon, and that the painstaking fine work belonging to the man 
machine interaction would have been started soon.
I'm seeing no trend in such a direction.

In this case a trend toward Databanking may be seen as an oneway risc.
Nice and necessary, but -
I'm nearly the only one in the family using linux, most are using Mac, some  
Windows.
Using linux I'm handicapped by the many incompatibilities given by imperfect 
and nonstandard graphic file encodings given by Sane, Gimp and other 
graphical linux tools, even under known names like tif, gif and jpg, which is 
making it complicated to interchange graphical data with the programs of the 
international graphical software leaders (e.g. Photoshop!).
My children, graphical professionals, are reporting about .jpg's and .gif's 
from me, which could be viewed only in firefox and .tiff's, which are 
overstraining even market leader graphical analyzing programs, hardened for 
extreme defective and even partial graphical data.
On a long term this can make my photos unreadable.

And my confidence in flexible, easy portable linux software conforming to 
standards is not grown in the last days.

Am Mittwoch 07 Februar 2007 23:38 schrieben Sie:
> No, you can use multiple KPA archives.  Doing so could perhaps be made a
> bit easier if KPA were to prompt for which of the archives you want to use

Indeed - there's not at all a theoretical problem, but a bad human/machine 
interface. The usual solution - startup with a default page; address line in 
the browser and  open-dialog to change it dynamically - would solve it. Every 
PC user is trained to work in that manner.
I't would therefore be the only solution to do so.

> > And it is lacking a method to implement other than explicitely defined
> > enumeration data.
> I don't think I understand this comment.

Would it be naturally to make an explicit categorization entry for every 
second, for which a photo is existing, before referring to this second?
Would you expect to find any second, in which a photo is taken, in an 
unordered (or manually ordered) explicit list of seconds?
(Of course, an internal list may exist ...)

Would it be more naturally to use such an entry, when it's a successive 
natural numbering?
Would it be more naturally to use such an entry, when ordered strings are 
used?
Would it really be natural to make a category entry, which will be used 
exactly once, just to make possible another order than a time based order?

Is it naturally to use a (time-)slider holding a prominent place having no 
equivalent tool, because the part of an order key criterium is strictly bound 
to time, even in absence of usable time information?

Is it naturally to do totally with unordered data, when there is no time order 
but e.g. a natural number ordering?

And, there's a further lasting problem: how to navigate in such a number heap?

My example using KPA:
up to now only 10 Categories (following to the proposals I had to implement a 
10 more).

To make an entry is posing the following problem, description only of the very 
first phase:
   upfolding of all categories.
       result: 10 windows, one over the other
        all at address (0,0), upper left corner
    appopriate positioning of all windows (min. 30 seconds).
**saving of the settings (worthless - X is ignoring global window positioning, 
and that's so in most implementations since the founding of X in the 
1970ies).
  seeking (positioned windows are disappearing).

No, KPA can't change X - but it could make use of working parts of the GUI.

... so, after making the first entry (a 3 minutes only for positioning 
struggling), next search, beginning often, rather typically with a mismatch, 
because it's so costly and error prone to do all markers back, and there's no 
quick overview over the state.

First: appopriate positioning of all windows starting from the very beginning.

Result: the pure window management,  I'd say the KPA Laokoon Group, is taking 
overwhelming much time.
A better management could and should allow to make a setting in less than 3 
seconds and could and should give an overview over the setting with one 
glance.

Every new entry is taking some minutes pure overhead because of the poor 
handling implementation.
Without an extremous time consuming manual ordering there's no usable 
resulting search order, the directory order seems to be unused (lexical 
ordering and actual ordering).

With a manual ordering the resulting ordering is also very poor, because there 
is no search adapted ordering (think about googling without an ordering of 
results!) - no automatic try and no mechanism for archive installers.

> ... categories you enumerate a new sub-category simply by naming it when you
> apply it to a photo.

Yes, and even doing that is proved to be unnecessary clumsy, and the 
(pre-)ordering according to time is inappopriate.

Let's explain.
After some years of work - up to over 1000 fotos a day, up to 100 
classifications per day, some of them from accounted experts - some guy has 
today 14141 insect photos of minimally 1764 species.

O.k., it's fair for him to order them, e.g. one of them as "hexapoda, insecta, 
pterygota, neoptera, odonata, zygoptera, coenagridae, pyrrhosoma, nymphula" -
but "pyrrhosoma nymphula, imago, 30.6.2002, #23" should say enough and give a 
good ordering.

It would be complete nonsense to look at these pictures in chronological 
order. But to have a slider to find the 

But even names like "pyrrhosoma nymphula, imago, 30.6.2002, #23" alone would 
give an acceptable alphabetical ordering. Sometimes I am also photographing 
insects, but to store "pyrrhosoma nymphula, imago, 30.6.2002, #23" will be 
much better for me than to store "hexapoda, insecta, pterygota, neoptera, 
odonata, zygoptera, coenagridae, pyrrhosoma, nymphula, imago, 30.6.2002".
But only, when not intermixed with the pyramids of Gizeh.

> It's also worth noting that when KPA presents a list of categories they are
> sorted in lexicographical order, so if you name your batches with leading
> zeros (i.e. 00123 instead of 123), the list will be sorted in numerical
> order.

As I said, the naming of my files is devoted to my relatives, and they have to 
work even outside of the context and outside of linux.