[KimDaBa] Next release one week, then what?!

[Vincent Picavet]

Hi,

On Sun, 8 May 2005 14:26:26 +0200
"Jesper K. Pedersen" <blackie at blackie.dk> wrote:

> | 0) Up to date debian packages in the sid official repository, with
> | kipi-plugin support.
> Thats really out of my control, fell free to push, however, could get
> that done.
I know this is out of your control, but this mailing list is probably
the best place to discuss this point, as the packager is, I hope,
reading it...
 
> | 2) Being able to quickly display a color histogram of an image (the
> one| in digikam is great)
> KimDaBa is really not an image editor.
Displaying the histogram of an image is not editing the image. It just
give informations about the image. It is very useful to rate an image,
and classify it according to the shape of the histogram. For example,
tag it with a specific keyword which means that the image has to be
edited later, or has to be print out. The histogram is useful as well to
compare similar images and choose the one of them with the best
technicals caracteristics...

> I dont see why you would not have them in one database. And if they
> have absolutely nothing to do with each other, why would you want to
> access them at the same time. It is possible to load a new database
> from the command line using kimdaba -c <path-to-index.xml-file>
> Adding the possibility to load a new database to the menu would of
> course be a good idea.
This is the point :) I just lack a menu entry, and a policy about what
to load at kimdaba startup : last database opened ? A default one
specified in the configuration of kimdaba ? For me the latter is the
best solution.

> | 4) Complete Gallery synchronisation. Being able to synchronise
> kimdaba| and gallery in both ways would be great : adding new comments
> to kimdaba| and upload them to gallery, adding new comments to online
> Gallery and| updates them to kimdaba would be very cool !
> Cool yes, but just the though of parsing HTML doesn't exactly thrill
> me.
I don't know the gallery remote access protocol, but there may be a
way of getting those informations without parsing the HTML code !
Or perhaps another web gallery software give this opportunity.
(coppermine ?).

> | 5) DCOP support, for more script plugins facilities (as amarok
> does). Could you give me some ideas what you might want here.

I have to investigate a bit to know exactly how it could look like.
Do you use amarok ? I think you would get an idea of the use of DCOP to
 extend an application, and let it act as a service program.

One possible use case example is :
The user does a selection / research
He launches a plugin. This plugin can be written in any language as long
as it can launch a dcop call (quite all languages through the "dcop"
program). 
The plugin gets the current selection through a DCOP call, 
It launches two kipi plugins over the selection one after the other,
through dcop calls. 
Then it tags a part of the selection with a new keyword, 
And finally it refreshes the current display of kimdaba to actualise the
changes.
 
> | 6) Predefined filtering, or "dynamic selection" : let the user
> define| a selection and display it. This gives the advantage of not
> having to| manually having to set a given keyword to the new images
> corresponding| to this selection.
> Added to my TODO list for consideration
Thanks :)

> | * a filter textbox on top of list panels (like in amarok, very
> | convenient for person names)
> In 2.1
re-thanks :)

> | * display the current "location" in the status bar, something like
> | Paris > StreetArt > Invaders
> | and the ability to click on them to remove them from the filter
> | (enlarging the selection).
> Interesting, I'll add that to the TOOD
re-re-thanks :)

cheers,
Vincent

-- 
Vincent Picavet,		Tel : +33 (0) 1 39 63 52 14	
INRIA Rocquencourt,		E-mail : vincent.picavet at inria.fr
Projet CLIME			http://www-rocq.inria.fr/clime