From: Chris C. <ca...@al...> - 2008-09-01 16:05:43
|
On Mon, Sep 1, 2008 at 3:31 PM, D. Michael McIntyre <ros...@gm...> wrote: > Before we move to the hard hands-on slog, though, I'd like to see if we can't > catch the qt4-mechanized branch up to trunk, and run the script against as > much of 1.7.2's code as possible before committing anything that's officially > beyond the machine translation stage. What I've done is the following: * [rev 9069] Merged trunk to the kiftsgate branch (which contains a bit of restructuring of command registration intended to make constructing actions simpler in the edit views -- this work isn't as complete as I'd like, but its incompleteness doesn't actually affect the porting effort and it doesn't make any difference to functionality) * [rev 9070] Copied the kiftsgate branch to a new qt4 branch * [rev 9071] Merged the threads branch to the qt4 branch (this removes almost all uses of DCOP) * [rev 9072] Merged the qt4-mechanised branch to the qt4 branch (this introduces the replacement Command base classes mentioned in some earlier emails in this thread) * [rev 9075] Ran the convert.pl script to make all the mechanised conversions we've done so far The net result is to introduce a new branch named "qt4" which is completely up to date with trunk, which has all of the structural changes available so far, and which has all of the mechanised changes we've managed to script to date. Needless to say, it doesn't actually compile. To get this branch, of course, you should check out: https://rosegarden.svn.sourceforge.net/svnroot/rosegarden/branches/qt4 Remember that you can get a complete build and error log by running e.g. $ make -k -f qt4-makefile 2>&1 | tee make.log so long as your copy of qt4-makefile has the right include and library paths in it (the SVN version should be OK for Ubuntu). So, what to do next? One thing I _don't_ think we should do is run qt3to4. That tries to update Qt3 code to use the Qt3 compatibility layer in Qt4, rather than using native Qt4 classes, even where moving to the Qt4 classes would be simple. In most cases that is not what we want -- even if we do want to use the compatibility layer for difficult situations like the canvas, we should be aiming to use Qt4 classes for the straightforward cases. And qt3to4 will break some of the work we've already done, such as layout fixes. I have tested it on this code, and it definitely produces some output that may compile but behave wrongly for us, which is the last thing we need. It made little difference to how much of the code actually compiled, as well. Some obvious things that other people might like to volunteer to handle next: * Updating the CMake build system -- I'm just using qt4-makefile myself * Work out what to do about KDockWidget, which looks like a tricky one * Update all our uses of KConfig (automatically or manually depending on what you feel able to do) to use either the new KConfig syntax, or QSettings -- Emanuel, your branch looks like it has some work on this? Can you handle this one? * We have quite a lot of tests that assume you can cast from QString to bool (to test for emptiness), which is no longer the case -- the error messages for these are very easy to spot ("could not convert X to `bool'"), the fix is simple (replace "if (X)" with "if (!X.isEmpty())") and automating them could be tough -- anyone like to fix these? * Check out all the "no match for operator<<" errors -- these may just need "misc/Strings.h" including, or may be something more subtle * Replace all uses of KProgress classes with the QProgress equivalents * Look at all errors that start with "error: invalid use of incomplete type" and see how many of them can be fixed by just adding a #include The next things I intend to do myself are: * Go back and finish the DCOP removal work in threads branch, and then merge the results to the qt4 branch. So, IMPORTANT NOTE: Any errors you see in the qt4 branch that result from references to DCOP -- ignore them please! I will fix them. * Fix a bunch of compile errors in calls to CommandRegistry::registerCommand -- these arise from changes to shortcut handling, and appeared as a result of the Kiftsgate branch merge One thing I will eventually do if nobody else does, but I don't mind if someone else gets to first: * Formulate and apply a policy for moving from KDE3 action classes to something else -- probably Qt4 action classes -- and check out how this interacts with KXMLGUI which we use quite heavily. It's probably a good idea if we discuss, or at least mention, changes on this list before committing any big manual fixes. At the least, make sure your commit messages are informative. Emanual, you should subscribe to the rosegarden-bugs mailing list as well if you haven't already (that's where commit notifications go). Chris |