[KPhotoAlbum] Tokens enhancement

[Wes Hardaker]

>>>>> "h" == havoc  <havoc at harrisdev.com> writes:

h> On the one hand, I'm wondering if it's effective to turn the tokens
h> into a separate and independent tag, when we already have keywords as
h> tags.

Jesper has said multiple times in the past he has no intention to
increase the functionality behind the token support much...

Here's how I use tokens, and why I think they're actually the *only*
way to classify images:

1) I view *fullscreen* (ctrl-I) all images in a new folder.  I tag
   each image with tokens based on what's in it, etc.  Most
   importantly, one of the tags I use is "Good" (which I normally
   assign token G to).  It is impossible to tag a image as "good"
   without seeing it full size to make sure it's very very sharp.  I
   take lots of wildlife pictures and at a smaller resolution they can
   appear just fine, but when blown up to full screen you'll find it's
   slightly blury.  Or you'll find that one blown up is slightly
   better than another if you took multiple pictures of the same
   subject.

2) Then I move all non-good pictures to an "other" subdirectory.  This
   is simply how I store stuff on a web-server that auto-displays a
   folder of images.  (no html extraction needed).

   Because kimdaba won't do this for you easily, I wrote a perl script
   to do this quickly...

      kimdbmove -c index.xml -m -G=others

   moves all images without the G token to "others", for example.

3) Because it's sort of a pain in kimdaba (sorry...  kphotoalbum) to
   change tokens to real tags, I wrote another script to do that and
   it reads the index.xml file and displays a GUI allowing you to
   change all tags to a given category/label.  It remembers the last
   ones used, so it assumes as a default in the GUI that "G" for me is
   Category=keywords, label=good.  This modifies the XML file to do
   all those assignments.  This is much much faster than doing it
   within kphotoalbum.

4) Because loading the .xml file with a ton of images is very slow,
   both for the scripts I wrote and for kphotoalbum itself I often
   create a temporary index.xml file for use with just the new images
   I'm currently sorting (often it's on my laptop when I'm
   disconnected from the main repository on my server at home).  Thus,
   I had to write another script that merges kimdbmerge that takes two
   index.xml files and combines them (optionally adding path prefixes
   to one so it becomes a subdirectory in the main image repository).

I'd *love* it if kphotoalbum would allow me to sort images this way in
a better fashion.  Certainly the SQL backend alone will speed up many
of my issues, which would be a huge improvement.  In fact, being able
to *quickly* assign category/label in the full screen viewer would be
a good thing.  The current multiple-image sorting screen is very good,
assuming you don't need to examine image quality  much but because I
take many many images I need to examine for quality I simply can't use
it.

(I'll happily give my tools to anyone that uses them, but to be honest
I'm not categorizing as in #3 as much because it's still not ideal)

I love kphotoalbum.  It's a fantastic piece of software.  But speed
improving it's ability to classify images would be fantastic.  Note
that in the above sequences, I don't use any mouse movement to do
stuff either...  It's all just keystrokes to do classification and not
having to move my hands is also important for speed...

-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett