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

[Marcel Wiesweg]

> 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

> - 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).

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

> - 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.

> - 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.


Marcel