Thought about a Qt port

[Dirk Hohndel]

Alberto Mardegan <mardy at users.sourceforge.net> writes:

> 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.

Excellent - we really appreciate the help.

> 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 did the initial port of Subsurface to Windows and Mac. The Windows
port is a complete cross build (is that possible with Qt - I just hate
working under Windows and avoid it as much as possible)...

> 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.

Have you looked at the documentation at
http://subsurface.hohndel.org/documentation/user-manual ? That should
give you at least some idea of how things are intended to work...

> 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?).

I think that's a very good summary of what we do. There is a map view
that shows all the dive location in an overview, there is a map view
that shows just the location of a specific dive, and the ability to use
that same widget to enter a location.

> 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).

That was my goal. I played with QML when the Trolls were first working
on it a few years ago - I find it intriguing but I think it is too far
away from the comfort zone of most of the developers here.

> 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.

I think that describes where we ended up now - Linus started with Gtk
and we revisited that decision multiple times over the past year as
almost all of us hated Gtk.

A word of warning: Linus has very strong feelings about all the things
that are wrong with C++ and at times has been known to be less
diplomatic than me when explaining his point of view... :-)
But he made a clear statement that he is interested in seeing this port
happening, as long as most of the program logic that is not UI code
stays in (quote) "sane C files". So please keep that in mind as we drive
this further.

> 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.

What is the status of Qt5 for Windows and Mac? Are the fully supported
implementations? I normally would also suggest to start at the latest
version, but want to make sure that there are no Gotchas...

> One more question is how much of the code we want to be left in C.

The simple answer? "as much as possible".

> 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).

I think this topic is one of those "if everyone falls in love with Qt
and wakes up one morning no longer hating C++ and its pitfalls so much,
let's revisit the question" things. For now we really would like to
focus as much as possible on JUST changing the UI code.

> 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.

We don't use autotools now, we won't move to them for a Qt build. Right
now we have a hacked together Makefile that does a lot of fun things for
us.

I have never tried to use qmake but hear even less love for it than for
autotools (and that is saying a lot). Maybe we can start with qmake for
the initial exploration / prototype and as we move towards a first
buildable version that maps out the UI and links it with the existing
logic we can revisit this question as well?

Another thing to point out is that we would really like to stay with
gettext if possible - we have more than a dozen translations and don't
want to lose that (and frankly see no advantage in moving off of
gettext). 

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

I am definitely in, as are a hand full of the existing developers. For
your understanding, the current UI code has been 90+% written by Linus,
myself and Lubomir. Lately a few more developers have started to
contribute (Amit, Robert, Pierre, Salvador and others) but that was when
it really became obvious how much everyone struggled with the Gtk
limitations. I know that Linus, Lubomir, Amit and Jan are intersted in
the Qt port. As are some potential new developers that have spoken up on
Google+ (or at a conference that Linus and I attended earlier this
year). 

Others who are interested in contributing, please speak up!

My plan was to create a Qt branch in the git repository and do all the
work there so that we can continue to do update releases from master... 
it's hard to know how long this could take and I don't want Subsurface
to go dark on its users in the meantime. Feel free to set up
repositories on github and send pull requests (but please DON'T use the
github "send pull request" feature, just use git locally on your machine
to do so - that makes merging much easier for me.

Thanks

/D