"Software necromancy" on AUR - ideas/feedback appreciated

W.F.Cody · 2014-08-07 08:18:28

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)

Awebb · 2014-08-07 08:51:18

I have nothing of value to contribute, but I appreciate your efforts :-)

W.F.Cody · 2014-08-08 08:22:09

Awebb wrote:

I have nothing of value to contribute, but I appreciate your efforts :-)

Thanks Hopefully someone with the right skills can give a few pointers how I can get them to work as they should (QPaintEvent stuff for blackpenguin, X11 issues for xbic). I have the feeling that both just have some minor issues right now (since they both compile and start...)

ids1024 · 2014-08-09 00:02:20

The problem with xbic is that the DISPLAY variable is not being passed to the "fight" binary.

ids1024 · 2014-08-09 01:21:39

I fixed xbic (that specific problem anyway, I haven't tested much).
https://gist.github.com/ids1024/acb70af9a246f8a11df0

Edit: The problem was that QString is 16 bit rather than 8 bit (I presume it was different in Qt2). When it tried to read the text box containing the display, the first byte was the correct first character, but the second byte was empty, thus acting as a terminating null byte. The proper conversion method fixes it.

Last edited by ids1024 (2014-08-09 01:42:39)

ids1024 · 2014-08-09 01:53:03

For the problem with blackpenguin:
http://qt-project.org/doc/qt-4.8/portin … ng-widgets

ids1024 · 2014-08-09 04:30:21

Fixed the QPainter problem:

diff -upr blackpenguin-0.2-old/src/BlackPenguinData.cpp blackpenguin-0.2/src/BlackPenguinData.cpp
--- blackpenguin-0.2-old/src/BlackPenguinData.cpp       2014-08-08 18:57:26.750244782 -0700
+++ blackpenguin-0.2/src/BlackPenguinData.cpp   2014-08-08 21:25:46.257842241 -0700
@@ -894,6 +894,8 @@ BlackPenguinData::BlackPenguinData
        :
        Inherited( parent, name, 0 )
 {
+       setAttribute(Qt::WA_PaintOutsidePaintEvent, true);
+
        // load a previously stored keyboard assignment if available, else use defaults
        if (!loadkeys()) {
                m_nKeyNW = Qt::Key_Left;

ids1024 · 2014-08-09 16:41:55

I've ported xbic to qt5 (once again more or less untested).
https://gist.github.com/ids1024/5a71b467f9317d95e5bc
Includes my previous patch.

W.F.Cody · 2014-08-11 12:17:34

Awesome work ids1024! I will update the packages ASAP

So the dependency is qt5 now? No need for the Qt3Support module?

EDIT: I saw in the patch now that Qt3support module was removed. Great

Last edited by W.F.Cody (2014-08-11 12:40:34)

ids1024 · 2014-08-11 18:03:32

Gtk1 may be of interest, though I expect gtk programs are harder to port to newer versions.
https://aur.archlinux.org/packages/gtk/

ids1024 · 2014-08-11 18:41:23

The dismiss button is missing in the blackpenguin rules window. Deleting this line in CRulesDialogData.cpp fixes it.

dlgedit_PushButton_1->setFixedSize(QWidget::sizeHint());

W.F.Cody · 2014-08-12 10:34:12

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)

ids1024 · 2014-08-16 23:53:31

Ported blackpenguin to qt5:
https://gist.github.com/ids1024/483f7e248ccd2ba4c639

W.F.Cody · 2014-08-19 07:53:12

ids1024 wrote:

Ported blackpenguin to qt5:
https://gist.github.com/ids1024/483f7e248ccd2ba4c639

That is truly awesome! I uploaded the new build to AUR and confirmed that the binary only needed Qt5 by ldd. Is it just me or does it look nicer now? Before I did not have the scores/life points etc.
This proves that 1) as long as it is mirrored, open source software never dies 2) Qt is an amazingly future-proof toolkit

I hope to have time to adopt/adapt some of the Qt3 orphans on AUR soon
Truly amazing job ids1024!

ids1024 · 2014-08-19 14:51:53

W.F.Cody wrote:

Before I did not have the scores/life points etc.

That was of course a problem with the qt4 version. I don't know what caused it, but in porting to qt5 I accidentally fixed it.

ids1024 · 2014-12-17 06:04:43

It seems it's time to resurrect the necromancy thread.

I have been working on porting genchemlab from qt3 to qt4. I have it building (patch here), but there are still issues.

ids1024 · 2014-12-18 00:40:19

I fixed the problem it had. Now to test it and perhaps port to qt5.

Does anyone have any arguments against patching qt3 programs in the AUR to work with qt4/5? I know Arch generally favors having as few patches as possible, but it seems reasonable to patch to avoid relying on an old version of a major library, were that version has been dropped from the repo.

Edit: I have uploaded my patched version to the AUR. Another method for dealing with obscure qt3 programs is to delete them from the AUR, but I don't like that method.

