Hi all, Today, i have talk in private with Colin about the possibility to start the implementation of libkipi version 2. The purpose of this version is to prepare the code of QT4/KDE4 port. It will not yet a port, but just a code cleanup and API polishing.

<br><br>The libkipi implementation is not clean for many points of view. <br><br>1/ There is no way to handle plugins actions using the standard rc files way provided by KDEAPI. The way to plug actions in kipi host is complex and not really maintainable. 

<br>There is already a file in B.K.O relevant of this subject :<br><br><a href="http://bugs.kde.org/show_bug.cgi?id=122454" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://bugs.kde.org/show_bug.cgi?id=122454

</a> There is no way to plug an action in tool bar... It&#39;s not really user friendly. The solution to solve it is simple and is already used in digikam core with image editor plugins : KXMLGUIClient. Of course, the kipi host need to be fixed, and it can be difficult/long to do.

<br><br>2/ More related to Colin wishes, are :<br><br>* Full abstraction of the folder/directory access to albums and<br>photos/items. IMO, a kipi plugin should just call API methods for<br>working on albums and items and it should not (need to) care about how

that is done on any disk. &nbsp;* A host application should be able to store abstract key/valu information about albums and photos and this should be accessable by plugins via the libkipi API. 3/ Remove bloating data only used by kipi-plugins and not kipi host, like some widgets, icons, class, etc...

<br><br>What do you think about ?<br><br>Gilles Caulier<br><br>