[bt-devel] porting to QT4

[Joachim Ansorg]

Hi,
thank you for your investigation. Feel free to put that into the wiki :)

> Hi all,
>
> It looks like we have two main issues with porting to QT4: Taking out KDE
> objects (KMainWindow, KApplication as examples) and moving existing logic
> to new QT's classes (QPtr and QDict don't exist any more).

It's not that easy, I think.
The KDE classes use a lot of non-Qt techniques, e.g. XML definitions for the 
main menu, DCOP, etc.
We also depend on some KDE classes like KListView and KHTML which are really 
useful for easier development. We can't drop KHTML, so we have to use a 
version which uses Qt4, so it has to be from KDE4, which is considered as 
unstable.
KHTML needs some stuff of kdecore, so we still have to include KDE classes in 
a Qt only port. And we don't know yet where to get stable versions of 
those :)

> It seems like we just have to plod through the code and find QT4
> equivalents for the KDE classes we need to replace while converting to new
> QT classes. Some of the logic may change, but mostly (I think) it's
> changing class/method names to match QT4.
>
> I've attached the errors KDevelop spit out when I tried to compile using
> QT4. The QT4 docs on Trolltech's site include a QT3-to-4 porting guide
> listing all the classes that have changed. I attached "qt4errors - with
> notes.txt" to specifically speak to some of the 3-to-4 problems we will
> encounter.
>
> Do we just want to fork? (like the KDE team is doing) - continue
> developlent of BibleTime 1.6 in QT3, but release BibleTime 1.7 (or 2.0 or
> whatever) using QT4.

That may be better but I don't think we got the development power for that. 
And I don't think we wan't to do new features two times in the old and new 
branch.

> This may not be as in-depth as we need, but hopefully enough to aide the
> port decision. I am in favor of upgrading to QT4, but I would suggest
> holding off porting to other platforms until that upgrade is complete.

Joachim