Re: Possibility to add custom field?

[Joakim Bygdell]

On 26 July 2017 at 06:48, Dirk Hohndel  wrote:

>
> > On Jul 25, 2017, at 7:44 PM, Linus Torvalds <
> torva...@linux-foundation.org> wrote:
> >
> > This message was in the Subsurface "Google Groups" thing, and I'm
> > moving the discussion to the development mailing list instead since I
> > think more people read that one.
> >
> > [ I don't know how many people follow that google group, thing - I
> > just do it over email anyway ]]
> >
> > Anyway, I suggested to Marc that the natural way to do this would be
> > to make it possible to edit the "extradata" { key, value } pairs that
> > we show in the "Extra Info" tab, and Marc said that would work well
> > for him.
> >
> > But obviously I don't do UI code. But it feels like it *should* be
> > fairly easy to make that "Extra data" thing be something you can add
> > entries to and edit.
>
> That wouldn't be too terribly hard in principle. But usually once you take
> that first step, people want more. Autocompletion of entries. Ability to
> search and/or filter. Ability to display the information in the mobile app,
> etc.
>
> I'm not against doing this, but I want us to do this eyes wide open.
>
> I really hope that Tomaz will NOT say "I'll do it", mainly because he is
> working on statistics and we have too many things already that got
> started and never got finished :-/
>
>
If we get this information from libDC or our text parsers, fine.
If it is something the user will add  manually they might as well add it in
the notes field.



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

Re: [PATCH 0/2] Properly save and restore multiple pressure sensors

[Dirk Hohndel]

On Tue, Jul 25, 2017 at 07:24:36PM -0700, Linus Torvalds wrote:
> 
> By "multiple" I obviously currently mean just two sensors for each sample, 
> since that's our current limitation. But I have test-data that then 
> alternates multiple sensors over those two slots, and the code is also 
> written so that if people really end up wanting more than two concurrent 
> pressure sensors, at least the saving and restoring should happily handle 
> it.

So this doesn't break any of the existing tests, but I think it would be
worth while to have some tests that exercise this code. I know that you
aren't a C++ fan, but it would be nice to add a few tests for that, and
you might indeed be the best person to do so as you know exactly what the
corner cases here might be.

> Note that while saving and restoring can handle multiple sensors per 
> sample, other parts of the code are still limited to just two (and some 
> code only iterates over one single sensor). But with this code, I can at 
> least save and load test-files with sensor data from multiple sensors, 
> which will help me a lot. And from my (admittedly fairly limited) testing, 
> we still save old-style data with no changes.
> 
> The first patch should introduce no changes at all, just moving one helper 
> file and introducing another one. That prepares for a simpler and more 
> legible second patch, which then actually looks at the dive sample data to 
> see if it should be saved in the old legacy format or the new "pressure 
> and cylinder index together" format.
> 
> For the git save format, we simply add a ":sensor" to the pressure reading 
> to indicate which cylinder the pressure reading is from.
> 
> For the XML save format, we use "pressureN='xyz bar'" for cylinder N, 
> since XML doesn't like having multiple nodes with the same name (so you 
> can't just repeat "pressure=xyz" in XML and use the same trick we used for 
> the git save format).

That's not TOO ugly...

Thanks for working on this!

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

Re: Possibility to add custom field?

[Dirk Hohndel]

> On Jul 25, 2017, at 7:44 PM, Linus Torvalds  
> wrote:
> 
> This message was in the Subsurface "Google Groups" thing, and I'm
> moving the discussion to the development mailing list instead since I
> think more people read that one.
> 
> [ I don't know how many people follow that google group, thing - I
> just do it over email anyway ]]
> 
> Anyway, I suggested to Marc that the natural way to do this would be
> to make it possible to edit the "extradata" { key, value } pairs that
> we show in the "Extra Info" tab, and Marc said that would work well
> for him.
> 
> But obviously I don't do UI code. But it feels like it *should* be
> fairly easy to make that "Extra data" thing be something you can add
> entries to and edit.

That wouldn't be too terribly hard in principle. But usually once you take
that first step, people want more. Autocompletion of entries. Ability to
search and/or filter. Ability to display the information in the mobile app,
etc.

I'm not against doing this, but I want us to do this eyes wide open.

I really hope that Tomaz will NOT say "I'll do it", mainly because he is
working on statistics and we have too many things already that got
started and never got finished :-/

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

Re: Possibility to add custom field?

[Linus Torvalds]

