[Digikam-devel] Prepare the future : merging digiKam and DigikamImagePlugins

[Achim Bohnet]

On Thursday, 1. March 2007, Gilles Caulier wrote:
> About QT4 this is my plan :
> 
> - This port require also KDE 4 library port. I have seen in lots of
> developpers blogs than the API is not yet frozen and stabilized.
> - In my computer (Mandriva 2007), i have already QT4 API but not yet KDE4.
> This one will be certainly available in next Mandriva release planned in few
> month. I refuse to work on QT4 KDE4 port without a clean API available. The
> time is precious and i won't lost time to trying to install an unstable
> package with a risk to break my computer.
> - To have take a look into QT4 port, well digiKam will be long (few
> month) but easy to do because we using standard API witch are always
> available in QT4. The main change are about multithreading witch is more
> easy to do with QT4, but i think we can just port the code as well without
> improve anything. Marcel, i need your viewpoint here...
> - Another main problem is to have an area in svn to work on digiKam and
> others shared lib (libkipi, libexiv2, likdcraw), without to be in conflict
> with others application available in extragear (kphotoalbum, showimg, etc.)
> witch will not be ported at now and continue to require QT3/KDE3. I have
> follow a thread last year about this point in extragear mailing list without
> to have a clean response. Angelo, if you have some fresh informations about
> this point, let's me hear...

IMHO, we can use branches/work/<whatever> and to lib*, digikam etc in their.
Maybe call it kipi4.  So everything required/related fits nicely ;)
CMake stuff can always later adapted to whatever schema extragear will chose.

FWIW: I will try to contribute to auto* -> cmake switch.

Achim

> - We cannot merge QT3 and QT4 code. This is want mean than all part need to
> be ported before. All shared lib need to ported in first : libkipi,
> libkexiv2, and libkdcraw. After the core of digiKAm can be ported to disable
> all external plugins (kipi-plugins and DigiKamImagePlugins). And t end the
> port of plugins can be done : DigikamImagePlugins in first (to merge the
> code in digiKam core), and kipi-plugins in second. This last one is the ost
> complicated to plan because it's shared with others hosts program and
> maintaned by a lot of contributors. I think than kipi-plugins will take a
> while to port.
> 
> I'm agree with Fabien. A new QT3 release must be done at least : 0.9.2. We
> will port the core to libkdcraw (a patch is ready on my computer) and we wil
> fix a lot of bugs from B.K.O.
> 
> Gilles
> 
> 
> 2007/3/1, Arnd Baecker <arnd.baecker at web.de>:
> >
> > On Thu, 1 Mar 2007, Fabien wrote:
> >
> > [...]
> >
> > > I guess that when you will start to port digiKam to QT4, there will be a
> > >   feature freeze for around 1 year, the time to change the source code
> > > and to stabilize the new version, isn't it ?
> >
> > If this would really freeze feature additions for one year,
> > I would also like to add a few wishes before that ;-)
> > (OTOH, Gilles is so fast, so maybe the freeze would much shorter ;-0)
> >
> > Arnd
> > _______________________________________________
> > Digikam-devel mailing list
> > Digikam-devel at kde.org
> > https://mail.kde.org/mailman/listinfo/digikam-devel
> >
> 



-- 
  To me vi is Zen.  To use vi is to practice zen. Every command is
  a koan. Profound to the user, unintelligible to the uninitiated.
  You discover truth everytime you use it.
                                      -- reddy at lion.austin.ibm.com