Subsurface-mobile downloadfrom divecomputer

Dirk Hohndel dirk at hohndel.org
Sat Feb 13 09:45:35 PST 2016


Let's keep the conversation on list, please.

> On Feb 13, 2016, at 7:15 AM, Willem Ferguson <willemferguson at zoology.up.ac.za> wrote:
> 
> Dirk,
> I have a version where the mobile code populates the two comboboxes on the download screen. The action is as unreliable as hell, but with my preliminary tests with QML, there was a very poor performance of the desktop-QML interface, specifically with comboboxes. So I hope it is attributable to that reason.

I have seen weird things happen on the desktop with QML - things that work fine on device, fail on the desktop (like the bottom margin for scrolling a ListView). So it's possible that things will be better on Android. There's an easy way to find out :-)

> I have two requests:
> 1) I have now gone beyond the last patch that I submitted (I think 3 days ago) doing some first groundwork by removing some code from the usual binaries and putting it the downwnloadmanager class. Looks like that patch has not been implemented yet. So I can now submit a larger patch that INCLUDES the previous one and that, in addition, populates the vendor and product comboboxes.

That sounds excellent. Yes, please send a new patch set - as I'm sure you've noticed, I've been very focused on getting this first release out and spent all my time on cleaning up the issues found in the alphas and the beta (frankly, surprisingly little feedback on that - as usual, I guess (so why am I surprised?)).

> 2) I would like to see an .apk to see how this works on a real mobile device. There are three ways to go about this:
> 
> a) The downloadfromdivecomputer option is activated and moved to the Developer submenu in Subsurface-mobile where one can access it directly as a menu option. That allows me to submit patches in the normal way and gives me some feedback in terms of .apk installables.
> 
> No, there is only one way, the above option. The other options will create chaos unless I want to run a separate branch or something like that. Regular patch submissions are required, given the rapid rate of development of the mobile  code.
> 
> What do you think?

Here's my suggestion. I'll create a divecomputerDownload branch and apply your patches there. I'll work on keeping it reasonably in sync with master. And I'll build separate test binaries for that branch that you and those focused on this aspect of the project can work on.

We can then merge that branch after the first release of Subsurface-mobile is out. And get ready to include this in the second release.

> At the moment I am figuring out how to get communication between C++ and the progressBar.

I may be wrong but I think the way you'd do that is to have a Q_PROPERTY on the C++ side that you update with the progress value and then use that property on the QML side for the value in the progress bar. It should automagically be kept in sync as long as your setter on the C++ side raises the corresponding ...Changed signal every time it updates the value.

Does that make sense?

/D



More information about the subsurface mailing list