Table of Contents

A Programme For Tedium

Or “A Program For Tediumme”. How to help out with the dull, mechanical part of converting to Qt4.

Working environment

Here's how to check out, update, and test-build the “Qt4 Mechanised Conversion” branch.

First you'll need the Qt4 and KDE4 headers. Here on Ubuntu 8.04 this one line seems to be enough:

  $ sudo apt-get install kdelibs5-dev

Yes, that's a 5.


  $ svn co
  $ cd qt4-mechanised
  $ bash
  $ make -f qt4-makefile    # Note qt4-makefile has hard-coded system paths: edit for your system

So, you do that, and what happens? It should work fine, up to the Make stage, and then you get lots of errors.

The errors

For me, at the time of writing, the first error is:

/usr/bin/c++ -c -Wall -O0 -g -DHAVE_ALSA -DHAVE_LIBJACK -DHAVE_DSSI -DHAVE_LADSPA -DHAVE_LIBLO -DHAVE_LIBLRDF -DHAVE_XFT -DDEBUG -D'VERSION="2.0-yeah-whatever-innit"' -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtXml -I/usr/include/qt4/QtNetwork -I/usr/include/qt4 -I/usr/lib/kde4/include -I/usr/include -I/usr/local/include -I/usr/include/freetype2 -Isrc/base -Isrc src/document/MultiViewCommandHistory.cpp -o src/document/MultiViewCommandHistory.o
src/document/MultiViewCommandHistory.cpp:35:24: error: qpopupmenu.h: No such file or directory

With make -k, you can see all the errors:

  $ make -k -f qt4-makefile 2>&1 | grep error | wc
    13209  122366 1449720

OK, 13209 errors. So that's the bad news. Well, some of the bad news.

Here's some better news:

  $ find src -name \*.cpp | wc
    574     574   22863
  $ find src/ -name \*.o | wc
    217     217    7886

So even with all those errors, a third to a half of the code seems to have compiled fine. Sure, it was the easiest third – by definition – but it's a start.

What to do about it

So, you look at the first error, or you run make with -k and find one of the most numerous errors.

Could that error be fixed using a simple search and replace on the source code?

If so, you need to work out how to express that replacement in Perl, and add it to the end of, before the last print line. Make sure you also read the introductory comments for that file, and add a little comment saying what you're doing.

(If it can't be fixed using an automated search and replace, don't even try to fix it now. Don't start editing the source code itself, unless you really know what you're doing and have a cunning plan in mind.)

Test your change by running on just the one file you changed, for example

  $ perl ./ ./src/gui/editors/eventlist/EventView.cpp

and scanning the results to see if they seem more or less right. If it looks OK, re-run

  $ bash

Then, rebuild and repeat as necessary.

How can I tell whether it's easily fixable or not?

Refer to the KDE4 porting guidelines and the Qt4 porting guidelines.

What about Qt3/KDE3 compatibility code?

Ideally, we'd be able to make do without using the Qt3 compatibility stuff found in Qt4, or the KDE3 compatibility stuff found in KDE4.

But what we really want to do, more than anything, is to get something working.

So if you can see a simple search-and-replace change that involves a Q3 header and class, or a k3 header and class, go ahead and make it. At least at this stage we'll be able to easily see all such changes in the convert script, and maybe think again about them later.

What if I'm not sure about it?

Do it anyway! Put the replacement in, with a comment saying you don't really know what you're doing. Commit it and tell the -devel list. We can sort it out later.

What to ignore

You almost certainly will want to run with -k and ignore some of the errors, for example by dumping to a file:

  $ make -k -f qt4-makefile 2>&1 | tee make.log

and then reading the file. Errors worth ignoring at this stage include:

What to commit

At this stage, try to avoid committing your actual code changes. It's simpler just to commit with your new scripted change in it.

  $ svn commit

(If you think it would be better to commit all the code as we go along, say so. I've changed my mind about this more than once already.) (Michael says: “No. Just commit to It's the way to go. Since we have some considerable amount of active work in trunk/ to merge in, what I'm aiming to try to do is use this branch in its current states as a testbed for, and then try running it on an updated/merged branch that pulls in all the changes from trunk/ one last time before we finally have to do a hard fork. After that hard fork, porting in people's ongoing work on the old QT3 code will become increasingly tedious and undesirable to deal with.”)

And finally, tell the rosegarden-devel list all about what you've done, no matter how trivial. Let's keep the noise up!