[Kde-imaging] [RFC] kipi & co. release plan proposal

[Gilles Caulier]

2008/3/19, Achim Bohnet <ach at mpe.mpg.de>:
> On Tuesday, 18. March 2008, Angelo Naselli wrote:
>  > libkipi
>  > 21-24/3 libkipi      0.2.0 (*kde4*) beta
>  >              libkipi      0.1.6 (kde3) need to verify if we can avoid breaking abi first
>
>
> I would suggest release and break API with 0.1.6 only when there are
>  kde3 kipi-plugins available that make use of the interface to implement
>  new enduser functionality (runtime versus buildtime lib version does
>  not count as enduser functionality).
>
>  Angelo, scheduled 0.1.6 as bug fix release.  And to be honest when
>  I consider free time constraints: Better implement new features in
>  KDE4 (first) if there time left for backports ... we'll see ;)
>
> >
>  > libkexiv2
>  > 21-24/3 libkexiv2  0.1.7 (kde3) need to verify if we can avoid breaking abi first
>
>
> Again only break API if there's a real win for the user of the applications.
>  For new we have KDE4 were we can break every API we want.
>
>
>  > kipi-plugins
>  > 12-13/4 kipi-plugins 0.1.6 (kde3) beta1 (it should be only a bug fixing release)
>  > 19-20/4 kipi-plugins 0.1.6 (kde3) beta2 or rc1
>  > 19-20/4 kipi-plugins 0.2.0 (*kde4*) beta1
>  > 16-27/4 kipi-plugins 0.1.6 (kde3) rc1 or final (can be postponned by a week)
>  > 3-4/5   kipi-plugins 0.1.6 (kde3) final if not yet done
>
>
> 0.1.6 looks fine.
>
>  0.2.0 I'm not sure.  Will gwenview support kipi-plugins in 0.4.1 if we release
>  now?
>
>  If not, better wait with a release until the digikam/kphotoalbum for KDE4
>         reach a releaseable state.  Until then use svn builds
>
>  If gwenview does, do we implizitly promixe not to break API compatibility
>  during KDE4 life cyle for libkipi?

I have already working hard to implement all major libkipi features to
KDE4. It's sound fine to 90% for me. It still a little feature to add:
to able to use a progress bar from kipi host with batch plugins.

Aurélien, Jasper,

In libkipi, i have removed all widget, dialog. It's a pure C++
interface without internationalization now. It's a pure QT4
implementation also.

All widgets must be re-implemented in kipi host, especially about
collection model/view witch can be different (for ex. KPhotoalbum and
digiKam)

I have already implemented all in digiKam core, if you want to get inspiration.

For ex, collection selection support folder tree view. It really
better than a flat list :

http://digikam3rdparty.free.fr/Screenshots/newkipiimagecollectionselectorwidgetKDE4.png

I have also cleaned API and moved common dialog (like batch process)
into internal libkipiplugins, because kipi will never use it.

I have also re-implemented the image dialog with use now a thumbnail
generator from kipi host (if you re-implement it in your interface),
and provide metadata informations for image using libkexiv2. The
dialog is a simple extension of KDE open fiel dialog. No need to
re-invent the wheel.

About plugins, all my one are ported to KDE4 are pure Qt4 :

JPEGLossLess
Raw converter (witch now support 16 bits color depth conversion with
auto gamma!)
SimpleViewerExport
SendImages
MetadataEdit (which support XMP as editor:
http://digikam3rdparty.free.fr/Screenshots/MetadataEditor)
AcquireImages
GPSSync (which can edit GPS track list:
http://digikam3rdparty.free.fr/Screenshots/gpstracklisteditor.png)
TimeAdjust.

Note : all Plugins support XMP everywhere. I have improved very well
libkexiv2 for that.

I know that Valerio must continue the SlideShow plugin port. I have
started the job, but he must complete it...

Aurélien, do you will port HTMLExport plugin ?

Gilles Caulier