This message was in the Subsurface "Google Groups" thing, and I'm
moving the discussion to the development mailing list instead since I
think more people read that one.

[ I don't know how many people follow that google group, thing - I
just do it over email anyway ]]

Anyway, I suggested to Marc that the natural way to do this would be
to make it possible to edit the "extradata" { key, value } pairs that
we show in the "Extra Info" tab, and Marc said that would work well
for him.

But obviously I don't do UI code. But it feels like it *should* be
fairly easy to make that "Extra data" thing be something you can add
entries to and edit.

Anybody? Help? Tomaz?

  Linus

On Tue, Jul 25, 2017 at 6:21 PM, Marc Collin  wrote:
> I use version 4.6.4 under linux.
> I would like to know if there is a way to add custom field?
>
> I use sometime a rebreather and i would like to store information about
> cellule (mv for diluant, o2...)
>
> thanks
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

[PATCH 2/2] Add support for loading and saving multiple pressure samples

[Linus Torvalds]

From: Linus Torvalds 
Date: Tue, 25 Jul 2017 19:10:03 -0700
Subject: [PATCH 2/2] Add support for loading and saving multiple pressure 
samples

This does both the XML and the git save format, because the changes
really are the same, even if the actual format differs in some details. 
See how the two "save_samples()" routines both do the same basic setup, 
for example.

This is fairly straightforward, with the possible exception of the odd

 sensor = sample->sensor[0];

default in the git pressure loading code.

That line just means that if we do *not* have an explicit cylinder index 
for the pressure reading, we will always end up filling in the new 
pressure as the first pressure (because the cylinder index will match the 
first sensor slot).

So that makes the "add_sample_pressure()" case always do the same thing it 
used to do for the legacy case: fill in the first slot. The actual sensor 
index may later change, since the legacy format has a "sensor=X" key value 
pair that sets the sensor, but it will also use the first sensor slot, 
making it all do exactly what it used to do.

And on the other hand, if we're loading new-style data with cylinder 
pressure and sensor index together, we just end up using the new semantics 
for add_sample_pressure(), which tries to keep the same slot for the same 
sensor, but does the right thing if we already have other pressure values.

The XML code has no such issues at all, since it can't share the cases 
anyway, and we need to have different node names for the different sensor 
values and cannot just have multiple "pressure" entries. Have I mentioned 
how much I despise XML lately?

Signed-off-by: Linus Torvalds 
---

 core/load-git.c  |  7 ++-
 core/parse-xml.c | 22 +
 core/save-git.c  | 60 +++-
 core/save-xml.c  | 45 ++
 4 files changed, 103 insertions(+), 31 deletions(-)