Last edited by ids1024 (2014-12-18 01:00:27)

Awebb · 2014-12-18 09:30:34

Development should not stay in the AUR. It's very nice to have those packages instead of not having them, your patches should go upstream at some point. If there is no more upstream, then I don't mind.

ids1024 · 2014-12-18 14:58:50

It hasn't been updated in 10 years, but there is a sourceforge page. I'll try to contact the author.

Would it be better to set up a github repo rather than include major patches in the AUR?

Awebb · 2014-12-18 15:06:08

I'd say it depends on the quantity of the patch. If you only change a few shebangs (like python → env python2), then I guess the AUR is the right place. You, however, seem to port all those applications to more recent Qt, so you basically forked it. I'd properly fork it and set up a github repo. It all depends on how much work you want to put into maintaining those sources.

That said, I'm only a casual AUR maintainer (I have one tiny package), so the best place to ask would be the AUR mailing list. They know all the rules and they have experience with different scenarios.

W.F.Cody · 2014-12-22 12:27:40

ids1024 wrote:

I fixed the problem it had. Now to test it and perhaps port to qt5.
Does anyone have any arguments against patching qt3 programs in the AUR to work with qt4/5? I know Arch generally favors having as few patches as possible, but it seems reasonable to patch to avoid relying on an old version of a major library, were that version has been dropped from the repo.
Edit: I have uploaded my patched version to the AUR. Another method for dealing with obscure qt3 programs is to delete them from the AUR, but I don't like that method.

Awesome! I was actually looking at trying to port that package before... and then life got in the way. Great that you continue this, because if one could purge old dependencies from the AUR, it would be a big win I think

EDIT: another one that is stuck on Qt3 that I was thinking about was Nethack - but there it would probably make more sense to push upstream (and there is a forked port to qt4 available)

Last edited by W.F.Cody (2014-12-22 12:33:49)

ids1024 · 2014-12-22 18:01:59

I have created a github page for genchemlab. It's not used by the AUR package yet; I think I will try to port it to Qt5 before I make a release.
https://github.com/ids1024/genchemlab

ids1024 · 2014-12-31 23:37:01

I have ported genchemlab to Qt5 and updated the AUR package. I also removed autotools in favor of qmake.

Internationalization is probably broken. I have tried to get it working with no success.

Arch Linux

#1 2014-08-07 08:18:28

"Software necromancy" on AUR - ideas/feedback appreciated

#2 2014-08-07 08:51:18

Re: "Software necromancy" on AUR - ideas/feedback appreciated

#3 2014-08-08 08:22:09

Re: "Software necromancy" on AUR - ideas/feedback appreciated

#4 2014-08-09 00:02:20

Re: "Software necromancy" on AUR - ideas/feedback appreciated

#5 2014-08-09 01:21:39

Re: "Software necromancy" on AUR - ideas/feedback appreciated

#6 2014-08-09 01:53:03

Re: "Software necromancy" on AUR - ideas/feedback appreciated

#7 2014-08-09 04:30:21

Re: "Software necromancy" on AUR - ideas/feedback appreciated

#8 2014-08-09 16:41:55

Re: "Software necromancy" on AUR - ideas/feedback appreciated

#9 2014-08-11 12:17:34

Re: "Software necromancy" on AUR - ideas/feedback appreciated

#10 2014-08-11 18:03:32

Re: "Software necromancy" on AUR - ideas/feedback appreciated

#11 2014-08-11 18:41:23

Re: "Software necromancy" on AUR - ideas/feedback appreciated

#12 2014-08-12 10:34:12

Re: "Software necromancy" on AUR - ideas/feedback appreciated

#13 2014-08-16 23:53:31

Re: "Software necromancy" on AUR - ideas/feedback appreciated

#14 2014-08-19 07:53:12

Re: "Software necromancy" on AUR - ideas/feedback appreciated

#15 2014-08-19 14:51:53

Re: "Software necromancy" on AUR - ideas/feedback appreciated

#16 2014-12-17 06:04:43

Re: "Software necromancy" on AUR - ideas/feedback appreciated

#17 2014-12-18 00:40:19

Re: "Software necromancy" on AUR - ideas/feedback appreciated

#18 2014-12-18 09:30:34

Re: "Software necromancy" on AUR - ideas/feedback appreciated

#19 2014-12-18 14:58:50

Re: "Software necromancy" on AUR - ideas/feedback appreciated

#20 2014-12-18 15:06:08

Re: "Software necromancy" on AUR - ideas/feedback appreciated

#21 2014-12-22 12:27:40

Re: "Software necromancy" on AUR - ideas/feedback appreciated

#22 2014-12-22 18:01:59

Re: "Software necromancy" on AUR - ideas/feedback appreciated

#23 2014-12-31 23:37:01

Re: "Software necromancy" on AUR - ideas/feedback appreciated

Board footer