Re: Subsurface-mobile for Android -845

[Thomas Pfeiffer]

On Samstag, 13. Februar 2016 10:35:50 CET Henrik Brautaset Aronsen wrote:
> On Sat, Feb 13, 2016 at 9:59 AM, Henrik Brautaset Aronsen <
> 
> subsurf...@henrik.synth.no> wrote:
> > Just a couple of things: The title bar is too cramped now.  Other apps use
> > that to display info on the current context.  We could display "Dive list"
> > or "Dive #643" or "Edit dive #242" or "About" there in the future.
> > 
> > And since we're going for the action button design, how about making it
> > more like the action buttons in other apps, i.e. larger and more to the
> > right?

+1 for making it bigger (I don't know why it's currently so small, it was 
bigger in our mockups). I wouldn't push it to the side, though, because it can 
still be dragged to open drawers, so the center position is best for that.

Even though Subsurface uses no context drawer at the moment doesn't mean that 
it never will, so I wouldn't recommend optimizing the overall UI for not 
having one

Also, there are some Google apps which have the action button at the center 
(e.g. Phone or Clock), even though most have it on the right.

> And if possible, why not go all in:  It looks like the google apps (e.g.
> Google Plus and Photos) hide the top bar and the action button as you
> scroll downwards in a list (or large page), giving full access to the
> screen estate.

Marco had the idea to hide the top bar when scrolling as well, and it 
absolutely makes sense to me, since people should still remember where they 
are even when they scroll down.
I'm not so sure about the action button, though, given that it holds the most 
important action on a screen.

Cheers,
Thomas (responsible for the KDE mobile HIG)
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

[PATCH 3/3] QML UI: enable edit of gasmix

[Joakim Bygdell]

First cylinder only, show warning if there are more than one cylinder defined.

Signed-off-by: Joakim Bygdell 
---
 qt-mobile/qml/DiveDetails.qml |  3 +++
 qt-mobile/qml/DiveDetailsEdit.qml | 13 -
 qt-mobile/qml/main.qml|  1 +
 qt-mobile/qmlmanager.cpp  |  9 -
 qt-mobile/qmlmanager.h|  2 +-
 5 files changed, 25 insertions(+), 3 deletions(-)

