Fwd: Re: Subsurface-mobile downloadfrom divecomputer

[Willem Ferguson]

Thank you for the comment. I realise you were uber-occupied the last week.

On 13/02/2016 19:45, Dirk Hohndel wrote:
> Let's keep the conversation on list, please.
>
>> 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?)).
>
  I need to filter the above dive computer names to those with FTDI
interfaces. In libdivecomputer the dc_descriptor_t contains a lot of
information, for instance the transport definition. In addition there is
dc_type that also has information. Which is the mechanism to detect
which compuyers have an FTDI interface?

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

I would be perfectly happy.
>> 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?

It makes very much sense, but the problem is that QComboBox takes a
variable of data type 'real' to indicate progress. No indication on
whether this is 16-bit, 32-bit or even longer. In c++ I translated that
as float but this is currently not working.  The combobox value is not
overloaded for other formats. Calling the setter  that provides a float
from C++ currently creates a segfault. But I will get there.

I am looking at updating the mobile user manual, but am waiting for a UI
that does not change rapidly. Looks like we are close.

KInd regards,
willem