Subsurface-mobile build on F23

[Dirk Hohndel]

Hi Willem,

Let's try to keep discussions on the mailing list. There are a lot more knowledgable people than me on that list who might be willing to chime in...

> On Jan 24, 2016, at 9:32 AM, Willem Ferguson <willemferguson at zoology.up.ac.za> wrote:
> I few things I would like to briefly discuss. Hope this is ok?
> 
> 1) I need to get a basic approach to interact with the existing Subsurface desktop code. Currently the downloadFromDCWidget handles the download. Looks to me that that object is not directly usable. If this is so, it means one needs to write some parallel code to get the vendor and product names of dive computers from libdivecomputer. This parallel code may make sense because one needs to get only the products that are FTDI-compatible.

I think the right thing to do would be to break out the code that creates these models into its own class / source files. And then have an option that only adds those dive computers that are known to work on Android - which could initially be a white list. But I don't think it's smart to create a parallel implementation. That just means that the two will diverge, our code will bloat even more and will become even less maintainable. One of our big goals is to keep much of the code base shared so Subsurface-mobile benefits from all the work on the desktop app and vice versa.
Tomaz has been doing a herculean effort in raining this in (with the untangling of the profile from the desktop app, with the dive model, now with the settings, and with dozens of other pieces). It's always easier to just write something new (and I'm guilty, guilty, guilty of that. But the least I can do is to prevent others from making the same mistake :-)

> Also, probably writing some parallel code to initiate the actual download process. I assume the most sensible approach would be to keep new C++ code within QMLManager.cpp. Is this correct? There needs to be some signalling between the QML and the C++ in order to supply the appropriate products, once a vendor has been selected. This would require at least one additional slot slot for QMLManager. Does this approach sound sensible at all? This QML code would also be a relatively easy way of starting with changes to the existing download code. I am dependent on your comments on the above.

I think several people have pointed out that the QMLManager is way overused already. This needs to be broken down into smaller objects with fewer methods to stay manageable. That said, that doesn't mean that you need to be the one to do that - so feel free to add another slot to the QMLManager and it will get cleaned up when someone steps up to do so.


> 2) I have long term use of a Tusa Zen IQ-900 dive computer (basically a rebranded Oceanic Atom 1 dc). I do not have a cable for it but the suppliers are close at hand. I do not know the dc but I will do enough downloads using Subsurface desktop to get familiar with it before messing around with downloads to mobile.

Excellent. I figured that you would have to have at least one dive computer that can be supported on Android for this to be workable.

> 3) After the above, the screen for listing the downloaded dives will probably require the most QML expertise. But at that stage I will hopefully be more comfortable with the system.

As you know, we already have such a screen. It will need some reworking, but it's a good starting point. And Sebastian has been exceptionably patient helping us with QML and Rick and Jan are starting to get the hang of it as well, so we should have more people able to chime in if you run into problems.

> 4) A question about QtCreator and cmake. When I load the CMakeLists.txt file, it runs cmake to create a project setup. Two things:
> a) It creates a directory "build-subsurface-Desktop_Default " within src.
> b) While attempting to create .cbp file it gives familiar error messages indicating it cannot find Grantlee5Config.cmake. This is on the screen where one has to provide command-line options that I assume must remain blank? It does not ask me for the location of the source or destination and I assume most of this is contained in CMakLists.txt.

When you go to "Projects" in QtCreator you can pick the build directory - pick the one that was used by the build.sh and it will all work. My guess is that's ~/src/subsurface/build-mobile for Subsurface-mobile and ~/src/subsurface/build for the desktop version.
I use two different "kits" in QtCreator for the two different incarnations of Subsurface. That works really well to be able to work on both desktop and mobile app.

Thanks for volunteering to work on the Android download from dive computer. That's something that a lot of people are hoping for in the mobile app. And even if this won't get fully functional in the first release of Subsurface-mobile - we'll definitely want it in the second release.

/D