<br><br>

<div><span class="gmail_quote">2007/3/1, Marcel Wiesweg <<a href="mailto:marcel.wiesweg@gmx.de">marcel.wiesweg@gmx.de</a>>:</span>

<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">> About QT4 this is my plan :<br>><br>> - 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.

<br>Most important, high-quality documentation is being written at<br><a href="http://techbase.kde.org">techbase.kde.org</a> (subdomain subject to change: <a href="http://developernew.kde.org">developernew.kde.org</a> 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.

<br>> The time is precious and i won't lost time to trying to install an unstable<br>> package with a risk to break my computer.<br><br>I understand your point...but as usual (me being a Gentoo user) I don't have

<br>any objections to install KDE trunk svn parallely on my computer. There is<br>also documentation:<br><a href="http://techbase.kde.org/Getting_Started/Build/Unstable_Version">http://techbase.kde.org/Getting_Started/Build/Unstable_Version

</a></blockquote>

<div> </div>

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

<div> </div><br>

<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">> - To have take a look into QT4 port, well digiKam will be long (few<br>> 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...

<br><br>Yes multithreading is easier with Qt4, but that's not a problem for porting,<br>the code still works, it means we can actually remove code (and I will very<br>happily volunteer to remove all the manual event sending code, QDeepCopies of

<br>QStrings from our multithreaded parts).</blockquote>

<div> </div>

<div> </div>

<div>Fine for me if you can do it (:=)))</div>

<div> </div><br>

<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Overview documentation<br><a href="http://techbase.kde.org/Development/Tutorials/KDE4_Porting_Guide">http://techbase.kde.org/Development/Tutorials/KDE4_Porting_Guide

</a><br><br>There are scripts to relieve us of the tedious work:<br><a href="http://doc.trolltech.com/4.2/qt3to4.html">http://doc.trolltech.com/4.2/qt3to4.html</a><br><a href="http://websvn.kde.org/trunk/KDE/kdesdk/scripts/qt4/">

http://websvn.kde.org/trunk/KDE/kdesdk/scripts/qt4/</a><br><br>There are two pages with detailed information about the API changes. These<br>need to be consulted while porting:<br><a href="http://doc.trolltech.com/4.0/porting4.html">

http://doc.trolltech.com/4.0/porting4.html</a><br><a href="http://websvn.kde.org/*checkout*/trunk/KDE/kdelibs/KDE4PORTING.html">http://websvn.kde.org/*checkout*/trunk/KDE/kdelibs/KDE4PORTING.html</a></blockquote>

<div> </div>

<div>These links are very important. Please put these urls in TODO file to remember... </div>

<div> </div><br>

<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">> - Another main problem is to have an area in svn to work on digiKam and<br>> others shared lib (libkipi, libexiv2, likdcraw), without to be in conflict

<br>> with others application available in extragear (kphotoalbum, showimg, etc.)<br>> witch will not be ported at now and continue to require QT3/KDE3. I have<br>> follow a thread last year about this point in extragear mailing list

<br>> without to have a clean response. Angelo, if you have some fresh<br>> informations about this point, let's me hear...<br><br>Overall KDE policy is clear: trunk is KDE4 because it's the future. Branches

<br>are KDE3. Amarok also has its KDE4 = main development branch as trunk.</blockquote>

<div> </div>

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

<div> </div>

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

<div> </div>

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

<div> </div><br>

<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">> - We cannot merge QT3 and QT4 code. This is want mean than all part need to<br>> be ported before. All shared lib need to ported in first : libkipi,

<br>> libkexiv2, and libkdcraw. After the core of digiKAm can be ported to<br>> disable all external plugins (kipi-plugins and DigiKamImagePlugins). And t<br>> end the port of plugins can be done : DigikamImagePlugins in first (to

<br>> merge the code in digiKam core), and kipi-plugins in second. This last one<br>> is the ost complicated to plan because it's shared with others hosts<br>> program and maintaned by a lot of contributors. I think than kipi-plugins

<br>> will take a while to port.<br>><br>> I'm agree with Fabien. A new QT3 release must be done at least : 0.9.2. We<br>> will port the core to libkdcraw (a patch is ready on my computer) and we<br>> wil fix a lot of bugs from 

B.K.O.<br><br>This should of course be done before branching to a KDE3-stable and a KDE4<br>branch. Once the branch is done, we can still do bug fixes but not much more.</blockquote>

<div> </div>

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

<a href="http://makefile.am">makefile.am</a>) witch are obsolete with CMake. Can we have both at the same time and at the same place ? </div></div>

<div> </div>

<div>Gilles</div>