Thought about a Qt port

[Dirk Hohndel]

Thiago Macieira <thiago at macieira.org> writes:
>
> Yes, cross-compilation to Windows is possible. I know that because there's one 
> certain Qt-based software that releases like that: VLC. If they can get 1.2 
> billion downloads, it means it works.
>
> Even though I share your feeling about working with Windows, I have personally 
> never tried cross-mingw. And upstream often breaks that, since it's not an 
> officially supported build environment for the Qt Project. But rest assured that 
> fixes come in quite quickly, even if not by the release.

Simply from a workflow perspective I would much prefer to be able to
cross build... I'll be happy to bug the maintainers to make sure that
stays possible. The simple logic is that I create all of our official
binaries. I have a Linux system with me most everywhere I go - and I can
dual boot it into a Mac if I have to (or remotely log into one of my
Macs at home).

>> > 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.
>
> I'd recommend sticking to QtWidgets as much as possible for two reasons:
>  1) closer to the comfort zone of the developers, like Dirk says
>  2) Qt 4 compatibility
> (in fact, I wonder if we should use .ui files at all)

Someone else brought up this issue with respect to picking Qt5 over
Qt4...

We want to be able to support at least the following distros:
Fedora (under support, currently 17/18)
openSUSE (under support, 12.1-12.3)
Ubuntu (12.04, 12.10, 13.04)
Debian (Squeeze, Wheezy - we actually dropped Squeeze support for a
while - so that's not quite as critical as Wheezy will be out before we
are ready).

I don't think Qt5 is available for all those, is it?

For all of these (maybe except Ubuntu 12.04) my guess is that we can
drop the oldest one as it will take us a while to get there and by that
time things will have rotated one further...

> As to the map view... I've seen demos of less than 500 lines that used OSP. I 
> can try to dig it them up if there's interest. Basically, they downloaded OSP 
> tiles on-demand, without caching. 

Interesting. Let's keep that in mind.

> Another alternative would be to use a web view and use OSP directly or Google 
> Maps via their JS API. Just note that this alternative means shipping the 
> QtWebKit library, which is "un-small".

Yeah - the reason we went with OSMGPSMAP is that it allows to display
the map without dragging in a whole browser...

>> > 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...
>
> Mac and Windows are fully supported in Qt 4 and 5. That said, I'd recommend 
> that Subsurface keep building on *both* major versions during the porting 
> effort. At some later point, you can make a decision to drop Qt 4 support.

See above, I think that's good.

> For Mac, you can probably just download the pre-built SDK from
> http://qt-project.org/downloads. This will install Qt Creator too, but
> note that you do not have to use it, unless you want to.
>
> For Windows, I'd recommend building yourself. The current binary downloads are 
> for hosted builds, plus the MinGW folks can't make up their minds about what 
> ABI to use.

Bleh. Not having a stable MinGW build really hurts me. Maybe we can
engage with them while we do this and help figure this out?

>> 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?
>
> I took a look at it and I'd propose the following:
>  - hack the Makefile a little more and give it basic Qt support
>  - in parallel, if someone is interested, try porting to qmake

Cool

> Adding basic C++ and Qt support to the Makefile isn't difficult. Adding support 
> for Qt resource files is also trivial, if that feature is ever needed. Support 
> for moc and uic can be done, but without a good dependency scanner, subsurface 
> will have to obey some strict rules about where the #includes can be placed 
> for the generated files. Or manually adjust the Makefile to declare the 
> dependencies.

I don't think I understand enough of the Qt build mechanics to
competently comment on this one... Hopefully some of the experienced Qt
developers here can take charge of this part :-)

> qmake is easy to use and good at *building*, but not at *detecting* stuff. If 
> you have hard dependencies you just want to use, qmake can do it. To detect, 
> the code will be a great deal uglier. Even for installation, it might be ugly.

I was actually quite frustrated with the amount of #ifdef's that we
ended up with by not making dependencies hard dependencies. Worse, one
could easily build without things like zlib and then major functionality
would be missing (ask me about that... the Windows binaries for 3.0 were
missing major chunks because I hadn't noticed that I had the wrong mingw
zlib packages installed and the build simply dropped everything that
required this).

So I'd much rather have hard requirements for the dependencies and do
less "detecting".

> In fact, maybe the ideal solution is hybrid: leave the current Makefile for 
> detecting and installing, but ask qmake to generate another Makefile for 
> building. Or if we can get the install rules working with qmake, create a 
> simple configure script.

This /sounds/ quite convoluted to me. Didn't you say earlier that it's
reasonably easy to simply have a plain Makefile that pulls all the
pieces together?

/D