diff --git a/qt-mobile/qml/DiveDetails.qml b/qt-mobile/qml/DiveDetails.qml
index 5a39576..c906ba2 100644
--- a/qt-mobile/qml/DiveDetails.qml
+++ b/qt-mobile/qml/DiveDetails.qml
@@ -24,6 +24,7 @@ MobileComponents.Page {
property alias weight: detailsEdit.weightText
property alias startpressure: detailsEdit.startpressureText
property alias endpressure: detailsEdit.endpressureText
+   property alias gasmix: detailsEdit.gasmixText
 
state: "view"
 
@@ -128,10 +129,12 @@ MobileComponents.Page {
if (diveDetailsListView.currentItem.modelData.dive.getCylinder 
!= "Multiple" ) {
startpressure = 
diveDetailsListView.currentItem.modelData.dive.startPressure
endpressure = 
diveDetailsListView.currentItem.modelData.dive.endPressure
+   gasmix = 
diveDetailsListView.currentItem.modelData.dive.firstGas
} else {
// careful when translating, this text is "magic" in 
DiveDetailsEdit.qml
startpressure = "cannot edit multiple cylinders"
endpressure = "cannot edit multiple cylinders"
+   gasmix = "cannot edit multiple gases"
}
 
diveDetailsPage.state = "edit"
diff --git a/qt-mobile/qml/DiveDetailsEdit.qml 
b/qt-mobile/qml/DiveDetailsEdit.qml
index f2b0462..ae943ca 100644
--- a/qt-mobile/qml/DiveDetailsEdit.qml
+++ b/qt-mobile/qml/DiveDetailsEdit.qml
@@ -24,6 +24,7 @@ Item {
property alias weightText: txtWeight.text
property alias startpressureText: txtStartPressure.text
property alias endpressureText: txtEndPressure.text
+   property alias gasmixText: txtGasMix.text
 
height: editArea.height
ColumnLayout {
@@ -147,6 +148,16 @@ Item {
 
MobileComponents.Label {
Layout.alignment: Qt.AlignRight
+   text: "Gas mix:"
+   }
+   TextField {
+   id: txtGasMix
+   readOnly: (text == "cannot edit multiple gases" 
? true : false)
+   Layout.fillWidth: true
+   }
+
+   MobileComponents.Label {
+   Layout.alignment: Qt.AlignRight
text: "Start Pressure:"
}
TextField {
@@ -192,7 +203,7 @@ Item {
manager.commitChanges(dive_id, 
detailsEdit.dateText, detailsEdit.locationText, detailsEdit.gpsText, 
detailsEdit.durationText,
  detailsEdit.depthText, 
detailsEdit.airtempText, detailsEdit.watertempText, detailsEdit.suitText,
  detailsEdit.buddyText, 
detailsEdit.divemasterText, detailsEdit.weightText, detailsEdit.notesText,
- 
detailsEdit.startpressureText, detailsEdit.endpressureText)
+ 
detailsEdit.startpressureText, detailsEdit.endpressureText, 
detailsEdit.gasmixText)
// apply the changes to the dive detail view - 
since the edit could have changed the order
// first make sure that we are looking at the 
correct dive - our model allows us to look
// up the index based on the unique dive_id
diff --git a/qt-mobile/qml/main.qml b/qt-mobile/qml/main.qml
index 2c066e2..68696b6 100644
--- a/qt-mobile/qml/main.qml
+++ b/qt-mobile/qml/main.qml
@@ -84,6 +84,7 @@ MobileComponents.ApplicationWindow {
detailsWindow.duration = ""
detailsWindow.suit = ""
detailsWindow.weight = ""
+   detailsWindow.gasmix = ""
detailsWindow.startpressure = ""
detailsWindow.endpressure = ""
stackView.push(detailsWindow)
diff --git a/qt-mobile/qmlmanager.cpp b/qt-mobile/qmlmanager.cpp
index cd45d30..422a77e 100644
--- a/qt-mobile/qmlmanager.cpp
+++ b/qt-mobile/qmlmanager.cpp
@@ -353,7 +353,7 @@ void QMLManager::refreshDiveList()
 // update the dive and return 

[PATCH 1/3] Add helper function to retrieve first gas

[Joakim Bygdell]

Signed-off-by: Joakim Bygdell 
---
 subsurface-core/subsurface-qt/DiveObjectHelper.cpp | 7 +++
 subsurface-core/subsurface-qt/DiveObjectHelper.h   | 2 ++
 2 files changed, 9 insertions(+)

diff --git a/subsurface-core/subsurface-qt/DiveObjectHelper.cpp 
b/subsurface-core/subsurface-qt/DiveObjectHelper.cpp
index 8a44c0e..38b 100644
--- a/subsurface-core/subsurface-qt/DiveObjectHelper.cpp
+++ b/subsurface-core/subsurface-qt/DiveObjectHelper.cpp
@@ -292,3 +292,10 @@ QString DiveObjectHelper::endPressure() const
QString endPressure = getPressures(m_dive, END_PRESSURE);
return endPressure;
 }
+
+QString DiveObjectHelper::firstGas() const
+{
+   QString gas;
+   gas = get_gas_string(m_dive->cylinder[0].gasmix);
+   return gas;
+}
diff --git a/subsurface-core/subsurface-qt/DiveObjectHelper.h 
b/subsurface-core/subsurface-qt/DiveObjectHelper.h
index 5d8abfd..a4a425a 100644
--- a/subsurface-core/subsurface-qt/DiveObjectHelper.h
+++ b/subsurface-core/subsurface-qt/DiveObjectHelper.h
@@ -37,6 +37,7 @@ class DiveObjectHelper : public QObject {
 Q_PROPERTY(QString getCylinder READ getCylinder CONSTANT)
 Q_PROPERTY(QString startPressure READ startPressure CONSTANT)
 Q_PROPERTY(QString endPressure READ endPressure CONSTANT)
+Q_PROPERTY(QString firstGas READ firstGas CONSTANT)
 public:
DiveObjectHelper(struct dive *dive = NULL);
~DiveObjectHelper();
@@ -72,6 +73,7 @@ public:
QString getCylinder() const;
QString startPressure() const;
QString endPressure() const;
+   QString firstGas() const;
 
 private:
struct dive *m_dive;
-- 
2.4.9 (Apple Git-60)

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

[PATCH 2/3] Add helper function to parse gasmix strings

[Joakim Bygdell]

Signed-off-by: Joakim Bygdell 
---
 subsurface-core/helpers.h|  2 ++
 subsurface-core/qthelper.cpp | 41 +
 2 files changed, 43 insertions(+)

diff --git a/subsurface-core/helpers.h b/subsurface-core/helpers.h
index 7537818..44f25f5 100644
--- a/subsurface-core/helpers.h
+++ b/subsurface-core/helpers.h
@@ -36,6 +36,8 @@ int parseLengthToMm(const QString );
 int parseTemperatureToMkelvin(const QString );
 int parseWeightToGrams(const QString );
 int parsePressureToMbar(const QString );
+int parseGasMixO2(const QString );
+int parseGasMixHE(const QString );
 QString get_dive_duration_string(timestamp_t when, QString hourText, QString 
minutesText);
 QString get_dive_date_string(timestamp_t when);
 QString get_short_dive_date_string(timestamp_t when);
diff --git a/subsurface-core/qthelper.cpp b/subsurface-core/qthelper.cpp
index 07ec194..a889233 100644
--- a/subsurface-core/qthelper.cpp
+++ b/subsurface-core/qthelper.cpp
@@ -885,6 +885,47 @@ int parsePressureToMbar(const QString )
return mbar;
 }
 
+int parseGasMixO2(const QString )
+{
+   QString gasString = text;
+   int o2, number;
+   if (gasString.contains(QObject::tr("AIR"), Qt::CaseInsensitive)) {
+   o2 = O2_IN_AIR;
+   }
+   else if (gasString.contains(QObject::tr("EAN"), Qt::CaseInsensitive)) {
+   gasString.remove(QRegExp("[^0-9]"));
+   number = gasString.toInt();
+   o2 = number * 10;
+   }
+   else if (gasString.contains("/")) {
+   QStringList gasSplit = gasString.split("/");
+   number = gasSplit[0].toInt();
+   o2 = number * 10;
+   }
+   else {
+   number = gasString.toInt();
+   o2 = number * 10;
+   }
+   
+   return o2;
+}
+
+int parseGasMixHE(const QString )
+{
+   QString gasString = text;
+   int he, number;
+   if (gasString.contains("/")) {
+   QStringList gasSplit = gasString.split("/");
+   number = gasSplit[1].toInt();
+   he = number * 10;
+   }
+   else {
+   he = 0;
+   }
+   
+   return he;
+}
+
 QString get_dive_duration_string(timestamp_t when, QString hourText, QString 
minutesText)
 {
int hrs, mins;
-- 
2.4.9 (Apple Git-60)

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Subsurface-mobile downloadfrom divecomputer

[Dirk Hohndel]

Let's keep the conversation on list, please.

> On Feb 13, 2016, at 7:15 AM, Willem Ferguson 
>  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

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Subsurface-mobile for Android -845

[Dirk Hohndel]

On Sat, Feb 13, 2016 at 09:29:34AM +0100, Joakim Bygdell wrote:
> > 
> > 845 should address the issues that were mentioned
> > 
> > - I think I finally figured out the hang with incorrect credentials
> > - I FINALLY paid enough attention to realize why the 'Save' after an edit 
> > accessed the network - that should be fixed now
> > - the redundant context menus are gone. Android users are comfortable using 
> > the back button to go up / back a level and to cancel an operation
> > 
> > So I think this is the UI direction I'm leaning towards. Small title bar 
> > with no menus / buttons. Action button when there's an action. Handle to 
> > open global menu / drawer (but swipe from the side works as well). Right 
> > now we have no screen that has a context menu.
> The handle that opens the drawer should maybe be a bit more transparent to 
> start with, not the arrow but the background.

Yes, there is definitely some fine tuning to be done here.

> The action button we need to do something with as well, right now you have  
> to scroll all the way to the bottom ft prevent the 
>  action button form obscuring stuff on the details and edit pages.

I find that an interesting comment. Let me try to figure out if I
understand what you are saying: when you are in the middle of the dive
list, the action button is obscuring a small part in the center of the
bottom dive that is visible (assuming you are on a phone or tablet in
portrait mode - in landscape mode it really isn't in the way at all as it
sits on the center divider). So what is stopping you from scrolling up by
one dive to see the dive that you want to see? I don't understand your
refference to "have to scroll all the way to the bottom" of the dive list.
Or are you saying you'd like to have this white margin at the bottom all
the time? Because I'd hate that as wasted screen real estate.

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Subsurface-mobile for Android -845

[Joakim Bygdell]

> On 13 Feb 2016, at 18:52, Dirk Hohndel  wrote:
> 
> On Sat, Feb 13, 2016 at 09:29:34AM +0100, Joakim Bygdell wrote:
>>> 
>>> 845 should address the issues that were mentioned
>>> 
>>> - I think I finally figured out the hang with incorrect credentials
>>> - I FINALLY paid enough attention to realize why the 'Save' after an edit 
>>> accessed the network - that should be fixed now
>>> - the redundant context menus are gone. Android users are comfortable using 
>>> the back button to go up / back a level and to cancel an operation
>>> 
>>> So I think this is the UI direction I'm leaning towards. Small title bar 
>>> with no menus / buttons. Action button when there's an action. Handle to 
>>> open global menu / drawer (but swipe from the side works as well). Right 
>>> now we have no screen that has a context menu.
>> The handle that opens the drawer should maybe be a bit more transparent to 
>> start with, not the arrow but the background.
> 
> Yes, there is definitely some fine tuning to be done here.
> 
>> The action button we need to do something with as well, right now you have  
>> to scroll all the way to the bottom ft prevent the 
>> action button form obscuring stuff on the details and edit pages.
> 
> I find that an interesting comment. Let me try to figure out if I
> understand what you are saying: when you are in the middle of the dive
> list, the action button is obscuring a small part in the center of the
> bottom dive that is visible (assuming you are on a phone or tablet in
> portrait mode - in landscape mode it really isn't in the way at all as it
> sits on the center divider). So what is stopping you from scrolling up by
> one dive to see the dive that you want to see? I don't understand your
> refference to "have to scroll all the way to the bottom" of the dive list.
> Or are you saying you'd like to have this white margin at the bottom all
> the time? Because I'd hate that as wasted screen real estate.
Not the dive list, but on details and edit page. 

> /D

/Jocke

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Subsurface-mobile for Android -845

[Dirk Hohndel]

On Sat, Feb 13, 2016 at 09:59:27AM +0100, Henrik Brautaset Aronsen wrote:
> On Sat, Feb 13, 2016 at 8:07 AM, Dirk Hohndel  wrote:
> >
> > There certainly is room for fine-tuning (I just noticed that the icon /
> > text in the title bar aren't vertically centered - also the drawer handle
> > maybe isn't the final design, yet - this is just my quick hack to give
> > Thomas and Marco an idea of what I'm thinking). But unless I hear strong
> > and well reasoned feedback from Henrik or some of the others who have been
> > rather outspoken on wanting the more Android typical menu / action buttons
> > in the top bar, I think that's where we'll go.
> >
> 
> Hi!  I think it looks pretty decent now.  I like that there is less clutter.

Yay!

> Just a couple of things: The title bar is too cramped now.  Other apps use
> that to display info on the current context.  We could display "Dive list"
> or "Dive #643" or "Edit dive #242" or "About" there in the future.

That's a good idea... but I think I like the idea of it simply fading away
even better.

> And since we're going for the action button design, how about making it
> more like the action buttons in other apps, i.e. larger and more to the
> right?

Thomas answered the "more to the right" question. But there's another
reason. Right now, when you use your device in landscape mode you get the
action button right on the center divider which is perfect, IMHO.

> And one more (less related) thing:  If I edit a dive and press the back
> button (instead of save), I should get a request: "Discard edits? [Yes /
> Save edits / Cancel]

I hate those dialogs on some level, but I guess you are right.

Thomas, what's the HID approved way of doing something like that?

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Subsurface-mobile for Android -845

[Dirk Hohndel]

On Sat, Feb 13, 2016 at 06:55:36PM +0100, Joakim Bygdell wrote:
> > 
> >> The action button we need to do something with as well, right now you have 
> >>  to scroll all the way to the bottom ft prevent the 
> >> action button form obscuring stuff on the details and edit pages.
> > 
> Not the dive list, but on details and edit page. 

DUH. You said that right there. So we need to do something similar to be
able to scroll those pages up higher.

Can you file a bug so I don't forget?

Thanks

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Android alpha -838 with experimental mobile components change

[Dirk Hohndel]

On Sat, Feb 13, 2016 at 09:38:11AM +, David Tillotson wrote:
> On Fri, 12 Feb 2016 14:07:03 -0800
> Dirk Hohndel  wrote:
> > >> Attached is a profile from a manually added dummy dive, that seems
> > >> to have set the width to 2:30 hours for some reason.
> > 
> > This often happens if there is conflicting information in the dive
> > data. Can you access this dive from the desktop application and
> > export it as XML and send the XML?
> 
> XML export attached - It looks OK to me, apart from having six "empty"
> samples.

Those samples don't look right to me. How did you create that dive?
You added this in the Android app?
I'll need to add this to my dive list to see if I can reproduce the
2h30min duration problem...

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

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





___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Subsurface-mobile for Android -845

[Willem Ferguson]

I ran 849 on two Android versions 4.3 and 5.1.1. Appears pretty stable, 
especially on Android 4.3. A few points or suggestions, :


1) In Show GPS fixes, the text flows underneath the three lines forming 
the drag point on the right of each GPS record. In 5.1.1 this is worse 
than with 4.3.


2) About the right-hand action panel (context menu?), I would not rule 
it out at this point altogether. For instance after editing, the SAVE 
button at the bottom is located in a little bit of an unexpected place. 
A context menu with SAVE CHANGES and QUIT WITHOUT SAVING could work. Of 
course this creates the question of what the Action Button should do in 
this situation, so I can understand if a context menu is not implemented 
here.


3) Text in the landing screen has a left margin pretty close to the left 
edge of the screen.


4) I have now loaded a full dive log (only some 200 dives) onto both 
mobile devices and I was surprised how rapidly a fairly large data set 
was loaded. After loading these data using 845, however, the program 
unpredictably crashes at startup. Attached a logcat. I would say about 
60% of startups end in a crash. Those that start up behave pretty 
normally, no obvious anomalies. With 849 still the same problem. If 
necessary I can collect more information.


Kind regards,
willem





logcatwf.dat.tar.gz
Description: application/gzip
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Subsurface-mobile for Android -845

[Joakim Bygdell]

> On 13 Feb 2016, at 08:07, Dirk Hohndel  wrote:
> 
> Hi there.
> 
> 845 should address the issues that were mentioned
> 
> - I think I finally figured out the hang with incorrect credentials
> - I FINALLY paid enough attention to realize why the 'Save' after an edit 
> accessed the network - that should be fixed now
> - the redundant context menus are gone. Android users are comfortable using 
> the back button to go up / back a level and to cancel an operation
> 
> So I think this is the UI direction I'm leaning towards. Small title bar with 
> no menus / buttons. Action button when there's an action. Handle to open 
> global menu / drawer (but swipe from the side works as well). Right now we 
> have no screen that has a context menu.
The handle that opens the drawer should maybe be a bit more transparent to 
start with, not the arrow but the background.

The action button we need to do something with as well, right now you have  to 
scroll all the way to the bottom ft prevent the 
 action button form obscuring stuff on the details and edit pages.

> 
> There certainly is room for fine-tuning (I just noticed that the icon / text 
> in the title bar aren't vertically centered - also the drawer handle maybe 
> isn't the final design, yet - this is just my quick hack to give Thomas and 
> Marco an idea of what I'm thinking). But unless I hear strong and well 
> reasoned feedback from Henrik or some of the others who have been rather 
> outspoken on wanting the more Android typical menu / action buttons in the 
> top bar, I think that's where we'll go.
> 
> I realize that I'm going back and forth on this. Guilty as charged. This is 
> hard. But I spent almost an hour with a 4" phone, a 5.7" phone, a 7" tablet 
> and a 10" tablet and I think I'm happy with what we have.
> 
> Assuming we can get reasonable consensus (or only mostly unconvincing 
> whining), I'll do a second beta based on this UI idea (after Marco helps me 
> with the fine tuning mentioned above).
> 
> Thoughts? Comments?
> 
> /D
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

/Jocke

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Subsurface-mobile for Android -845

[Henrik Brautaset Aronsen]

On Sat, Feb 13, 2016 at 9:59 AM, Henrik Brautaset Aronsen <
subsurf...@henrik.synth.no> wrote:

>
> Just a couple of things: The title bar is too cramped now.  Other apps use
> that to display info on the current context.  We could display "Dive list"
> or "Dive #643" or "Edit dive #242" or "About" there in the future.
>
> And since we're going for the action button design, how about making it
> more like the action buttons in other apps, i.e. larger and more to the
> right?
>

And if possible, why not go all in:  It looks like the google apps (e.g.
Google Plus and Photos) hide the top bar and the action button as you
scroll downwards in a list (or large page), giving full access to the
screen estate.

Henrik
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Subsurface-mobile for Android -845

[Henrik Brautaset Aronsen]

On Sat, Feb 13, 2016 at 8:07 AM, Dirk Hohndel  wrote:

> Hi there.
>
> There certainly is room for fine-tuning (I just noticed that the icon /
> text in the title bar aren't vertically centered - also the drawer handle
> maybe isn't the final design, yet - this is just my quick hack to give
> Thomas and Marco an idea of what I'm thinking). But unless I hear strong
> and well reasoned feedback from Henrik or some of the others who have been
> rather outspoken on wanting the more Android typical menu / action buttons
> in the top bar, I think that's where we'll go.
>

Hi!  I think it looks pretty decent now.  I like that there is less clutter.

Just a couple of things: The title bar is too cramped now.  Other apps use
that to display info on the current context.  We could display "Dive list"
or "Dive #643" or "Edit dive #242" or "About" there in the future.

And since we're going for the action button design, how about making it
more like the action buttons in other apps, i.e. larger and more to the
right?

And one more (less related) thing:  If I edit a dive and press the back
button (instead of save), I should get a request: "Discard edits? [Yes /
Save edits / Cancel]

Henrik
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Android alpha -838 with experimental mobile components change

[David Tillotson]

On Fri, 12 Feb 2016 14:07:03 -0800
Dirk Hohndel  wrote:
> >> Attached is a profile from a manually added dummy dive, that seems
> >> to have set the width to 2:30 hours for some reason.
> 
> This often happens if there is conflicting information in the dive
> data. Can you access this dive from the desktop application and
> export it as XML and send the XML?

XML export attached - It looks OK to me, apart from having six "empty"
samples.

-- 
David Tillotson

dummy.xml
Description: XML document
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Subsurface-mobile for Android -845

[Thomas Pfeiffer]

On Samstag, 13. Februar 2016 09:57:21 CET Dirk Hohndel wrote:
> > Hi!  I think it looks pretty decent now.  I like that there is less
> > clutter.
> Yay!

Yay++

> > Just a couple of things: The title bar is too cramped now.  Other apps use
> > that to display info on the current context.  We could display "Dive list"
> > or "Dive #643" or "Edit dive #242" or "About" there in the future.
> 
> That's a good idea... but I think I like the idea of it simply fading away
> even better.

+1 for fading away.

> > And since we're going for the action button design, how about making it
> > more like the action buttons in other apps, i.e. larger and more to the
> > right?
> 
> Thomas answered the "more to the right" question. But there's another
> reason. Right now, when you use your device in landscape mode you get the
> action button right on the center divider which is perfect, IMHO.
> 
> > And one more (less related) thing:  If I edit a dive and press the back
> > button (instead of save), I should get a request: "Discard edits? [Yes /
> > Save edits / Cancel]
> 
> I hate those dialogs on some level, but I guess you are right.
 
> Thomas, what's the HID approved way of doing something like that?

We originally had the idea that for "swipe to go back/forward" or "column-
based navigation", one could simply swipe forward again to get back to the 
already entered/changed data if one has accidentally swiped back without 
saving (before navigating somewhere else). That's not as easily possible when 
using the back button, of course.

Google's apps for Android (those which do not auto-save) do use such a dialog. 
They all use a Discard/Cancel approach (though with completely different 
wording and even inconsistent button position between the apps, which is 
really bad design).
We haven't written about it in the HIG yet (we'll still add one guideline for 
that), but here's what I'd suggest:
"Discard your changes?" [Discard] [Keep Editing]". This makes saving take one 
more step, but we want to train users to just hit "Save" anyway, and it makes 
the decision in the dialog easier.
There is already a component for a slide-in dialog available (don't know its 
name, though, tbh. If you can't find it, ask Marco).

Cheers,
Thomas
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Subsurface-mobile for Android -845

[Dirk Hohndel]

> On Feb 13, 2016, at 8:52 PM, Rick Walsh  wrote:
> > Another thing - In the dive list, there's a blank row above the trip
> > separator line.  I'm not sure if that's deliberate, but it looks like a
> > waste of space to me.
> 
> Do you have a screen shot?
> 
> See attached
>  

Those blank rows are the trip titles...

/D___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Subsurface-mobile for Android -845

[Dirk Hohndel]

On Sun, Feb 14, 2016 at 03:52:44PM +1100, Rick Walsh wrote:
> > So I tried to implement something that I find reasonable and intuitive.
> >
> > - there's still the save button
> > - the action button is cancel and there is NO CONFIRMATION - you hit that
> >   button, you get what you asked for
> > - the back button asks the user if they really wanted to discard the
> >   changes, and if they don't confirm within 3 seconds it simply hides the
> >   confirmation dialog and pretends nothing happens
> >
> > Please play with it, the description sounds a lot more awkward that it
> > felt to me to use...
> >
> 
> The logic is good, and the description makes sense.  The reasons I'd rather
> the action button be 'save' are:
> (1) I'm lazy and if all I want to do is enter/alter a couple of details
> (e.g. dive site and buddy), then I don't want to have to scroll down to the
> bottom of the page to find the save button
> (2) we effectively have two quick-access buttons: the action button and the
> back button.  Having both do the same thing (with or without confirmation)
> is a bit of a waste.  We have two actions that should be accessed rapidly:
> save and discard.  The back button can be used to discard changes, so it
> makes sense to me that the action button would be save.
> (3) let's trust the user knows what she's doing - more often than not, when
> the user wants to leave the page, she wants to save changes.  We should
> make that as easy as possible.

I can see your point. So let me rip out the work that I did and implement
that instead.

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Subsurface-mobile 854 - now even more Plasma-mobile than ever before

[Joakim Bygdell]

> On 14 Feb 2016, at 07:23, Dirk Hohndel  wrote:
> 
> 
> So based on the feedback received and the discussion here on the list, I
> decided to go all the way...
> 
> - all the save buttons on the pages are gone
> - the action button is used for the main action on any page, including all
>  the save actions (this is for preferences, credentials, edits, etc)
> - the back button is used for the go-back, discard, abort style actions
>  everywhere (without confirmation dialog)
> 
> In order for this to work a couple of patches to the mobile components are
> needed. They were all sent to the plasma-devel mailing list -- actually,
> only one is really /needed/ at this point. One is actually no longer
> relevant (because we don't use context menus) and one is more a visual
> thing and won't prevent functionality. So building from source will have
> almost everything work as expected - except when you decide to change
> credentials and then change your mind and hit the back key. Oops, you just
> quit Subsurface. That's fixed in my APK and in last of the patches I sent
> to the plasma-devel list :-)
> 
> Please test. I know, I keep saying that and I have to say I am thrilled
> with all the feedback you are giving. I think this is really shaping up to
> be a very strong first release.
> 
> I'll give it a day or two for testing and then hopefully I can make a
> second beta with the updated UI.

Issues found:
Cloud credentials page:
If you have valid cloud credentials in place it is not possible to go back to 
the divelist,
pressing the action button does nothing and the back button closes the app.
You can’t go back by selecting “Dive list” in the menu either.

Selecting sub-menues does not close the lefthand drawer, 
the page is loaded in the background and the drawer is returned to the top 
level listings.
* Show GPS fixes
* App log
* Divelist
* Add dive

Canceling the Add dive does not show you the divelist, but the details page of 
the last dive in the list.

> 
> /D
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

/Jocke

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Subsurface-mobile 854 - now even more Plasma-mobile than ever before

[Dirk Hohndel]

So based on the feedback received and the discussion here on the list, I
decided to go all the way...

- all the save buttons on the pages are gone
- the action button is used for the main action on any page, including all
  the save actions (this is for preferences, credentials, edits, etc)
- the back button is used for the go-back, discard, abort style actions
  everywhere (without confirmation dialog)

In order for this to work a couple of patches to the mobile components are
needed. They were all sent to the plasma-devel mailing list -- actually,
only one is really /needed/ at this point. One is actually no longer
relevant (because we don't use context menus) and one is more a visual
thing and won't prevent functionality. So building from source will have
almost everything work as expected - except when you decide to change
credentials and then change your mind and hit the back key. Oops, you just
quit Subsurface. That's fixed in my APK and in last of the patches I sent
to the plasma-devel list :-)

Please test. I know, I keep saying that and I have to say I am thrilled
with all the feedback you are giving. I think this is really shaping up to
be a very strong first release.

I'll give it a day or two for testing and then hopefully I can make a
second beta with the updated UI.

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Subsurface-mobile for Android -845

[Dirk Hohndel]

> On Feb 13, 2016, at 10:33 PM, Willem Ferguson 
>  wrote:
> 
> On 14/02/2016 06:18, Dirk Hohndel wrote:
>> On Sat, Feb 13, 2016 at 09:59:36PM +0200, Willem Ferguson wrote:
>>> I ran 849 on two Android versions 4.3 and 5.1.1. Appears pretty stable,
>>> especially on Android 4.3. A few points or suggestions, :
>>> 
>>> 1) In Show GPS fixes, the text flows underneath the three lines forming the
>>> drag point on the right of each GPS record. In 5.1.1 this is worse than with
>>> 4.3.
>> I think this is more a font-size to screen-size issue than a 4.3 vs 5.1.1
>> issue. Do you have a screen shot?
>> 
> Attached

As expected. Font size. I wonder why the fonts on your device are so big,
relatively speaking. Do you have any overall Android settings that would
increase the default font size? I'd hate to have to add some heuristics that
would make us shrink the fonts for certain ratios of font size and screen 
width...

/D

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Fwd: Re: Subsurface-mobile downloadfrom divecomputer

[Willem Ferguson]

On 14/02/2016 06:13, Dirk Hohndel wrote:

On Sat, Feb 13, 2016 at 08:55:27PM +0200, Willem Ferguson wrote:

  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?

I don't think there's a way to tell from their descriptor. We may have to
white-list the ones that we know works. Manually.


:-

It makes very much sense, but the problem is that QComboBox takes a 
variable of data type 'real' to indicate progress. No indication on 

You lost me. Do you mean the QML type ProgressBar?

Not sure where a QComboBox needs a real.


From Qt manual:

QProgressBar


   Properties

 * **hovered
   **
   : bool
 * **indeterminate
   
**
   : bool
 * **maximumValue
   
**
   : real
 * **minimumValue
   
**
   : real
 * **orientation
   
**
   : int
 * **style
   **
   : Component
 * **value
   **
   : real


value : real

This property holds the progress bar's current value. Attempting to 
change the current value to one outside the minimum-maximum range has no 
effect on the current value.


The default value is |0|.


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.

Can you post a piece of code?


No need, I solved the problem by passing a QVariant instead of a float. 
Works now  :-)


