[KPhotoAlbum] order criteria for a family photo collection

[Heinz Kohl]

Am Dienstag 20 Februar 2007 07:07 schrieb Tero Tilus:
> On Mon, 19 Feb 2007, Heinz Kohl wrote:
> > KPA should therefore hold the possibility to make XML output.
>
> AFAIK it will.
>
> > I would be over glad, when KPA would conserve additional entries KPA
> > is not knowing.  Maybe KPA 3.0 is doing that - KPA 2.2 is removing
> > all unknown data, even a XML style link.
>
> If you have entered your own custom XML _markup_ to index.xml I would
> not be surprised if it's gone after first 'save' from KPA.  If you
> want your changes be persistent, KPA needs to understand them.  If you
> edit index.xml stay inside KPA schema.

It could be nice to have at least the following:
- not throwing away XML declarations at the beginning of the file, just to 
copy and ignore them
example: 
     <?xml version="1.0" encoding="ISO-8859-1" standalone="no"?>
     <?xml-stylesheet href="indexStyle.css" type="text/css"?>
     <!DOCTYPE xhtml PUBLIC "-//W3C//DTD XHTML 1.1 plus MathML 2.0 plus SVG 
1.1//EN" "http://www.w3.org/2002/04/xhtml-math-svg/xhtml-math-svg.dtd" [ 
     ]>

This could make it possible e.g. to include external files entities, the usual 
technic e.g. to incorporate flexible language incorporations, and a style 
sheet, which would make it possible to show up the index file in a browser in 
a more convenient and user readable form (i.e not as a plain text).

Of course, a niche to add features would be also very nice, even if it would 
be not more but a place to add an external reference unseen.

Browsers like Firefox could even be motivated to write a text like
"This is an internal KPhotoAlbum file describing the pictures of a Photo 
Album, perhaps yours, don't move, rename or delete it"
instead of
        "Mit dieser XML-Datei sind anscheinend keine Style-Informationen 
verknüpft. Nachfolgend wird die Baum-Ansicht des Dokuments angezeigt.
	<KPhotoAlbum version="2" compressed="0"> ........


> > I think, it's too complicated to explain what I've really intended
> > with my remarks about date, I hope, it will be seen more clearly
> > with my prototype.
>
> In this case proto is really the best way to 'explain'.  At least I'm
> looking forward to trying it out.

The last three hours I've studied the KPA doc again. 
It's possible, that I hadn't looked to write a proto, when I've had realized 
the real meaning of Fig. 2.3 "Configuring image properties" before - I 
haven't seen to work it in the intended manner on my KPA 2.2 before - and now 
only in the Demo.
Of course, I've seen and studied it before, but to see it hadn't helped 
anything.
Whatever I tried in former times and now again, I didn't get such a single 
window. The category windows were and are staying floating windows.

So I tried the KPA demo - and to my surprise I saw Fig. 2.3 working like I had 
expected it had to work ...
O.k., I was finding the dungeon game informations "it's possible to move the 
items of the property window around ... bar at the top of the frames".
O.k., I was finding this mystically "bar at the top" working as descibed, but 
this was still by no means helpful outside the demo.

It might be simple to ban the floating windows, but
- I hadn't seen, that this is possible
- up to now I don't know, what to do for that beside to try a new 
installation, and at the best a new version 
- I'm tired of seeking such unnecessary 'tricks' (of course, computer usage is 
principially doing series of crazy handlings, which are seen to be normal or 
clever, if and only if they are common)

I've done a demo run at the very beginning, but it isn't a big surprise, that 
I hadn't realized the situation. To see it, some experience with the program 
is necessary. Demos are nice - but don't overestimate their use.
They are also tending to loose value with increasing computer experience and 
for older people with a somewhat restricted memory for new data, especially 
for data with - at the first unstructured - neuronal stimuli.

So you will get the demo, but I'm still hoping to give one or the other hint 
and expecting to write a tool, which will be useful as addition to KPA.

Resume:
- not everybody using KDE is knowing more about the features than "klick and 
look"
- not everybody is interested to have such a knowledge
- I'm estimating, less than 1% of KDE users will have interest to learn about 
that
- it has to be possible to use modern window programs without any knowledge of 
the system behind
- even computer professionals, which are using more than a tiny repertory of 
programs, are necessarily pure dabbler for the rest of the spectrum of tools 
they are using

So:
99.9% of all computer programs have to be written for pure amateurs.
That's the real art of programming - not to write for experts.

- the user description should give a clear information even for system 
ignorants
- at the other side, it should give a precise information for experts and user 
with more specific interests

This is a real art in describing and also a real challenge. A nearly optimal 
solution is possible - but I haven't seen such a description since 1982.

H. Kohl