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

Gilles Caulier caulier.gilles at gmail.com
Thu Mar 20 07:53:04 CET 2008


2008/3/19, Gilles Caulier <caulier.gilles at gmail.com>:
> 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 ?
>
>

Others question is about all others plugins not yet ported to KDE4

Plugins that i will never port to KDE4 are :


- FindImages.
- KameraKlient

Plugins which need to be rewrited (but not by me):

- BatchProcessImages.
- CDArchiving.
- MPEGEncoder

For the 2 ones, internal digiKam solutions are planed...

Plugins which need to be ported by mainteners :

- Calendar
- Slideshow
- FlickerExport
- GalleryExport
- HTMLExport
- PicasaWebExport
- IpodExport
- PrintWizzard
- ImageViewer

Pending question is about Sync framework from Colins...

For all these point we need a time-line to be clear with users. It's
clear for me than not all kipi-plugins will be available for the first
KDE4 release... Porting code to Qt4/KDE4 take a while and require
important regression tests. The advantage is than we review code
indeep and a lots of bugs can be fixed...

Best

Gilles Caulier


More information about the Kde-imaging mailing list