Thought about a Qt port

[Thiago Macieira]

On sábado, 30 de março de 2013 07.20.50, Dirk Hohndel wrote:
> > 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)...

Hi Dirk & all

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.

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

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. 

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

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

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.

> 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

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.

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.

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.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20130330/04c3ba83/attachment.sig>