diff --git a/core/load-git.c b/core/load-git.c
index 6a3cc75c..e7732a69 100644
--- a/core/load-git.c
+++ b/core/load-git.c
@@ -560,6 +560,7 @@ static void parse_sample_keyvalue(void *_sample, const char 
*key, const char *va
 
 static char *parse_sample_unit(struct sample *sample, double val, char *unit)
 {
+   unsigned int sensor;
char *end = unit, c;
 
/* Skip over the unit */
@@ -572,12 +573,16 @@ static char *parse_sample_unit(struct sample *sample, 
double val, char *unit)
}
 
/* The units are "°C", "m" or "bar", so let's just look at the first 
character */
+   /* The cylinder pressure may also be of the form '123.0bar:4' to 
indicate sensor */
switch (*unit) {
case 'm':
sample->depth.mm = lrint(1000*val);
break;
case 'b':
-   sample->pressure[0].mbar = lrint(1000*val);
+   sensor = sample->sensor[0];
+   if (end > unit+4 && unit[3] == ':')
+   sensor = atoi(unit+4);
+   add_sample_pressure(sample, sensor, lrint(1000*val));
break;
default:
sample->temperature.mkelvin = C_to_mkelvin(val);
diff --git a/core/parse-xml.c b/core/parse-xml.c
index e261d127..ef6f0bdf 100644
--- a/core/parse-xml.c
+++ b/core/parse-xml.c
@@ -928,6 +928,7 @@ static void try_to_fill_dc(struct divecomputer *dc, const 
char *name, char *buf)
 static void try_to_fill_sample(struct sample *sample, const char *name, char 
*buf)
 {
int in_deco;
+   pressure_t p;
 
start_match("sample", name, buf);
if (MATCH("pressure.sample", pressure, >pressure[0]))
@@ -938,6 +939,27 @@ static void try_to_fill_sample(struct sample *sample, 
const char *name, char *bu
return;
if (MATCH("o2pressure.sample", pressure, >pressure[1]))
return;
+   /* Christ, this is ugly */
+   if (MATCH("pressure0.sample", pressure, )) {
+   add_sample_pressure(sample, 0, p.mbar);
+   return;
+   }
+   if (MATCH("pressure1.sample", pressure, )) {
+   add_sample_pressure(sample, 1, p.mbar);
+   return;
+   }
+   if (MATCH("pressure2.sample", pressure, )) {
+   add_sample_pressure(sample, 2, p.mbar);
+   return;
+   }
+   if (MATCH("pressure3.sample", pressure, )) {
+   add_sample_pressure(sample, 3, p.mbar);
+   return;
+   }
+   if (MATCH("pressure4.sample", pressure, )) {
+   add_sample_pressure(sample, 4, p.mbar);
+   return;
+   }
if (MATCH("cylinderindex.sample", get_cylinderindex, 
>sensor[0]))
return;
if (MATCH("sensor.sample", get_sensor, >sensor[0]))
diff --git a/core/save-git.c b/core/save-git.c
index b734f59f..1fe2642f 100644
--- a/core/save-git.c
+++ b/core/save-git.c
@@ -241,21 +241,45 @@ static void 

[PATCH 1/2] Make sample pressure helper functions available to everybody

[Linus Torvalds]

From: Linus Torvalds 
Date: Tue, 25 Jul 2017 18:33:10 -0700
Subject: [PATCH 1/2] Make sample pressure helper functions available to 
everybody

We had a "add_sample_pressure()" helper functions that was local to just
the libdivecomputer downloading code, but it really is applicable to
pretty much any code that adds cylinder pressure data to a sample.

Also add another helper: "legacy_format_o2pressures()" which checks the
sample data to see if we can use the legacy format, and returns the o2
pressure sensor to use for that legacy format.

Because both the XML and the git save format will need a way to save the
compatible old-style information, when possible, but save an extended
format for when we have data from multiple concurrent sensors.

Signed-off-by: Linus Torvalds 
---

I should have made the "add_sample_pressure()" thing public from the 
beginning.

And the "legacy_format_o2pressures()" may look odd here with no actual 
users yet, but it's fairly simple code and it will make the next patch 
more legible because it can just use these simple helpers that both the 
XML and git format will want to use.

 core/dive.c| 83 ++
 core/dive.h|  2 ++
 core/libdivecomputer.c | 41 -
 3 files changed, 85 insertions(+), 41 deletions(-)

diff --git a/core/dive.c b/core/dive.c
index 8270c547..42ef687e 100644
--- a/core/dive.c
+++ b/core/dive.c
@@ -35,6 +35,89 @@ const char *cylinderuse_text[] = {
 };
 const char *divemode_text[] = { "OC", "CCR", "PSCR", "Freedive" };
 
+/*
+ * Adding a cylinder pressure sample field is not quite as trivial as it
+ * perhaps should be.
+ *
+ * We try to keep the same sensor index for the same sensor, so that even
+ * if the dive computer doesn't give pressure information for every sample,
+ * we don't move pressure information around between the different sensor
+ * indexes.
+ *
+ * The "prepare_sample()" function will always copy the sensor indices
+ * from the previous sample, so the indexes are pre-populated (but the
+ * pressures obviously are not)
+ */
+void add_sample_pressure(struct sample *sample, int sensor, int mbar)
+{
+   int idx;
+
+   if (!mbar)
+   return;
+
+   /* Do we already have a slot for this sensor */
+   for (idx = 0; idx < MAX_SENSORS; idx++) {
+   if (sensor != sample->sensor[idx])
+   continue;
+   sample->pressure[idx].mbar = mbar;
+   return;
+   }
+
+   /* Pick the first unused index if we couldn't reuse one */
+   for (idx = 0; idx < MAX_SENSORS; idx++) {
+   if (sample->pressure[idx].mbar)
+   continue;
+   sample->sensor[idx] = sensor;
+   sample->pressure[idx].mbar = mbar;
+   return;
+   }
+
+   /* We do not have enough slots for the pressure samples. */
+   /* Should we warn the user about dropping pressure data? */
+}
+
+/*
+ * The legacy format for sample pressures has a single pressure
+ * for each sample that can have any sensor, plus a possible
+ * "o2pressure" that is fixed to the Oxygen sensor for a CCR dive.
+ *
+ * For more complex pressure data, we have to use explicit
+ * cylinder indexes for each sample.
+ *
+ * This function returns a negative number for "no legacy mode",
+ * or a non-negative number that indicates the o2 sensor index.
+ */
+int legacy_format_o2pressures(struct dive *dive, struct divecomputer *dc)
+{
+   int i, o2sensor;
+
+   o2sensor = (dc->divemode == CCR) ? get_cylinder_idx_by_use(dive, 
OXYGEN) : -1;
+   for (i = 0; i < dc->samples; i++) {
+   struct sample *s = dc->sample + i;
+   int seen_pressure = 0, idx;
+
+   for (idx = 0; idx < MAX_SENSORS; idx++) {
+   int sensor = s->sensor[idx];
+   pressure_t p = s->pressure[idx];
+
+   if (!p.mbar)
+   continue;
+   if (sensor == o2sensor)
+   continue;
+   if (seen_pressure)
+   return -1;
+   seen_pressure = 1;
+   }
+   }
+
+   /*
+* Use legacy mode: if we have no O2 sensor we return a
+* positive sensor index that is guaranmteed to not match
+* any sensor (we encode it as 8 bits).
+*/
+   return o2sensor < 0 ? 256 : o2sensor;
+}
+
 int event_is_gaschange(struct event *ev)
 {
return ev->type == SAMPLE_EVENT_GASCHANGE ||
diff --git a/core/dive.h b/core/dive.h
index df0c4107..eb976f56 100644
--- a/core/dive.h
+++ b/core/dive.h
@@ -760,6 +760,8 @@ extern void clear_table(struct dive_table *table);
 
 extern struct sample *prepare_sample(struct divecomputer *dc);
 extern void finish_sample(struct divecomputer *dc);
+extern void 

[PATCH 0/2] Properly save and restore multiple pressure sensors

[Linus Torvalds]

By "multiple" I obviously currently mean just two sensors for each sample, 
since that's our current limitation. But I have test-data that then 
alternates multiple sensors over those two slots, and the code is also 
written so that if people really end up wanting more than two concurrent 
pressure sensors, at least the saving and restoring should happily handle 
it.

Note that while saving and restoring can handle multiple sensors per 
sample, other parts of the code are still limited to just two (and some 
code only iterates over one single sensor). But with this code, I can at 
least save and load test-files with sensor data from multiple sensors, 
which will help me a lot. And from my (admittedly fairly limited) testing, 
we still save old-style data with no changes.

The first patch should introduce no changes at all, just moving one helper 
file and introducing another one. That prepares for a simpler and more 
legible second patch, which then actually looks at the dive sample data to 
see if it should be saved in the old legacy format or the new "pressure 
and cylinder index together" format.

For the git save format, we simply add a ":sensor" to the pressure reading 
to indicate which cylinder the pressure reading is from.

For the XML save format, we use "pressureN='xyz bar'" for cylinder N, 
since XML doesn't like having multiple nodes with the same name (so you 
can't just repeat "pressure=xyz" in XML and use the same trick we used for 
the git save format).

Linus Torvalds (2):
  Make sample pressure helper functions available to everybody
  Add support for loading and saving multiple pressure samples

 core/dive.c| 83 ++
 core/dive.h|  2 ++
 core/libdivecomputer.c | 41 -
 core/load-git.c|  7 -
 core/parse-xml.c   | 22 +
 core/save-git.c| 60 +---
 core/save-xml.c| 45 +++
 7 files changed, 188 insertions(+), 72 deletions(-)

-- 
2.13.1.518.g0d864c4df

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

Re: latest APK

[Davide DB]

Sorry Joakim

davide@mobile

On Jul 25, 2017 9:38 PM, "Joakim Bygdell"  wrote:

> On 25 July 2017 at 21:07, Davide DB  wrote:
>
>> On selected dive/row I mean
>>
>> davide@mobile
>>
>> On Jul 25, 2017 9:06 PM, "Davide DB"  wrote:
>>
>>> Hi Joakim,
>>>
>>> Why the second row cannot be plain white in all themes?
>>>
>>> davide@mobile
>>>
>>
>>
> There is no reason it can't.
>
>
> --
> Jocke
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

ping

[Robert Helling]

Hi,

I just wanted to let you know I am still alive but totally buried under work 
(actual for money and also in anticipation of moving house in two weeks). But 
that should be better hopefully soon when I will be on summer vacation and plan 
to have time for my most favourite dive log again!

Tonight, I had a few minutes to spare so I built and installed the latest 
master on my iPad (it did not require any fiddling besides setting the 
QuickControls version to 2.1). And, what can I say, there is so much 
improvement! You guys rock (I wasn’t even properly following what is going on 
on the mailing list only saw lots and lots of messages). Keep going. Hope to 
join you again soon.

Best
Robert


signature.asc
Description: Message signed with OpenPGP
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] Try to sanely download multiple concurrent cylinder pressures

[Linus Torvalds]

On Tue, Jul 25, 2017 at 12:13 PM, Linus Torvalds
 wrote:
>
> I'll fix that, since I can easily generate bogus data with many sensors.

Actually, the first thing I need to fix is the save format.

Right now our pressure data looks like this in our XML files:

pressure='180.84 bar' sensor='1'

and that is actually horrible for various reasons. Once you have
multiple sensors, that "sensor='N'" format ends up being really
unhappy, not least because of XML rules (but also because we need to
associate the sensor with one of the pressure values, and so it's
fundamentally a bit ambiguous, especially as we currently skip the
sensor data if it matches the previous one).

To continue on the horrid format, if we have a second pressure, right
now we can only do that for one *fixed* sensor per dive, which is
fixed to the Oxygen bottle, and then we add a field like

o2pressure='171.76 bar'

to the sample XML.

The git format is very similar, although with slightly less
unnecessary syntax crap (ie it would be just

180.84bar sensor=1

and

   o2pressure=171.76bar

respectively).

Now, for legacy reasons (so that you can continue to use old clients
on the cloud data, for example), I propose to just continue to use the
old format for the cases where it works.

But for dives that actually have multiple sensors and aren't of that
"CCR with O2 sensor" form we need to have a new format, simply because
the existing format can't handle it.

My current personal preference is to not use the "o2pressure=" or
"sensor=" tags at all, but instead just indicate the sensor as a ":N"
after the unit (bar).

So we'd just have something like

pressure='180.84 bar:1'

and

pressure='171.76 bar:2'

to indicate the pressures of sensor 1 and 2 respectively (and it
wouldn't matter if it's a CCR dive and one of the sensors is connected
to an Oxygen bottle or not - it still uses the same format).

Comments? Do people hate this? Any other suggestions?

Note: regardless, we *will* have to support that mixed old-and-new
format for a while, so it's going to be a bit hacky and ugly for some
time regardless of what syntax we'd choose.

*Eventually* we can maybe decide to only save in the new format,
because in a year or so maybe we can just say "everybody has the new
clients, we can just use the simpler new save format unconditionally".
But I'll have to write the code to fall back to the odd special-cases
for now when possible.

I guess not a lot of people actually look at the raw git tree or the
XML, so I doubt people have strong opinions on the format. But if you
do have a strong opinion, speak now or forever hold your peace..

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

Re: [PATCH] Try to sanely download multiple concurrent cylinder pressures

[Linus Torvalds]

On Mon, Jul 24, 2017 at 12:09 PM, Linus Torvalds
 wrote:
>
> I think we'll need to create some test data with Dirk, but we only have
> two Suunto transmitters between us to begin with, and mine is already off
> for the recall.
>
> We do have three transmitters total for the Shearwater [..]

Bah.

It was easy to test the downloading: I just hacked up the
libdivecomputer Suunto EON Steel back-end to start generating random
pressure data for multiple cylinders.

And it turns out that we seem to handle the case of two sensors fine
these days. So I think the sidemount case should work.

If we actually have three sensors, subsurface indeed gets very
confused. The code that shows pressure sensors simply expects that
each pressure slot is consistent over the whole dive, and it does
*not* actually look at the index in the pressure slot except to say
what gas it is.

I'll fix that, since I can easily generate bogus data with many sensors.

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

Re: latest APK

[Davide DB]

On selected dive/row I mean

davide@mobile

On Jul 25, 2017 9:06 PM, "Davide DB"  wrote:

> Hi Joakim,
>
> Why the second row cannot be plain white in all themes?
>
> davide@mobile
>
> On Jul 25, 2017 8:41 PM, "Joakim Bygdell"  wrote:
>
>> On 25 July 2017 at 20:01, Joakim Bygdell  wrote:
>>
>> On 25 July 2017 at 19:58, Linus Torvalds 
>>> wrote:
>>>
 Sadly, the new color scheme no longer works for the pink theme.

 The dark pink is much too dark, being red rather than pink, and the
 text is no longer legible because it's black on a dark background.

 The color used for the trip header is the right pink color, but the one
 used for "selected dive" and the download button is bad.

>>>
>>> I know, working on it right now.
>>> We also need to get the differences between the dark primary and light
>>> colors match between blue and pink.
>>>
>>>

 (This may not be a new thing, I haven't tested the mobile app in a
 while)

 Linus

>>>
>>>
>> Using the light pink that are on the trip header as our primary pink will
>> not work, the distance in tint to the lighter version would
>> end up as white.
>>
>> Two screenshots attached with alternate pink colors while maintaining the
>> same light pink base color.
>>
>> --
>> Jocke
>>
>> ___
>> 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

Re: latest APK

[Davide DB]

Hi Joakim,

Why the second row cannot be plain white in all themes?

davide@mobile

On Jul 25, 2017 8:41 PM, "Joakim Bygdell"  wrote:

> On 25 July 2017 at 20:01, Joakim Bygdell  wrote:
>
> On 25 July 2017 at 19:58, Linus Torvalds 
>> wrote:
>>
>>> Sadly, the new color scheme no longer works for the pink theme.
>>>
>>> The dark pink is much too dark, being red rather than pink, and the text
>>> is no longer legible because it's black on a dark background.
>>>
>>> The color used for the trip header is the right pink color, but the one
>>> used for "selected dive" and the download button is bad.
>>>
>>
>> I know, working on it right now.
>> We also need to get the differences between the dark primary and light
>> colors match between blue and pink.
>>
>>
>>>
>>> (This may not be a new thing, I haven't tested the mobile app in a while)
>>>
>>> Linus
>>>
>>
>>
> Using the light pink that are on the trip header as our primary pink will
> not work, the distance in tint to the lighter version would
> end up as white.
>
> Two screenshots attached with alternate pink colors while maintaining the
> same light pink base color.
>
> --
> Jocke
>
> ___
> 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

Re: latest APK

[Joakim Bygdell]

On 25 July 2017 at 21:00, David Tillotson  wrote:

> On 25 July 2017 17:44:30 BST, Dirk Hohndel  wrote:
>>
>> Thanks to Jocke the UI keeps getting better and better.
>> I really like the colored icon as indication for the running location
>> service. Nicely done.
>>
>> The only thing I really feel is preventing me from doing another beta is
>> the issue with the cloud credentials - that's not in a good state right
>> now. The rest looks great!
>>
>> If you want to see for yourself...
>>
>> http://subsurface-divelog.org/downloads/test/Subsurface-mobile-4.6.4.508-arm.apk
>>
>> /D
>> --
>>
>> subsurface mailing list
>> subsurface@subsurface-divelog.org
>> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>>
>>
> I'm not sure if it's intentional, but the drop-downs are not the best
> colour combination when the dark scheme is applied. Screenshot attached.
> The progress on the mobile has been absolutely superb (although I haven't
> been able to check GPS or downloading as yet).
> --
> David Tillotson
>
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
> The dark theme needs much more work before it can be considered anything
but a preview.


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

Re: latest APK

[Linus Torvalds]

Sadly, the new color scheme no longer works for the pink theme.

The dark pink is much too dark, being red rather than pink, and the text is
no longer legible because it's black on a dark background.

The color used for the trip header is the right pink color, but the one
used for "selected dive" and the download button is bad.

(This may not be a new thing, I haven't tested the mobile app in a while)

Linus

On Jul 25, 2017 9:44 AM, "Dirk Hohndel"  wrote:

Thanks to Jocke the UI keeps getting better and better.
I really like the colored icon as indication for the running location
service. Nicely done.

The only thing I really feel is preventing me from doing another beta is
the issue with the cloud credentials - that's not in a good state right
now. The rest looks great!

If you want to see for yourself...

http://subsurface-divelog.org/downloads/test/Subsurface-
mobile-4.6.4.508-arm.apk

/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

latest APK

[Dirk Hohndel]

Thanks to Jocke the UI keeps getting better and better.
I really like the colored icon as indication for the running location
service. Nicely done.

The only thing I really feel is preventing me from doing another beta is
the issue with the cloud credentials - that's not in a good state right
now. The rest looks great!

If you want to see for yourself...

http://subsurface-divelog.org/downloads/test/Subsurface-mobile-4.6.4.508-arm.apk

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