"Software necromancy" on AUR - ideas/feedback appreciated

Question

Hi
Background:
Basically to just see if it would work, I ported/updated two old abandoned packages on AUR that dependend on Qt2 to be built with Qt4.
Why?
I think it is better to use a mantained library than an old unmantained and possibly insecure and I was curious to see if it could work.
Why not Qt5?
Simply because Qt4 comes with the Qt3Support module, which is needed (otherwise much more invasive source code changes are needed). Basically, the Qt2-to-Qt3 porting information was "try to compile it and fix errors reported by the compiler" and the awesome qt3toqt4 application automated most source code changes, so I basically just tried to convert directly from the Qt2 programs. As far as I have understood, Qt4 to Qt5 should also be an easy porting, so perhaps the Qt3Support module could be ported to Qt5+ as an independent legacy support module in the future.
With no real knowledge in Qt or C++, I could in about 2 hours (including googling and reading documentation) get both applications to compile with Qt4. Now there are no more packages depending on Qt2 or less in AUR.
https://aur.archlinux.org/packages/blackpenguin/
https://aur.archlinux.org/packages/xbic/
There are some issues still with both packages, which I believe might be easy for people with real programming experience to spot/solve:
blackpenguin:
Program compiles and executes, but:
- Clicking "new game" or "load game" gives the following error:
QPainter::begin: Widget painting can only begin as a result of a paintEvent
- Clicking "help" gives the following error:
QWidget::setMinimumSize: (PushButton_1/QPushButton) Negative sizes (-1,-1) are not possible
F-keys, the "?" button etc seem to work as they should.
xbic:
Program compiles and executes, but:
when game should be loaded, the binary "fight" complains about:
fight: cannot connect to X server :
I tried to explicitly link against libX11 but this did not do any good.
There were also more manual interventions in this source (explicitly set (const char*) and (char*) on some arguments where newer Qt got their own types)
There is a potentially dangerous commenting out in menu.cc too, where I could not come up with a good alternative to the original killTimers().
The Qt QTimerEvent::killTimer(int) requires a timer ID to be given as an argument and I could not figure out a way to retrieve that information across functions (saving a variable name from the return value from startTimer() will probably not work). and the QBasicTimer start() and stop() do not seem to want to work, since the timer is started and stopped in two different functions (menu::start_battle() and menu::timerEvent() ). This probably just shows how little I know about C++ and looking at it with "C glasses".
Future ideas/prospects
* look if there are interesting Qt3 packages in AUR that could be updated
* investigate the porting of the Qt3Support module to Qt5
Feedback welcome
Last edited by W.F.Cody (2014-08-12 10:35:40)

Answer 1

ids1024 wrote:Gtk1 may be of interest, though I expect gtk programs are harder to port to newer versions.
https://aur.archlinux.org/packages/gtk/
Indeed! it does however seem like GTK 1 --> 2 -->3 migration is far more difficult than migration of Qt programs (blackpenguin was built in 1999) and I do not know how good the documentation is.
I was surprised to see how many applications on AUR depended on GTK1!
I think I will try to pick the "low haning" Qt3 stuff first before learning GTK, but I will remove the [Qt] in the thread title so that this thread is about general "software necromancy"
EDIT:
Although "controversial", these things might be a viable option to port from GTK to Qt
http://www.thelins.se/johan/2010/01/gtk-made-qt.html
http://wiki.lxde.org/en/Migrate_from_GTK+_to_Qt
https://gitorious.org/gqt/gqt
EDIT2:
documentation on GTK1 --> GTK2 is pretty poor. found this after some googling
http://web.archive.org/web/200805021613 … n/porting/
Last edited by W.F.Cody (2014-08-15 06:53:48)