[KimDaBa] New snapshot: "Patch" for thumbnails and questions/ideas about plugins

[Reimar Imhof]

Am Sonntag, 18. Juli 2004 17:23 schrieb Jesper K. Pedersen:
> After 3 month, a new snapshot is now available from:
> http://ktown.kde.org/kimdaba/snapshots/
>
> WARNING: We are still working on what images are effected by a plugin,
> which means that currently all images in scope (which might mean your whole
> database) are effected if nothing is selected.
> So before you start playing with unknown plugins, please try with a demo
> database first (run kimdaba -demo)
>
> Cheers
> Jesper.

Hello Jesper,

with the new snapshot I got a problem about thumbnails created for the 
Ctrl-T-thing:
These 256x256-thumbnails are build with a terrible quality.
I had a look at imageloader.cpp.
Here I found your hack (line 89 - 93).
I disabled the hack (removed those lines) and everything is fine.
The problem was this: A 64x64-thumbnail was created. This one was set to the 
variable img in line 75.
Then, within the hack, that image was scaled to 256x256.
To compare I had a look at the last snapshot (2004-04-18).
That one didn't have that problem because the original image was scaled to 
256x256.
On the other hand: The hack did work only if you had the standard size for 
that Ctrl-T-images (256X256). If you choose an other size (for example 
512x512) the 256-thumbnails were created for nothing...
(I do not apply a patch file with this mail because my change is so terrible 
simple!)

Two things about the plugin interface:
Selection:
I'd like a pseudo album with the images actually selected (via search 
functionality) within kimdaba. And I could also think of a second pseudo 
album with those images actually selected by mouse. So I could search for 
some pictures within kimdaba (get perhaps 10 images), then select 3 of them 
by mouse and tell the plugin just to take that second pseudo album to get the 
manually selected images. If I take the first pseudo album I get the Images 
actually found by the kimdaba search.

Rotation:
Kimdaba by default does not rotate images but stores an rotation angle in its 
index.xml file.
When I put rotated images to an kipi plugin the plugin does not care about the 
rotation. Just a little sad :-(.
Could kimdaba create temporary rotated files and put these rotated images to a 
plugin? This thing should be configured in the kimdaba options dialog (plugin 
section). There we could have a second check box ("use temporary rotated 
images").
In case a plugin changed a temporary image kimdaba could update the original 
file form the temporary one (using a second rotation, the other way round of 
course!).
Different approach: Kimdaba could have a new menu entry for rotating an image 
(some images) via lossless jpeg rotation according to the index.xml rotation 
angle (and then set that angle to 0)? This could also be helpfull without 
thinking about plugins.
And what about configure the rotation behavior in a general way: Kimdaba could 
have two radio buttons in it's configure dialog. One says "store rotation 
angle in index.xml file" (that's what is done today), the other on says 
"rotate image via lossless jpeg rotation".
If you turn on the second radio button, every rotate within the image 
properties dialog would use jpeg rotation and keep the rotation angle within 
the index.xml file as 0.

I hope these remarks could help you.

Bye
Reimar