The only thing I have to do now is to do the filtering of suitable 
devices. Then the REAL obstacle: getting the download itself to work. I 
will start with some preparations today. Will send patch a little later 
today.


Kind regards,
willem



___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Subsurface-mobile for Android -845

[Dirk Hohndel]

On Sun, Feb 14, 2016 at 03:12:11PM +1100, Rick Walsh wrote:
> I just tested 849.  I think the use of the action button is very good.  It
> doesn't waste space, it's transparent enough not to be invasive, it's easy
> to reach, and most importantly, the icons give good clues what the button
> does (unlike the original action button, which was powerful, efficient use
> of space, but confusing to many the first time they saw it).  I also like
> that I can still/again swipe the central action button instead of using the
> arrows - as I said before, when holding my phone in my not-dainty left
> hand, reaching the very left bottom of the screen with my thumb can be
> awkward.

Thanks for the feedback. Very helpful.

> > > > Just a couple of things: The title bar is too cramped now.  Other apps
> > use
> > > > that to display info on the current context.  We could display "Dive
> > list"
> > > > or "Dive #643" or "Edit dive #242" or "About" there in the future.
> > >
> > > That's a good idea... but I think I like the idea of it simply fading
> > away
> > > even better.
> >
> > +1 for fading away.
> >
> 
> I agree with both points.  Screen real estate is scarce, so if/when the
> title bar is shown, I think it should be more informative than
> Subsurface-mobile (I know what app I'm using).
> 
> Going through the various apps on my phone, many have "title" bars showing
> what page is active on the app (e.g. "Inbox" in gmail), or toolbars, some
> including the app logo (e.g. Twitter), but very few have a title bar with
> the app name displayed.  A few have a search bar that mentions the app name
> (e.g. "Search Google Maps").

I think I'm sold on dropping the name from the title bar. But I'm not 100%
sure what I want instead. No title bar at all? A title bar that fades?
What is it showing until it disappears? Contextual info (which dive is
shown or something like that)?

> In my opinion, the ideal title bar would have the Subsurface-mobile logo at
> left (like now, but moved down a tiny bit - right now its vertical
> alignment is hard against the top of the screen), with the page name next
> to it (e.g. Dive #643 as suggested by Henrik).  And ideally it would fade
> away when you scroll down the page, and probably reappear when you scroll
> back up to the top.

Yeah, so that's kinda what I was contemplating.

> > Google's apps for Android (those which do not auto-save) do use such a
> > dialog.
> > They all use a Discard/Cancel approach (though with completely different
> > wording and even inconsistent button position between the apps, which is
> > really bad design).
> > We haven't written about it in the HIG yet (we'll still add one guideline
> > for
> > that), but here's what I'd suggest:
> > "Discard your changes?" [Discard] [Keep Editing]". This makes saving take
> > one
> > more step, but we want to train users to just hit "Save" anyway, and it
> > makes
> > the decision in the dialog easier.
> > There is already a component for a slide-in dialog available (don't know
> > its
> > name, though, tbh. If you can't find it, ask Marco).
> 
> I find confirmation dialogs clumsy and don't like them if they can be
> avoided, especially on a mobile app.  If we were talking about
> writing/editing a thesis, I'd be more inclined towards a confirmation
> dialog, but if the the user accidentally close the dive edit page without
> saving, and lost their logging notes, they should be able to cope.
> 
> I'd rather have the action button action be 'save changes and close', and
> the Android back button would be 'discard changes and close'.  If that's
> too out the for new users, there could also be a discard button next to the
> current save (and close) ordinary button at the bottom of the page.

So I tried to implement something that I find reasonable and intuitive.

- there's still the save button
- the action button is cancel and there is NO CONFIRMATION - you hit that
  button, you get what you asked for
- the back button asks the user if they really wanted to discard the
  changes, and if they don't confirm within 3 seconds it simply hides the
  confirmation dialog and pretends nothing happens

Please play with it, the description sounds a lot more awkward that it
felt to me to use...

> Similarly, I think we should use the action button on the cloud
> credentials.  The action button action would be "save", and the back button
> would be "discard" (and return to dive list).  This could replace the
> existing ordinary buttons.

That I think is a good idea. I'll need to find the time to implement this.

> Another thing - In the dive list, there's a blank row above the trip
> separator line.  I'm not sure if that's deliberate, but it looks like a
> waste of space to me.

Do you have a screen shot?

Thanks for all the feedback!

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Subsurface-mobile for Android -845

[Rick Walsh]

On 14 February 2016 at 09:54, Thomas Pfeiffer 
wrote:

> On Samstag, 13. Februar 2016 09:57:21 CET Dirk Hohndel wrote:
> > > Hi!  I think it looks pretty decent now.  I like that there is less
> > > clutter.
> > Yay!
>
> Yay++
>
> I just tested 849.  I think the use of the action button is very good.  It
doesn't waste space, it's transparent enough not to be invasive, it's easy
to reach, and most importantly, the icons give good clues what the button
does (unlike the original action button, which was powerful, efficient use
of space, but confusing to many the first time they saw it).  I also like
that I can still/again swipe the central action button instead of using the
arrows - as I said before, when holding my phone in my not-dainty left
hand, reaching the very left bottom of the screen with my thumb can be
awkward.


> > > Just a couple of things: The title bar is too cramped now.  Other apps
> use
> > > that to display info on the current context.  We could display "Dive
> list"
> > > or "Dive #643" or "Edit dive #242" or "About" there in the future.
> >
> > That's a good idea... but I think I like the idea of it simply fading
> away
> > even better.
>
> +1 for fading away.
>

I agree with both points.  Screen real estate is scarce, so if/when the
title bar is shown, I think it should be more informative than
Subsurface-mobile (I know what app I'm using).

Going through the various apps on my phone, many have "title" bars showing
what page is active on the app (e.g. "Inbox" in gmail), or toolbars, some
including the app logo (e.g. Twitter), but very few have a title bar with
the app name displayed.  A few have a search bar that mentions the app name
(e.g. "Search Google Maps").

In my opinion, the ideal title bar would have the Subsurface-mobile logo at
left (like now, but moved down a tiny bit - right now its vertical
alignment is hard against the top of the screen), with the page name next
to it (e.g. Dive #643 as suggested by Henrik).  And ideally it would fade
away when you scroll down the page, and probably reappear when you scroll
back up to the top.


> > > And since we're going for the action button design, how about making it
> > > more like the action buttons in other apps, i.e. larger and more to the
> > > right?
> >
> > Thomas answered the "more to the right" question. But there's another
> > reason. Right now, when you use your device in landscape mode you get the
> > action button right on the center divider which is perfect, IMHO.
> >
> > > And one more (less related) thing:  If I edit a dive and press the back
> > > button (instead of save), I should get a request: "Discard edits? [Yes
> /
> > > Save edits / Cancel]
> >
> > I hate those dialogs on some level, but I guess you are right.
>
> > Thomas, what's the HID approved way of doing something like that?
>
> We originally had the idea that for "swipe to go back/forward" or "column-
> based navigation", one could simply swipe forward again to get back to the
> already entered/changed data if one has accidentally swiped back without
> saving (before navigating somewhere else). That's not as easily possible
> when
> using the back button, of course.
>
> Google's apps for Android (those which do not auto-save) do use such a
> dialog.
> They all use a Discard/Cancel approach (though with completely different
> wording and even inconsistent button position between the apps, which is
> really bad design).
> We haven't written about it in the HIG yet (we'll still add one guideline
> for
> that), but here's what I'd suggest:
> "Discard your changes?" [Discard] [Keep Editing]". This makes saving take
> one
> more step, but we want to train users to just hit "Save" anyway, and it
> makes
> the decision in the dialog easier.
> There is already a component for a slide-in dialog available (don't know
> its
> name, though, tbh. If you can't find it, ask Marco).
>
> I find confirmation dialogs clumsy and don't like them if they can be
avoided, especially on a mobile app.  If we were talking about
writing/editing a thesis, I'd be more inclined towards a confirmation
dialog, but if the the user accidentally close the dive edit page without
saving, and lost their logging notes, they should be able to cope.

I'd rather have the action button action be 'save changes and close', and
the Android back button would be 'discard changes and close'.  If that's
too out the for new users, there could also be a discard button next to the
current save (and close) ordinary button at the bottom of the page.

Similarly, I think we should use the action button on the cloud
credentials.  The action button action would be "save", and the back button
would be "discard" (and return to dive list).  This could replace the
existing ordinary buttons.


Another thing - In the dive list, there's a blank row above the trip
separator line.  I'm not sure if that's deliberate, but it looks like a
waste of space to me.

Cheers,

Rick

Re: Fwd: Re: Subsurface-mobile downloadfrom divecomputer

[Dirk Hohndel]

On Sat, Feb 13, 2016 at 08:55:27PM +0200, Willem Ferguson wrote:
> >>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?

I don't think there's a way to tell from their descriptor. We may have to
white-list the ones that we know works. Manually.

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

You lost me. Do you mean the QML type ProgressBar?

Not sure where a QComboBox needs a real.

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

Can you post a piece of code?

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

Yes. With my apologies for the thrash, but I think this is worth it. It
feels MUCH better now. But I'd give it a few more days.

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Subsurface-mobile 854 - now even more Plasma-mobile than ever before

[Rick Walsh]

On 14 Feb 2016 17:23, "Dirk Hohndel"  wrote:
>
>
> So based on the feedback received and the discussion here on the list, I
> decided to go all the way...
>
> - all the save buttons on the pages are gone
> - the action button is used for the main action on any page, including all
>   the save actions (this is for preferences, credentials, edits, etc)
> - the back button is used for the go-back, discard, abort style actions
>   everywhere (without confirmation dialog)
>
I played with this for a few minutes and really like it. Which is just as
well since you went and redid the button actions to address my comments.

> In order for this to work a couple of patches to the mobile components are
> needed. They were all sent to the plasma-devel mailing list -- actually,
> only one is really /needed/ at this point. One is actually no longer
> relevant (because we don't use context menus) and one is more a visual
> thing and won't prevent functionality. So building from source will have
> almost everything work as expected - except when you decide to change
> credentials and then change your mind and hit the back key. Oops, you just
> quit Subsurface. That's fixed in my APK and in last of the patches I sent
> to the plasma-devel list :-)
>
> Please test. I know, I keep saying that and I have to say I am thrilled
> with all the feedback you are giving. I think this is really shaping up to
> be a very strong first release.
>
> I'll give it a day or two for testing and then hopefully I can make a
> second beta with the updated UI.
>
> /D
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface