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

[Gilles Caulier]

2007/3/1, Marcel Wiesweg <marcel.wiesweg at gmx.de>:
>
> > 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.
>
> This is true, it is still changing, but it is much less changing than in
> previous months. The core technologies are there. Amarok has started
> porting.
> Most important, high-quality documentation is being written at
> techbase.kde.org (subdomain subject to change: developernew.kde.org works
> as
> well ;-) )
>
> > - 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.
>
> I understand your point...but as usual (me being a Gentoo user) I don't
> have
> any objections to install KDE trunk svn parallely on my computer. There is
> also documentation:
> http://techbase.kde.org/Getting_Started/Build/Unstable_Version


yes, but i won't to fight with an hard installation of KDE 4 on my computer.
If Mandriva provide standard packages, it will be more easy to do...


> - 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...
>
> Yes multithreading is easier with Qt4, but that's not a problem for
> porting,
> the code still works, it means we can actually remove code (and I will
> very
> happily volunteer to remove all the manual event sending code, QDeepCopies
> of
> QStrings from our multithreaded parts).



Fine for me if you can do it (:=)))


Overview documentation
> http://techbase.kde.org/Development/Tutorials/KDE4_Porting_Guide
>
> There are scripts to relieve us of the tedious work:
> http://doc.trolltech.com/4.2/qt3to4.html
> http://websvn.kde.org/trunk/KDE/kdesdk/scripts/qt4/
>
> There are two pages with detailed information about the API changes. These
> need to be consulted while porting:
> http://doc.trolltech.com/4.0/porting4.html
> http://websvn.kde.org/*checkout*/trunk/KDE/kdelibs/KDE4PORTING.html


These links are very important. Please put these urls in TODO file to
remember...


> - 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...
>
> Overall KDE policy is clear: trunk is KDE4 because it's the future.
> Branches
> are KDE3. Amarok also has its KDE4 = main development branch as trunk.


This is true about KDE core, but extragear is different and do not follow
KDE release plan...

The problem is than extragear host multiple project witch will use QT3 for a
long time.

Question : where Amarok team have placed the QT4 port source code ? It's
Amarok is moved to KDE core (like Gwenview) ?


> - 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.
>
> This should of course be done before branching to a KDE3-stable and a KDE4
> branch. Once the branch is done, we can still do bug fixes but not much
> more.


If i'm following you, after to release digiKam 0.9.1-final, we copy the code
from trunk to stable, and we continue the QT3 digiKam serie in stable, and
in trunk, we start the QT4 port. In this case, we will have a conflict with
others extragear applications witch continue to use QT3. In fact, the
problem is about the common autotools rules (.configure and makefile.am)
witch are obsolete with CMake. Can we have both at the same time and at the
same place ?

Gilles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-devel/attachments/20070301/dedf6ddd/attachment.html>