Thought about a Qt port

[Alberto Mardegan]

Hi all,
  following up for Dirk's intentions [0] to consider a move to Qt, I'd
like to offer my help despite having very little free time. I'm not a
diver myself, but Subsurface is an interesting project and I have some
experience in porting Gtk+ code to Qt/QML, so I hope to be somehow
helpful. I also have some experience in building Qt apps on Mac and
Win32, though that's the part I'd happily leave to someone else.

I checked out Subsurface and built it. Being totally out of context I'm
not sure how to use it, but I managed to enter some data in it to see it
in action. As far as I can see, there are a couple of custom widgets
(the rating combobox and the dive profile graph), and the rest seem to
be standard Gtk widgets. I see that it uses OsmGpsMap to show a map and
pick a location (are there other uses for the maps?).

Given the above, my suggestion would be to go for a QtWidgets based
application: porting should be easier, and if we need it, we can still
embed a QML scene into it (actually, we'll almost certainly need to do
that because the Map view provided by QtLocation is QML only).

The other option is to go for a QML UI, and then the sub-choices are
whether to use the items provided by the QtQuick Controls project or
bake our own widgets.

So, summing up the options:
1) QtWidgets
2) QML
  a) QtQuick 2.0 (using QtQuick Controls)
  b) Pure QtQuick 2.0

I wouldn't recommend option 2a for this project, because -- despite
having a bright future ahead -- the QtQuick Controls project isn't quite
mature yet and if the reason for moving away from Gtk+ is a lot of small
little annoyances, we might even find more of them in QtQuick Controls.
Option 2b can be a lot of fun and bring very nice results, but will
probably take a long time and maybe some frustration to get things
working exactly as we want them to work. One of my applications, Mappero
Geotagger, is entirely made of hand-made UI elements [1].
Both the options above have the drawback that they require writing quite
some C++/QML glue code (C++ QObject subclasses exposing properties and
methods to QML).

Option 1 has, as I said, the advantage that it maps more closely to the
Gtk+ UI paradigm and would make porting easier. Then, if the port goes
successfully and people feel they want to use more of Qt, we can revisit
the decision.


An orthogonal question to the above is whether we want to use Qt4 or
Qt5. Apart from option 2a, which isn't possible in Qt4 (there is no
QtQuick Controls there), for the others we have the choice of using Qt4
or Qt5. With almost no code changes if we go for the QtWidget approach,
and some minor changes for the QML approach.
I don't have a strong opinion on this, but unless someone finds some
reasons to stick with Qt4, I'd suggest starting with Qt5.


One more question is how much of the code we want to be left in C. Qt
makes handling of files (especially XML) very easy, as well as handling
of strings, and playing with data structures (hash tables, arrays and
the like).


The last question (and the spiciest of all) is of course about the build
system. :-) I generally use qmake; despite not liking it too much, it
just works and I found it especially easy when building in OS X or
Windows. I never used Qt with plain make, but I have tried it before
with autotools and waf, so it's certainly possible.


Waiting for comments. It would also be interesting to know how is in
:-), to have a better idea of how to go forward.

Ciao,
  Alberto

[0] https://plus.google.com/u/0/105872806106213007611/posts/MwiTc3cHKgi
[1] http://www.youtube.com/watch?v=b1J84dISuNk
-- 
http://blog.mardy.it <- geek in un lingua international!