[PATCH] update de_CH translation

[Martin Gysel]

Signed-off-by: Martin Gysel m...@bearsh.org
---
 translations/subsurface_de_CH.ts | 296 +--
 1 file changed, 163 insertions(+), 133 deletions(-)

diff --git a/translations/subsurface_de_CH.ts b/translations/subsurface_de_CH.ts
index 42b8485..36cf4ff 100644
--- a/translations/subsurface_de_CH.ts
+++ b/translations/subsurface_de_CH.ts
@@ -61,7 +61,7 @@
 message
 location filename=../qt-ui/divelogimportdialog.cpp line=25/
 sourceCyl. size/source
-translation type=unfinished/
+translationFlaschengrösse/translation
 /message
 message
 location filename=../qt-ui/divelogimportdialog.cpp line=25/
@@ -116,57 +116,57 @@
 message
 location filename=../qt-ui/divelogimportdialog.cpp line=27/
 sourceO₂/source
-translation type=unfinished/
+translationO₂/translation
 /message
 message
 location filename=../qt-ui/divelogimportdialog.cpp line=27/
 sourceHe/source
-translation type=unfinished/
+translationHe/translation
 /message
 message
 location filename=../qt-ui/divelogimportdialog.cpp line=27/
 sourceSample time/source
-translation type=unfinished/
+translationSegment Zeit/translation
 /message
 message
 location filename=../qt-ui/divelogimportdialog.cpp line=27/
 sourceSample depth/source
-translation type=unfinished/
+translationSegment Tiefe/translation
 /message
 message
 location filename=../qt-ui/divelogimportdialog.cpp line=27/
 sourceSample temperature/source
-translation type=unfinished/
+translationSegment Temperatur/translation
 /message
 message
 location filename=../qt-ui/divelogimportdialog.cpp line=27/
 sourceSample pO₂/source
-translation type=unfinished/
+translationSegment pO₂/translation
 /message
 message
 location filename=../qt-ui/divelogimportdialog.cpp line=27/
 sourceSample CNS/source
-translation type=unfinished/
+translationSegment CNS/translation
 /message
 message
 location filename=../qt-ui/divelogimportdialog.cpp line=27/
 sourceSample NDL/source
-translation type=unfinished/
+translationSegment Nullzeit/translation
 /message
 message
 location filename=../qt-ui/divelogimportdialog.cpp line=28/
 sourceSample TTS/source
-translation type=unfinished/
+translationSegment Aufstiegszeit/translation
 /message
 message
 location filename=../qt-ui/divelogimportdialog.cpp line=28/
 sourceSample stopdepth/source
-translation type=unfinished/
+translationSegment Stopptiefe/translation
 /message
 message
 location filename=../qt-ui/divelogimportdialog.cpp line=28/
 sourceSample pressure/source
-translation type=unfinished/
+translationSegment Flaschendruck/translation
 /message
 /context
 context
@@ -784,7 +784,7 @@
 message
 location filename=../qt-ui/configuredivecomputerdialog.ui 
line=1161/
 sourceSetpoint fallback/source
-translationStandardsetpoint/translation
+translationErsatzeinstellwert/translation
 /message
 message
 location filename=../qt-ui/configuredivecomputerdialog.ui 
line=1184/
@@ -1158,7 +1158,7 @@
 message
 location filename=../qt-ui/divecomponentselection.ui line=67/
 sourceDivemaster/source
-translationDivemaster/translation
+translationTauchgruppenleiter/translation
 /message
 message
 location filename=../qt-ui/divecomponentselection.ui line=74/
@@ -1263,7 +1263,7 @@
 message
 location filename=../qt-ui/downloadfromdivecomputer.cpp line=562/
 sourceDate/time/source
-translation type=unfinished/
+translationDatum und Zeit/translation
 /message
 message
 location filename=../qt-ui/downloadfromdivecomputer.cpp line=564/
@@ -1278,7 +1278,7 @@
 message
 location filename=../qt-ui/downloadfromdivecomputer.cpp line=588/
 sourceh:/source
-translation type=unfinished/
+translationh:/translation
 /message
 message
 location filename=../qt-ui/downloadfromdivecomputer.cpp line=588/
@@ -1539,12 +1539,12 @@
 message
 location filename=../qt-ui/divelogexportdialog.ui line=140/
 sourceCSV dive profile/source
-translation type=unfinished/
+translationCSV-Tauchprofil/translation
 /message
 message
 location filename=../qt-ui/divelogexportdialog.ui line=150/
 sourceCSV dive details/source
-translation type=unfinished/
+translationCSV-Tauchdetails/translation
 /message
 message
 location filename=../qt-ui/divelogexportdialog.ui line=170/
@@ -1554,7 +1554,7 @@
 message

[PATCH] api change in libgit2-0.22

[Martin Gysel]

Yet another api change in libgit2...
let's quote the website libgit2 is ... linkable library with a solid
API ...

Signed-off-by: Martin Gysel m...@bearsh.org
---
 save-git.c | 28 ++--
 1 file changed, 18 insertions(+), 10 deletions(-)

diff --git a/save-git.c b/save-git.c
index a8f745c..6c2587b 100644
--- a/save-git.c
+++ b/save-git.c
@@ -26,6 +26,14 @@
   #define git_reference_set_target(out,ref,target,signature,log_message) \
git_reference_set_target(out,ref,target)
 #endif
+/*
+ * api break in libgit2 revision 0.22
+ */
+#if !LIBGIT2_VER_MAJOR  LIBGIT2_VER_MINOR  22
+  #define git_treebuilder_new(out, repo, source) git_treebuilder_create(out, 
source)
+#else
+  #define git_treebuilder_write(id, repo, bld)   git_treebuilder_write(id, bld)
+#endif
 
 #define VA_BUF(b, fmt) do { va_list args; va_start(args, fmt); put_vformat(b, 
fmt, args); va_end(args); } while (0)
 
@@ -464,7 +472,7 @@ static int tree_insert(git_treebuilder *dir, const char 
*name, int mkunique, git
  * set the unique flag, which will then append the SHA1
  * of the directory to the name when it is written.
  */
-static struct dir *new_directory(struct dir *parent, struct membuffer *namebuf)
+static struct dir *new_directory(git_repository *repo, struct dir *parent, 
struct membuffer *namebuf)
 {
struct dir *subdir;
const char *name = mb_cstring(namebuf);
@@ -477,7 +485,7 @@ static struct dir *new_directory(struct dir *parent, struct 
membuffer *namebuf)
 * and an empty treebuilder list of files.
 */
subdir-subdirs = NULL;
-   git_treebuilder_create(subdir-files, NULL);
+   git_treebuilder_new(subdir-files, repo, NULL);
memcpy(subdir-name, name, len);
subdir-unique = 0;
subdir-name[len] = 0;
@@ -489,7 +497,7 @@ static struct dir *new_directory(struct dir *parent, struct 
membuffer *namebuf)
return subdir;
 }
 
-static struct dir *mktree(struct dir *dir, const char *fmt, ...)
+static struct dir *mktree(git_repository *repo, struct dir *dir, const char 
*fmt, ...)
 {
struct membuffer buf = { 0 };
struct dir *subdir;
@@ -504,7 +512,7 @@ static struct dir *mktree(struct dir *dir, const char *fmt, 
...)
break;
}
if (!subdir)
-   subdir = new_directory(dir, buf);
+   subdir = new_directory(repo, dir, buf);
free_buffer(buf);
return subdir;
 }
@@ -595,7 +603,7 @@ static int save_one_picture(git_repository *repo, struct 
dir *dir, struct pictur
 static int save_pictures(git_repository *repo, struct dir *dir, struct dive 
*dive)
 {
if (dive-picture_list) {
-   dir = mktree(dir, Pictures);
+   dir = mktree(repo, dir, Pictures);
FOR_EACH_PICTURE(dive) {
save_one_picture(repo, dir, picture);
}
@@ -612,7 +620,7 @@ static int save_one_dive(git_repository *repo, struct dir 
*tree, struct dive *di
 
/* Create dive directory */
create_dive_name(dive, name, tm);
-   subdir = new_directory(tree, name);
+   subdir = new_directory(repo, tree, name);
subdir-unique = 1;
free_buffer(name);
 
@@ -738,7 +746,7 @@ static int save_one_trip(git_repository *repo, struct dir 
*tree, dive_trip_t *tr
 
/* Create trip directory */
create_trip_name(trip, name, tm);
-   subdir = new_directory(tree, name);
+   subdir = new_directory(repo, tree, name);
subdir-unique = 1;
free_buffer(name);
 
@@ -837,8 +845,8 @@ static int create_git_tree(git_repository *repo, struct dir 
*root, bool select_o
 
/* Create the date-based hierarchy */
utc_mkdate(trip ? trip-when : dive-when, tm);
-   tree = mktree(root, %04d, tm.tm_year + 1900);
-   tree = mktree(tree, %02d, tm.tm_mon + 1);
+   tree = mktree(repo, root, %04d, tm.tm_year + 1900);
+   tree = mktree(repo, tree, %02d, tm.tm_mon + 1);
 
if (trip) {
/* Did we already save this trip? */
@@ -1072,7 +1080,7 @@ static int do_git_save(git_repository *repo, const char 
*branch, bool select_onl
/* Start with an empty tree: no subdirectories, no files */
tree.name[0] = 0;
tree.subdirs = NULL;
-   if (git_treebuilder_create(tree.files, NULL))
+   if (git_treebuilder_new(tree.files, repo, NULL))
return report_error(git treebuilder failed);
 
/* Populate our tree data structure */
-- 
2.2.1

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

yet another api change in libgit

[Martin Gysel]

this is a only compile tested patch which address' the latest api break in 
libgit2.
hope this breaks nothing... any brave tester?

/martin

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

Re: Any qmake experts out there?

[Martin Gysel]

Am 29.01.2015 10:06, schrieb Anton Lundin:
 On 29 January, 2015 - Thiago Macieira wrote:
 
 On Wednesday 28 January 2015 11:04:21 Linus Torvalds wrote:
 The proper way to get the git version is to just do

  # get raw SHA1
  git rev-parse HEAD

  # get description of it
  git describe --tags --abbrev=12

 but actually accessing the .git/HEAD file directly is very wrong. But
 I have no idea how to do git commands in the *.pri file, and handling
 failure gracefully (in case it's not a git repository etc).

 You're right, but this implies always running the rule. That implies Make 
 must 
 find that a given file is not up to date, otherwise it won't run the rule. 
 In 
 turn, it means the not-up-to--date status cascades down to the binary and 
 Make 
 will recompile and relink, even if nothing changed.

 I don't know of a way to ask Make to always run some commands and inspect 
 file 
 contents before deciding what is up to date and what isn't. The closest I 
 can 
 think of is to touch or not touch another file, but in a parallel build Make 
 may have already inspected that file and decided it was up-to-date.

 Do you know of any tricks I'm missing?
 
 I've successfully managed to fool make into doing the right thing by
 conditionally declaring a target as .PHONY, but i guess that trick could
 be used on a dependency.
 
 
 .PHONY: $(shell for f in $(DATA) $(GEN) ; do \
 if [ -e $$f ]  [ $$(( $$(date +%s) - $$(date -r $$f +%s))) -gt 
 $$(($(MAX_AGE)*60)) ] ; then \
   echo $$f ; \
   fi \
   done)
 
 
 Such a trick might be plausible to use to conditionally declaring that
 dependency or not.
 

Why does it have to be a Make target at all? In the 'old' Makefile used
to build the gtk version, the logic to compare versions was triggered by
a variable assignment. if the version changed in the meantime, the
version file got changed and make picked up that change.

/martin

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

Re: Which protocol to implement on a home brewed diving computer ?

[Martin Gysel]

Am 19.03.2015 um 14:14 schrieb Anton Lundin:
 On 17 March, 2015 - Thomas Schrein (mailinglists) wrote:
 
 Robert,

 Am 16.03.2015 um 17:35 schrieb Robert Helling:
 Thomas,

 On 16.03.2015, at 14:29, Thomas Schrein (mailinglists)
 tsx...@schrein.de mailto:tsx...@schrein.de wrote:

 The housing of oDiCo is made from plexiglas version 0.1 and filled with
 silicon oel. The next housing 0.2 will be milled from POM and the
 electronic will be an industry factored PCB. Awating to have it in the
 lake in June ...

 once you are in the habit of making housings, you might be interested in a
 project idea that came up here a while ago: We all love to have cylinder
 pressure graphs in our logs. But for the dive computer to records those
 you either need a hose that tends to be in your way or a radio
 transmission which is hard to make reliable. The idea was, during the dive
 to stick with an analogue gauge (as the history is mainly important in the
 log only) but attach a little data recorder with pressure sensor directly
 to the first stage to be read out later together with the dive computer.

 I did not really pursue this idea much further since all the pressure
 sensors I could find that fit the specs (up to 400bar with at most a few
 bar resolution an simple readout) almost costed as much as the pressure
 radio transmitters (120-150 Euro/pcs) and, more importantly, my total lack
 of experience in building watertight housings.

 You might be at least the solution to part two of the problem. What do you
 think?

 Nice idea, never thought about such a logger.

 Let me first give you an overview about our approach:
 We have an 400bar industry sensor in test. We will connect it to our
 hardware version 0.1 in the next weeks and go diving.
 We made an adapter to connect it to the high pressure hole on the regulator
 and connect it with an M12-Sensor wire to the existing odico housing.
 http://www.skin-diver.org/skd/export/sites/default/sdiv/bastelecke/odico/odico-entwicklung-2014/IMG_2159.JPG_1997443631.jpg
 It works on the land, but we are not sure if its really watertight, that we
 will see in the dive.
 http://www.skin-diver.org/skd/export/sites/default/sdiv/bastelecke/odico/odico-entwicklung-2014/IMG_2179.JPG_1997443631.jpg

 One option (may be you better say vision ;-) in our project is to use the
 odico electronics to control a rebreather using CANBUS (the controller has
 it build in already) and therefore the high pressure sensor would act as an
 CANBUS node with its own buildin controller, in particular a STMF1x, less
 then 5€ each.  The electronics could be sealed with casting resin.
 For our rebreather approach we accept the existence of wires, so we don't
 need to care about energy and communication. The pressure sensors cost about
 80€, plus the adapter for the high pressure, plus the wiring, but that costs
 are not a big deal to run a rebreather.
 My fellow, Marco, also doesn't care to much building even an self made
 pressure sensor with build in electronics . He has a degree as mechanical
 engineer and he's really gifted for job!
 So we don't care too much to get it water tight.

 From my point of view a logger could be designed like this:
 - located at the high pressure hole of the first stage
 - length about 5 - 10 cm, cylindrical
 - collecting data for pressure + time
 - as an option: collection depth+temp
 - energy by an AAA or 1/2 AA lithium 3v cell than could be replaced once a
 year
 - communication via radio (bluetooth, ...)
 - shop price  200 €

 Again, I never thought that would be worth to think about it. I will discuss
 with Marco!
 If you like we can discuss more.

 
 I would be interested in such a device, even if they would be built as
 one off jobs.
 
 
 Only thing i would argue is really important is to make sure they fail
 in a sane manner, and doesn't leak or dump my gas.

It seems there's at least some interest in such a device but to get a
retail price below 200 € one needs to produce/sell more then a couple...
I also doubt a kickstarter project will help here :(

Maybe the only option would be to design such a device in the public...
I have some contacts to a pressure sensor company and a university,
maybe that's a nice student project...


 Now this one is seriously OT but a idea i hand a couple of mates had as
 a idea, a depth/time logger with a accelerometer/gyro and try to use that
 as a mapping device to try to figure out how your movements under water
 actually where.
 
 I talked with another mate who's in the defense industry and they have
 such devices on there (semi)autonomous rovs, but they combine the
 accelerometer/gyro with sonar and doppler radar against its surroundings
 for more input to their odometry models.
 
 
 That would be really cool =)

Personally I doubt you get the needed accuracy by only using the
accelerometer and gyro... but you could also couple it with some buoys
which sends a ultrasonic beacon on which you can triangulate (like gps)

/martin

Re: HighPressureLogger, Odometer/ Re: Which protocol to implement on a home brewed diving computer ?

[Martin Gysel]

Am 19.03.2015 um 20:09 schrieb Robert C. Helling:
 Hi,
 
 On 19 Mar 2015, at 18:30, Thomas Schrein (mailinglists) tsx...@schrein.de 
 wrote:
 
 About the sensor: as a first idea we found 
 this:http://www.amsys.info/sheets/amsys.en.me501_d.e.pdf
 May you have an other sensor from the sensor company ?
 
 Did you see the MSG3500 from the same Swiss manufacturer: 
 www.servoflo.com/power/download/283/556/17.html
 This seems to be specifically for scuba applications already with the correct 
 port for first stage fitting.
 
 Too bad I cannot find a dealer/price quote.

for low volume, I suggest a sensor with integrated amplifier and
temperature compensation like the Serie 23 SY from Keller
http://www.keller-druck.ch/home_g/paprod_g/23y_25y_g.asp
It may also be available with the correct HP port although no mentioned
in the datasheet.

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

Re: HighPressureLogger ... Re: Which protocol to implement on a home brewed diving computer ?

[Martin Gysel]

Am 25.03.2015 um 14:18 schrieb Anton Lundin:
 On 17 March, 2015 - Thomas Schrein (mailinglists) wrote:
 


 Betreff: HighPressureLogger ... Re: Which protocol to implement on a home
 brewed diving computer ?
 Datum:   Tue, 17 Mar 2015 15:58:09 +0100
 Von: Thomas Schrein (mailinglists) tsx...@schrein.de
 An:  Robert Helling hell...@atdotde.de



 Am 17.03.2015 um 11:48 schrieb Robert Helling:
 Hi,

 On 17.03.2015, at 11:33, Thomas Schrein (mailinglists)
 tsx...@schrein.de mailto:tsx...@schrein.de wrote:

 One option (may be you better say vision ;-) in our project is to use
 the odico electronics to control a rebreather using CANBUS (the
 controller has it build in already) and therefore the high pressure
 sensor would act as an CANBUS node with its own buildin controller, in
 particular a STMF1x, less then 5€ each.  The electronics could be sealed
 with casting resin.
 For our rebreather approach we accept the existence of wires, so we
 don't need to care about energy and communication. The pressure sensors
 cost about 80€, plus the adapter for the high pressure, plus the wiring,
 but that costs are not a big deal to run a rebreather.
 My fellow, Marco, also doesn't care to much building even an self made
 pressure sensor with build in electronics . He has a degree as
 mechanical engineer and he's really gifted for job!
 So we don't care too much to get it water tight.

 From my point of view a logger could be designed like this:
 - located at the high pressure hole of the first stage
 - length about 5 - 10 cm, cylindrical
 - collecting data for pressure + time
 - as an option: collection depth+temp
 - energy by an AAA or 1/2 AA lithium 3v cell than could be replaced once
 a year
 - communication via radio (bluetooth, ...)
 - shop price  200 €

 80 Euros for the sensor sound like a good price. May I ask which sensor
 this is?
 http://www.automation24.de/prozesssensoren/elektronischer-drucksensor-automation24-pc6706-i10-374-0.htm

 When I did my research I found that you can buy sensors that already have
 the correct fitting to go into the HP port of a first stage (UNF 7/16”).
 Where can I get it ?
 For prototyping the logger I would have started with something like
 http://www.exp-tech.de/sparkfun-logomatic-v2-serial-sd-dataloger-fat32
 That has everything including battery recharging logic (and is a USB mass
 storage device).
 Looks good for prototyping. I would take a SD device only if I wanted to use
 the SD card for the data transfer to the PC. They burn about 100mA, lot more
 than the processor itself. I wourld prefer SPI FLASH.

 As said, we will connect that sensor to our already existing housing (odico)
 and will go diving, the logging function is only a subset of the odico
 functions. So its hard to me to plan for logger an extra prototype/proof of
 concept.

 Our next steps would be more focussed in
 1. integrate the highpressure piezo sensor into a selfmade housing
 2. build a prototype with an EAGLE designed PCB that fits in a size  10cm

 What about communication? USB / radio ?
 Energy ? Rechargeable or change of the cell ?

 
 I'm kinda in the area of the fewer o-rings the better. Less failure
 points. That is a upside with radio/bt.

+1

 I'm also kinda against using rechargeable cells, because of their
 failure patterns in a lot of cases. One really nice path that both HW
 and Shearwater took with the OSTC3/Petrel is that they just take any
 AA-sized cell, and use a internal voltage regulator, so you can run them
 of a regular alkaline battery or a SAFT LS14500 if you would like more
 battery time.

I would rather take rechargeable cells at they allow a smaller form
factor. it's much easier to seal everything than have a water resistant
housing...

 
 For the form factor, i would love something that fits on my right post
 of my doubles.
 
 Some nice references about dir-rigged doubles can be found at Peters
 site:
 http://dir-diver.com/en/equipment/reg_config_doubles.html
 
 As you see in those pictures, theres quite a bit of room below the right
 regulator, or between the doubles. Then you can safely store the data
 logger nicely tucked away in a protected spot.
 
 Maybe with a 15cm cable/hp hose between the port and the brick,
 depending on the size of the brick.

I wouldn't use a hp hose to connect the sensor with the 1st stage as it
increase the risk of failure. I think it's better to connect the sensor
to the hp port directly but place the rest of the electronic away from
it. so you can have a very tiny sensor and only one hp connection and
one O-ring. the 'logger' and battery can be place away at a place where
size is nit critical.
I also find it very annoying that most or even all wireless pressure
sensors are very bulky. it also lead to people carrying the tank holding
the wireless sensor :(

 The problem comes when you try to use the second hp-port on a stage
 bottle. That one is in a really exposed position:
 

Re: git backend: actually update local cache from remote

[Martin Gysel]

Am 11.06.2015 um 07:25 schrieb Robert C. Helling:
 
 On 11 Jun 2015, at 06:16, Dirk Hohndel d...@hohndel.org wrote:
 
 Good morning,
 
 This is kind of a hybrid of what you are talking about. If you are
 on a boat or on an island with shitty network you can simply work
 from the local cache. And if you suddenly have some connectivity
 you can trigger an upload to the remote in a very straight forward
 fashion.
 
 What am I missing?
 
 I would aim at making it maximally transparent to the user (as
 dropbox does for example): There are two states: Good network
 connection or no good network connection. Subsurface tries to guess
 that (for example by asking the OS about network connectivity beyond
 localhost or by trying to ping the cloud server or quickly
 downloading some data from the cloud server to estimate the
 connection speed) but there is a switch for the user to set it
 manually (like a little cloud icon that gets greyed out when there is
 no good connectivity).
 
 Without net, the remote server is ignored (obviously).
 
 When transitioning from bad to good state (or on startup) we trigger
 a sync (fetch and merge and then possibly push) in the background and
 after save we trigger a push (again in the background).
 
 Writing this, I wonder if we really should differentiate between push
 and pull or if we (again as dropbox) just try as much as possible to
 keep local and remote in sync (i.e. always fetch, merge and push in
 one go).
 
 I would to all cloud access in the background and offer the user (via
 a modal dialog) to reload when the background operation finished and
 implied an update to the currently displayed log.
 
 I never thought these operations are that hard to design a good
 workflow/UI for. I thought, only conflict resolution and version
 management beyond opening a terminal and ask the user to fix it on
 the command line would be hard…

please don't do any cloud sync in the background unconditionally. either
have something like a 'automatically sync with cloud' setting or allow
the user to trigger or at least cancel the sync.

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

Re: git backend: actually update local cache from remote

[Martin Gysel]

Am 11.06.2015 um 15:28 schrieb Dirk Hohndel:
 On Thu, Jun 11, 2015 at 12:15:12PM +0200, Martin Gysel wrote:

 I would to all cloud access in the background and offer the user (via
 a modal dialog) to reload when the background operation finished and
 implied an update to the currently displayed log.

 I never thought these operations are that hard to design a good
 workflow/UI for. I thought, only conflict resolution and version
 management beyond opening a terminal and ask the user to fix it on
 the command line would be hard…

 please don't do any cloud sync in the background unconditionally. either
 have something like a 'automatically sync with cloud' setting or allow
 the user to trigger or at least cancel the sync.
 
 Yes, I'd have an option in the preferences. Would you object to this
 option defaulting to on?

that's ok...

 How would a cancel of a background sync work? How would I trigger that?
 
 I'm just trying to understand what you have in mind.

like you described earlier, using the spinner or a similar dialog which
is visible when synching


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

Re: Location, location, location

[Martin Gysel]

Am 15.07.2015 um 10:10 schrieb Henrik Brautaset Aronsen:
 On Wed, Jul 15, 2015 at 1:45 AM, Dirk H dir...@gmail.com
 mailto:dir...@gmail.com wrote:


 So now I have Blu which completes to Blue Corner, Blue Grotto or
 Blue Hole.
 You also see an example of a dive site with no GPS data in that list.
 If you were to pick that site, we will add the GPS data in your
 current dive to that site.

 Now assume you have no GPS data. Here's what you'd see:




 This looks really good!   But how do I create a new dive site with the
 name Blu?  That first line in the pull down (with create dive site)
 shouldn't perform autocompletion, should it?

 Henrik

I've just skimmed though the thread and think there's an easy way to
make everyone happy

do the autocompletion in the Location text field. the letters type are
black, the completion gray. once you hit right array or even enter, the
completion is selected.
the list with the already existing spots is the same as shown in the
screenshot, except the top most entry, which equals to the black,
manually entered part of the text field.
with this approach it is very easy to use a already existing name (just
hit right array and select the top most entry in the list with the
'plus' symbol) but also very intuitive to create a new divesite, with
selecting the top most entry as well. - everybody is happy, although
Linus may hit one key more to make the completion.

/martin

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

Sourcecode of modified 3. party libs

[Martin Gysel]

Hi Dirk

What do you think about archiving the modified 3rd party libs for each
subsurface release (e.g. in a separate tar Subsurface-bundle.tgz)?
Otherwise it's not so trivial to know what lib has been used in which
version to build the official release binary. It would also help
packaging it for distros where shipping bundles libs is possible.

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

Re: Sourcecode of modified 3. party libs

[Martin Gysel]

Am 02.11.2015 um 16:26 schrieb Dirk Hohndel:
> On Mon, Nov 02, 2015 at 02:05:38PM +0100, Martin Gysel wrote:
>> Hi Dirk
>>
>> What do you think about archiving the modified 3rd party libs for each
>> subsurface release (e.g. in a separate tar Subsurface-bundle.tgz)?
>> Otherwise it's not so trivial to know what lib has been used in which
>> version to build the official release binary. It would also help
>> packaging it for distros where shipping bundles libs is possible.
> 
> I thought I did and just realized that I forgot to copy the marble one (as
> it didn't change between 4.5 and 4.5.1).
> 
> http://subsurface-divelog.org/downloads/libdivecomputer-subsurface-branch-4.5.1.tgz
> http://subsurface-divelog.org/downloads/marble-subsurface-branch-4.5.1.tgz
> 
> /D

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

Re: Swiss Translations

[Martin Gysel]

Hi Guido

Am 12.10.2015 um 11:00 schrieb Guido Lerch:
> Hi Dirk,
> I translated over 150 string for Swiss, last master does not contain those.
> Any reason why?
> I still have about 140 more to do though.

I first started the swiss translations but at the moment lack some time
do do any subsurface related work. My intension was to have the Swiss
translation close to the German one but without 'ß' and without some
words which sound very strange for me as a Swiss like
'Tauchgruppenleiter' (where I mostly used the English version which is,
according to my experience well used by Swiss divers). To ease
maintenance I always downloaded the latest Swiss and German version and
merged them in a merge tool like kdiff3. Where needed I could easily
modify the translation.
I still hope I have some 30min spare to help you before the big release :)

/martin

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

Re: Swiss Translations

[Martin Gysel]

Am 12.10.2015 um 14:36 schrieb Guido Lerch:
> Hi Martin
> 
> 2015-10-12 14:03 GMT+02:00 Martin Gysel <m...@bearsh.org
> <mailto:m...@bearsh.org>>:
> 
> Hi Guido
> 
> Am 12.10.2015 um 11:00 schrieb Guido Lerch:
> > Hi Dirk,
> > I translated over 150 string for Swiss, last master does not contain 
> those.
> > Any reason why?
> > I still have about 140 more to do though.
> 
> I first started the swiss translations but at the moment lack some time
> do do any subsurface related work. My intension was to have the Swiss
> translation close to the German one but without 'ß' and without some
> words which sound very strange for me as a Swiss like
> 'Tauchgruppenleiter' (where I mostly used the English version which is,
> according to my experience well used by Swiss divers). To ease
> maintenance I always downloaded the latest Swiss and German version and
> merged them in a merge tool like kdiff3. Where needed I could easily
> modify the translation.
> I still hope I have some 30min spare to help you before the big
> release :)
> 
> That would be nice, I am new and don't know all the tools yet, hence I
> switched my SSRF to German
> and then changed the Swiss translations.
> Apparently there is a faster way which I am not aware of.
> Can't we not just copy the german transl. over the Swiss one and the use
> the search to find
> the the scharf s etc. ? 

sure that would be possible but as said, in the German version there are
a lot of expressions (ot only the 'ß') which sound very strange for me
as a Swiss. This expressions were the main reason for me to start the
translation, I can live with a couple of 'ß' but I really would like to
call the diveguide 'Diveguide' and not 'Tauchgruppenleiter'

/martin

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

Re: [PATCH] WIP: use kirigami plugin instead of embedding in qrc

[Martin Gysel]

Am 30.05.2016 um 13:59 schrieb Marco Martin:
> On Sunday 29 May 2016, Dirk Hohndel wrote:
>> To make matters worse, Tomaz no longer has access to a Mac so he can’t
>> help, either. Which means that right now a Kirigami version that requires
>> the plugin is a non-starter for Subsurface-mobile on iOS. I simply don’t
>> understand how this is supposed to work and nothing that I find online
>> seems to address this combination in a way that I can follow. Not sure
>> what the solution here should be. A qmake file for the kirigami plugin
>> maybe?
> 
> If you want to give it a try, in the branch mart/runtimeTheme (that's the 
> branch where i switch to requiring an actual c++ plugin)
> I added a minimal qmake file. I only tried it on my local system, but it 
> seems 
> to build it correctly here.
> 

I'm wondering if it would be possible to get Kirigami 'into' qpm [1].
That way it would be much simpler to use it in any qmake base app.

I once played around with it and tried to create a .pri file but for
some reasons I failed.

I also tried to use Kirigami in a small toy project where I first
struggled. Now I can run the app locally but only by setting the QML
import path and autocompletion in qt creator still does not work.

As Kirigami is a KDE project it may make sense to use cmake but the way
Kirigami use cmake makes it definitely not easy to actually use Kirigami
as a framework for most projects.

/martin

[1] https://www.qpm.io/

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

Re: [PATCH] WIP: use kirigami plugin instead of embedding in qrc

[Martin Gysel]

Am 30.05.2016 um 14:55 schrieb Marco Martin:
> On Monday 30 May 2016, Martin Gysel wrote:
>> Am 30.05.2016 um 13:59 schrieb Marco Martin:
>>> On Sunday 29 May 2016, Dirk Hohndel wrote:
>>>> To make matters worse, Tomaz no longer has access to a Mac so he can’t
>>>> help, either. Which means that right now a Kirigami version that
>>>> requires the plugin is a non-starter for Subsurface-mobile on iOS. I
>>>> simply don’t understand how this is supposed to work and nothing that I
>>>> find online seems to address this combination in a way that I can
>>>> follow. Not sure what the solution here should be. A qmake file for the
>>>> kirigami plugin maybe?
>>>
>>> If you want to give it a try, in the branch mart/runtimeTheme (that's the
>>> branch where i switch to requiring an actual c++ plugin)
>>> I added a minimal qmake file. I only tried it on my local system, but it
>>> seems to build it correctly here.
>>
>> I'm wondering if it would be possible to get Kirigami 'into' qpm [1].
> 
> I'll look into it
> 
>> That way it would be much simpler to use it in any qmake base app.
>>
>> I once played around with it and tried to create a .pri file but for
>> some reasons I failed.
> 
> I made it build in a branch with a cmake project already, i'll take a look at 
> doing a .pri as well
> 

sounds great, thx :)
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Advanced alternative to cloud storage in Subsurface mobile

[Martin Gysel]

Am 18.02.2016 um 18:41 schrieb Tim Wootton:
> On 18/02/16 15:18, Dirk Hohndel wrote:
>> On Thu, Feb 18, 2016 at 03:13:56PM +0100, Anton Lundin wrote:
>>> Hi.
>>>
>>> I was thinking about adding a "advanced settings" to the cloud storage
>>> credentials screen, were one could point the app to a local xml file, or
>>> a local git repo. That way one can test the app without the need to push
>>> data to the could storage first.
>>>
>>> Also, the mobile app is built with libgit2 with libssh support, so
>>> adding support for using a alternative git url with a ssh key would be
>>> really nice to.
>>>
>>> All the bits are basically already there, from the desktop app, so
>>> getting this working in the mobile app would as usual just be a matter
>>> of building a Qml ui for it.
>>>
>>>
>>> I'm currently out of a working laptop so I won't be implementing this
>>> anytime soon, but just floating the idea here. Anyone against?
>> This falls into the "I understand why you want this, but I don't want this
>> in the app that will be in the app store" category.
>>
>> Yes, this is really useful for six people who know what they are doing.
> I must be one of those 6 people, this turns out to be exactly the
> feature  was waiting for. I'd like to be able to access my dives from my
> home server on my mobile (over VPN when I'm away from home). I'd
> resigned myself to the fact that the Andoid app wasn't going to be for
> me because it only worked with the one anointed data store .
> 
> Hands up, who are the other five?

although I created a cloud account recently to be able to use and test
the mobile app I would really appreciate such a feature, so anther +1

only a few more to prove dirk wrong ;)

>> No, this is not useful and only will cause confusion, bugs, the need for
>> more testing, and endless explaining to users "no, this isn't what you are
>> looking for" to our target audience.

I'm not claiming to know the target audience but there are other apps in
the store with such a functionality, like Password Store, an Android
port of pass...

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

Re: Developing and Deploying devices

[Martin Gysel]

Am 12.04.2016 um 11:53 schrieb Robert Helling:
> Hi,
> 
> I have been thinking a bit more about setting up a small device
> (C.H.I.P. or similar) to do the dive computer read out and communication
> with the mobile device.
> 
> One thing I am worried about is how to collaboratively develop for such
> a target. It is quite likely that we have to modify system files and
> settings (like startup, maybe configure BT or networking, instilling
> packages etc). How can we put that in version control? Do everything
> with a script and version control that script? For configuration files,
> one could have those in a directory under git and then have a small
> script that writes them in the appropriate places (and sets permissions
> etc). But maybe people have better ideas. Am I reinventing a packaging
> system?

'make install' could copy over all needed system files (which hopefully
are only whole files to add, nothing to patch...)
alternatively if using a debian based image, a dpkg (containing all
needed files) could be created and then installed.

> The other thing is deployment. Initially, that’s simple, we provide disk
> images. But then, what is the upgrade path? Connect to wifi and do git
> pull? apt-get upgrade/update? Get a new disk image? That needs to be
> thought about as well for devices like this.

I think it depends on the used base. if it's a debian based system (and
I would start with such a system), then providing a apt-get urls seems
to be the easiest solution. if using a leaner base (e.g. to reduce
startup time as much as possible) then flashing a whole image and/or
replace changed files (using a script or so) may be the best way.

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

Re: Developing and Deploying devices

[Martin Gysel]

Am 12.04.2016 um 16:36 schrieb Dirk Hohndel:
> 
>> On Apr 12, 2016, at 4:53 AM, Martin Gysel <m...@bearsh.org> wrote:
>>> The other thing is deployment. Initially, that’s simple, we provide disk
>>> images. But then, what is the upgrade path? Connect to wifi and do git
>>> pull? apt-get upgrade/update? Get a new disk image? That needs to be
>>> thought about as well for devices like this.
>>
>> I think it depends on the used base. if it's a debian based system (and
>> I would start with such a system), then providing a apt-get urls seems
>> to be the easiest solution. if using a leaner base (e.g. to reduce
>> startup time as much as possible) then flashing a whole image and/or
>> replace changed files (using a script or so) may be the best way.
> 
> Martin, I love your optimism. And I can tell that you are not part of the 
> people
> here who try to support our end users. I recommend that you go through our
> user forum and our FB page and look at the questions we are getting.
> 
> No, this cannot be based on apt-get URLs.

maybe you misunderstood me, I'm not proposing to have the enduser type
apt-get ..., rather let the system update itself using apt-get. but
event then, you might be right, it can cause troubles to the enduser
when e.g. there's a power failure in a critical phase of the upgrade.


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

Re: Divecomputer-reading from Mobile devices (Was: Divemate Fusion)

[Martin Gysel]

Am 09.04.2016 um 23:55 schrieb Dirk Hohndel:
> On Sat, Apr 09, 2016 at 02:46:32PM -0700, Linus Torvalds wrote:
>> On Sat, Apr 9, 2016 at 1:59 PM, Dirk Hohndel  wrote:
>>>
>>> It would be equally easy to build a full Subsurface - we seem to have a
>>> pretty complete Debian distro here.
>>
>> Well, there's only 4GB of emmc flash (and 512MB RAM) on that thing, so
>> I think it would be cramped to actually build subsurface on it.
>>
>> But yeah, you don't actually want a UI, you really just want a process
>> that links to libdivecomputer and can communicate over bluetooth to
>> get commands and return results.
> 
> I have a simple BLE app but can't quite connect to it, yet. But I'm pretty
> sure that this is just a matter of reading the docs one more time :-)

keep in mind, the throughput of a BLE connection is quite limited
(~32kbps on iOS, maybe up to ~84kbps on Android [1]). to download more
than a couple of dives a wifi connection might be the better option.
furthermore already used technology like git could be used to transfer
the dive from the 'device' to the mobile or to the cloud directly. BLE
could be used to command it.

/martin

[1]
https://devzone.nordicsemi.com/question/3440/how-do-i-calculate-throughput-for-a-ble-link/


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

Re: Divecomputer-reading from Mobile devices (Was: Divemate Fusion)

[Martin Gysel]

Am 10.04.2016 um 15:53 schrieb Dirk Hohndel:
> 
>> On Apr 10, 2016, at 12:42 AM, Robert Helling > > wrote:
>>
>> Hi,
>>
>> this is going fast!
>>
>>> On 09.04.2016, at 18:57, Linus Torvalds
>>> >> > wrote:
>>>
>>> Because $9 is $9. And depending on where I ship it, the postage is
>>> going to be more than that ;)
>>
>> Availability seems to be a problem at the moment. I preordered two at
>> their website and it said „Ships in June 2016“. Let’s hope for the best.
> 
> Yeah, I talked to the VP of Marketing. They can't make them fast enough.
> 
>> In the meantime I will play a bit with a Pi that I have right here. I
>> was thinking along the lines of adding a command line option to
>> subsurface which just downloads new dives from an attached dive
>> computer and updates the local git accordingly. Leaving the BT stuff
>> for the moment and maybe doing wifi first (as that should be easier
>> there).
> 
> I don't think we need a command line option for Subsurface.
> libdivecomputer already has a command line tool. I've used that
> successfully on my C.H.I.P to download from the Cobalt.

I can think of one reason to use subsurface (at least some parts of it)
to download the dives instead of libdc directly is subsurface supports
the Uemis whereas libdc doesn't.

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

Re: Kirigami patches

[Martin Gysel]

Am 16.08.2016 um 01:55 schrieb Dirk Hohndel:
> It's pretty clear that no one ever tested the kirigami.pro qmake file. The
> second patch I'm not 100% sure about, but it seems to match what the
> documentation tells us SHOULD be done.

maybe my understanding of the qt build system, tools and libraries is
wrong, but wouldn't it be better to

- use the .pri file when directly linking in kirigami into the (parent)
project (include directive in PROJECT.pro), then the Q_INIT_RESOURCE is
not necessary. using qmake this seems to be the easiest way and at least
seems to compile for different platforms.

- use the .pro file when using kirigami as library/plugin (static or
dynamic, from a parent 'subdirs' pro file). then the static variant
needs the Q_INIT_RESOURCE. using this approach leads at least on iOS to
various problems linking the app and not finding the resources at
runtime (so it did so while I tested this)

this also means we probably need another define like
KIRIGAMI_BUILD_TYPE_STATIC_PLUGIN and/or KIRIGAMI_BUILD_TYPE_DYNAMIC_PLUGIN

/martin

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

Re: 4.6.3

[Martin Gysel]

Am Donnerstag, 2. März 2017, 08:05:38 CET schrieb Dirk Hohndel:
> I tagged it, built it, pushed it, posted the announcement to our site, but
> for once didn't post it on FB, G+ or anywhere else - this way the
> translators have a chance to translate the announcement on github... let's
> see if that works and I can then post the announcement to FB tomorrow
> 
> Thank you so much for all the hard work on getting Greek and Italian all
> the way done and many of the other translations significantly improved.

Dirk, tags on marble and libdc are missing

/martin

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

[PATCH] tex export: check site pointer, before accessing it; print empty string rather than 'null'

[Martin Gysel]

Signed-off-by: Martin Gysel <m...@bearsh.org>
---
 desktop-widgets/divelogexportdialog.cpp | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/desktop-widgets/divelogexportdialog.cpp 
b/desktop-widgets/divelogexportdialog.cpp
index 9d3d271..6121bd9 100644
--- a/desktop-widgets/divelogexportdialog.cpp
+++ b/desktop-widgets/divelogexportdialog.cpp
@@ -282,7 +282,7 @@ void DiveLogExportDialog::export_TeX(const char *filename, 
const bool selected_o
put_format(, "\\def\\date{%04u-%02u-%02u}\n",
  tm.tm_year, tm.tm_mon+1, tm.tm_mday);
put_format(, "\\def\\number{%d}\n", dive->number);
-   put_format(, "\\def\\place{%s}\n", site->name);
+   put_format(, "\\def\\place{%s}\n", site ? site->name : "");
put_format(, "\\def\\spot{}\n");
put_format(, "\\def\\country{}\n");
put_format(, "\\def\\entrance{}\n");
@@ -293,8 +293,8 @@ void DiveLogExportDialog::export_TeX(const char *filename, 
const bool selected_o
put_format(, "\\def\\type{%s}\n", dive->tag_list ? 
dive->tag_list->tag->name : "");
put_format(, "\\def\\viz{%s}\n", viz.toUtf8().data());
put_format(, 
"\\def\\plot{\\includegraphics[width=9cm,height=4cm]{profile%d}}\n", 
dive->number);
-   put_format(, "\\def\\comment{%s}\n", dive->notes);
-   put_format(, "\\def\\buddy{%s}\n", dive->buddy);
+   put_format(, "\\def\\comment{%s}\n", dive->notes ? 
dive->notes : "");
+   put_format(, "\\def\\buddy{%s}\n", dive->buddy ? 
dive->buddy : "");
put_format(, "\\page\n");
}
 
-- 
2.10.1

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

Re: Very timid beginning framework for BLE communication

[Martin Gysel]

Am 24.04.2017 um 01:47 schrieb Linus Torvalds:
> On Sun, Apr 23, 2017 at 1:49 PM, Anton Lundin  wrote:
>>
>> As far as I've understood things, even the scan for devices are
>> completely different, so is the reason that Qt merges the two scan
>> results?
> 
> So as far as Qt seems to be concerned, "scan for devices" is all
> exactly the same. Only after the scan does the whole LE vs RFCOMM come
> into play.
> 
> So I'd rather share the scanning code, because I think that all can be common.

exactly, AFAIK starting with Qt 5.8 it's possible to only scan for e.g.
ble devices which speeds up scanning.

> 
>> That said, I would have liked to see that device pop up as two in the
>> device list, so you can choose if you would like to talk rfcomm to it or
>> btle.
> 
> I have no idea whether that is how it can actually work.
> 
> I *think* it shows up as one device as far as the Qt layer is
> concerned, and then you can look at the device->coreConfigurations()
> to see what different configurations it supports.

I don't thinks so, as classic and low energy devices are completely
different... the almost only things they have in common is the name
bluetooth ;)


/martin

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

Re: 4.7.1 released

[Martin Gysel]

Am 22.10.2017 um 12:46 schrieb Dirk Hohndel:
> With all the confusion (caused by me, no one else to blame - ok, I blame
> the bad internet here which made it worse) I decided to call this one
> 4.7.1. The OBS builds of 4.7.0 snuck out and I didn't realize until much
> later that they were available for download. Simply to avoid any
> additional pain from all this, I decided to skip ahead and call the
> official release 4.7.1. What's in a number, anyway.
> 
> I expect to make a 4.7.2 pretty soon and then the goal is to keep making
> monthly(-ish) releases. Please call me on it if I don't keep it up.
> And yes, I know that Subsurface-mobile vs Subsurface will mess with that.
> But we should try.
> 
> As always, the thanks goes to all of you. The developers, testers,
> documentation authors and reviewers, translators, all of you. The stats
> don't show the translators (the one downside of Transifex), but here they
> are:
> 
> $ git shortlog -s -n v4.6.4..v4.7.1
>407  Dirk Hohndel
>160  Lubomir I. Ivanov
> 92  Jan Mulder
> 63  Joakim Bygdell
> 63  Miika Turkia
> 53  Stefan Fuchs
> 52  Tomaz Canabrava
> 40  Robert Helling
> 34  Linus Torvalds
> 23  Anton Lundin
> 18  Salvador Cuñat
>  8  Rick Walsh
>  8  Willem Ferguson
>  7  Guillaume GARDET
>  6  Alex Blasche
>  6  John Van Ostrand
>  6  Seppo Takalo
>  3  Marc Arndt
>  3  Philippe Massart
>  2  Subsurface
>  2  Thiago Macieira
>  1  Ben McCandless
>  1  Darexon
>  1  Federico Masias
>  1  Olivier Verstraet
>  1  Robert Bodily
>  1  Robert C. Helling
>  1  Seamus Boyle
>  1  bs
> 
> Some names in there that have been in the top for many years, some new
> names (which always makes me happy).
> 
> Please continue to translate, continue to test, send those updates.  I'll
> hold back the public release announcement until after today's diving -
> just to make sure there aren't any more last second gotchas.

Dirk, can you please also tag the corresponding libdc version (I suppose
c0f025b?)

thanks
martin

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

Re: Subsurface on Opensuse Tumbleweed

[Martin Gysel]

Am 20.06.2018 um 19:46 schrieb Thiago Macieira:
> On Wednesday, 20 June 2018 07:23:27 PDT guillaume.gar...@free.fr wrote:
>> If I click the dive number it is fine. Otherwise, I get a blank area with
>> the following messages in console: QPainter::begin: Paint device returned
>> engine == 0, type: 2
>>   QPainter::setFont: Painter not active
>>   QPainter::setOpacity: Painter not active
>>   QPainter::end: Painter not active, aborted
> Can you run with QT_FATAL_WARNINGS=1 and once Subsurface aborts, get the 
> backtrace from these warnings?
>
> If these are not the first warnings printed by Subsurface, increase the 
> number 
> 1 to be the number of warnings until that "QPainter::begin".
>
I get the following backtrace:

QPainter::begin: Paint device returned engine == 0, type: 2

Thread 1 "subsurface" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51  ../sysdeps/unix/sysv/linux/raise.c: Datei oder Verzeichnis nicht
gefunden.
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x701c1ec1 in __GI_abort () at abort.c:79
#2  0x7118ffb0 in QMessageLogger::warning(char const*, ...)
const () from /usr/lib64/libQt5Core.so.5
#3  0x72724f74 in QPainter::begin(QPaintDevice*) () from
/usr/lib64/libQt5Gui.so.5
#4  0x73551777 in ?? () from /usr/lib64/libQt5Widgets.so.5
#5  0x73551c0c in QHeaderView::mousePressEvent(QMouseEvent*) ()
from /usr/lib64/libQt5Widgets.so.5
#6  0x7332823f in QWidget::event(QEvent*) () from
/usr/lib64/libQt5Widgets.so.5
#7  0x733c9a5e in QFrame::event(QEvent*) () from
/usr/lib64/libQt5Widgets.so.5
#8  0x73540cbb in QAbstractItemView::viewportEvent(QEvent*) ()
from /usr/lib64/libQt5Widgets.so.5
#9  0x7355075c in QHeaderView::viewportEvent(QEvent*) () from
/usr/lib64/libQt5Widgets.so.5
#10 0x7134b85a in
QCoreApplicationPrivate::sendThroughObjectEventFilters(QObject*,
QEvent*) () from /usr/lib64/libQt5Core.so.5
#11 0x732e8d55 in QApplicationPrivate::notify_helper(QObject*,
QEvent*) () from /usr/lib64/libQt5Widgets.so.5
#12 0x732f084f in QApplication::notify(QObject*, QEvent*) ()
from /usr/lib64/libQt5Widgets.so.5
#13 0x7134ba97 in QCoreApplication::notifyInternal2(QObject*,
QEvent*) () from /usr/lib64/libQt5Core.so.5
#14 0x732ef822 in QApplicationPrivate::sendMouseEvent(QWidget*,
QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer&, bool)
() from /usr/lib64/libQt5Widgets.so.5
#15 0x733428e3 in ?? () from /usr/lib64/libQt5Widgets.so.5
#16 0x73344ea9 in ?? () from /usr/lib64/libQt5Widgets.so.5
#17 0x732e8d7c in QApplicationPrivate::notify_helper(QObject*,
QEvent*) () from /usr/lib64/libQt5Widgets.so.5
#18 0x732f02f4 in QApplication::notify(QObject*, QEvent*) ()
from /usr/lib64/libQt5Widgets.so.5
#19 0x7134ba97 in QCoreApplication::notifyInternal2(QObject*,
QEvent*) () from /usr/lib64/libQt5Core.so.5
#20 0x725320a3 in
QGuiApplicationPrivate::processMouseEvent(QWindowSystemInterfacePrivate::MouseEvent*)
() from /usr/lib64/libQt5Gui.so.5
#21 0x72533d25 in
QGuiApplicationPrivate::processWindowSystemEvent(QWindowSystemInterfacePrivate::WindowSystemEvent*)
() from /usr/lib64/libQt5Gui.so.5
#22 0x7250cc7b in
QWindowSystemInterface::sendWindowSystemEvents(QFlags)
() from /usr/lib64/libQt5Gui.so.5
#23 0x7fffe370a9eb in ?? () from /usr/lib64/libQt5XcbQpa.so.5
#24 0x7134a88a in
QEventLoop::exec(QFlags) () from
/usr/lib64/libQt5Core.so.5
#25 0x71353270 in QCoreApplication::exec() () from
/usr/lib64/libQt5Core.so.5
#26 0x5566b527 in main ()

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

Re: Subsurface on Opensuse Tumbleweed

[Martin Gysel]

Am Mittwoch, 20. Juni 2018, 22:15:27 CEST schrieb Thiago Macieira:
> On Wednesday, 20 June 2018 12:35:45 PDT Martin Gysel wrote:
> > I get the following backtrace:
> > 
> > QPainter::begin: Paint device returned engine == 0, type: 2
> 
> Thanks Martin.
> 
> I don't see anything in the backtrace belonging to Subsurface, so this
> appears to be a regular Qt regression. Turns out there were a lot of
> changes to QHeaderView earlier this year, so one of the must be at fault. I
> can't spot which one just by looking though.
> 
> To help constrain the search, do you know if this warning was printed with
> Qt 5.10 too?

I switch from 5.9.x to 5.11, so I don't know

> 
> > #3  0x72724f74 in QPainter::begin(QPaintDevice*) () from
> > /usr/lib64/libQt5Gui.so.5
> > #4  0x73551777 in  () from /usr/lib64/libQt5Widgets.so.5
> > #5  0x73551c0c in QHeaderView::mousePressEvent(QMouseEvent*) ()
> > from /usr/lib64/libQt5Widgets.so.5
> 
> I'm trying to guess which frame is that ??, but it's not clear what it is.
> My first guess was QHeaderViewPrivate::setupSectionIndicator, which does
> have a QPainter, but that function is painting on a QPixmap and that
> wouldn't have printed the warning. But that leaves me out of options.
> 
> Can you install the debug symbols for the library?
> 
>   zypper in libQt5Gui5-debuginfo
> 
> That should resolve the ?? to something useful, and possibly also give us
> line numbers.

I this still needed after the backtrace from Dietrich? If so I can compile 
5.11.1 with debug 
symbols (I'm on gentoo)

> 
> PS: I'm experimenting with an optimised build of Qt5 that you can find at
> https://build.opensuse.org/package/show/
> home:thiagomacieira:branches:openSUSE:Factory/libqt5-qtbase

is there any related patch included I should try?

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

Re: Re : Re: Subsurface on Opensuse Tumbleweed

[Martin Gysel]

Am 20.06.2018 um 13:04 schrieb Dirk Hohndel:
> It builds. What happens if you resort the dive list based on a different 
> column?
once I upgraded to Qt-5.11.1 (on gentoo), the issue has gone (was there
with 5.11)

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

Re: experimenting with milestones at github

[Martin Gysel]

Am Freitag, 6. Juli 2018, 04:21:37 CEST schrieb Dirk Hohndel:
> I can't see a milestone on GitHub - am I looking at this wrong?

https://github.com/Subsurface-divelog/subsurface/milestones

> 
> /D
> 
> > On Jul 5, 2018, at 4:05 PM, Lubomir I. Ivanov  wrote:
> > 
> > a milestone can be used to distinguish issues and PRs that are
> > targeting a release.
> > for example, we already released 4.8, but all 4.8.x issues and PRs
> > should have the same 4.8 milestone.
> > 
> > i've added the 4.8 milestone at github and assigned one issue for it for
> > now: https://github.com/Subsurface-divelog/subsurface/issues/1461
> > 
> > here are a couple of other bugs that could be fixed in 4.8.1 as well:
> > https://github.com/Subsurface-divelog/subsurface/issues/1445
> > https://github.com/Subsurface-divelog/subsurface/issues/1446
> > 
> > if you think there are more, we can add them.
> > 
> > lubomir


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

Re: subsurface builds, but dumps core at startup :(

[Martin Gysel]

Am 11.09.18 um 18:21 schrieb Cristian Ionescu-Idbohrn:
> This is on debian unstable, subsurface master.  Seen this happening 
> since a few days back.
> 
> The kernel reports:
> 
> Sep 11 17:36:33 host kernel: [11915775.481135] subsurface[24251]: segfault at 
> 7fea4684ec60 ip 7fea4684ec60 sp 7ffd83e6ad38 error 15
> Sep 11 17:36:33 host kernel: [11915775.481145] 
> inlibqtgeoservices_googlemaps.so[7fea4684b000+8000]

did you switch the qt version but did not rebuild the googlemaps
qtlocation plugin? it depends on internal api so a rebuild is needed...

/martin


> 
> This is what happens:
> 
> $ ./subsurface/build/subsurface -vvv
> QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-user'
> QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-user'
> Subsurface v4.8.1-371-g619a52635a7f,
> built with libdivecomputer v0.7.0-devel-Subsurface-NG 
> (a9c582e26fe823bc7981ba5ee0510ad9d6f86017)
> built with Qt Version 5.11.1, runtime from Qt Version 5.11.1
> built with libgit2 0.26.0
> "validateGL(): created OpenGLContext."
> "validateGL(): obtained QOpenGLFunctions."
> "validateGL(): detected OpenGL version 4.6."
> Plugins Directory:  QDir( "./subsurface/build" , nameFilters = { "*" },  
> QDir::SortFlags( Name | IgnoreCase ) , QDir::Filters( 
> Dirs|Files|Drives|AllEntries ) )
> 
> $ gdb ./subsurface/build/subsurface core
> GNU gdb (Debian 8.1-4+b1) 8.1
> Copyright (C) 2018 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from ./subsurface/build/subsurface...done.
> [New LWP 24251]
> [New LWP 24253]
> [New LWP 24256]
> [New LWP 24254]
> [New LWP 24252]
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> Core was generated by `./subsurface/build/subsurface -vvv'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  0x7fea4684ec60 in qt_meta_data_QGeoTiledMapGooglemaps ()
>from 
> ./install-root/usr/lib/x86_64-linux-gnu/qt5/plugins/geoservices/libqtgeoservices_googlemaps.so
> [Current thread is 1 (Thread 0x7fea5c7b6a40 (LWP 24251))]
> (gdb) bt full
> #0  0x7fea4684ec60 in qt_meta_data_QGeoTiledMapGooglemaps ()
>from 
> ./install-root/usr/lib/x86_64-linux-gnu/qt5/plugins/geoservices/libqtgeoservices_googlemaps.so
> No symbol table info available.
> #1  0x7fea670575b4 in 
> QDeclarativeGeoMapCopyrightNotice::setMapSource(QDeclarativeGeoMap*) () from 
> /usr/lib/x86_64-linux-gnu/libQt5Location.so.5
> No symbol table info available.
> #2  0x7fea6703e1f3 in QDeclarativeGeoMap::mappingManagerInitialized() ()
>from /usr/lib/x86_64-linux-gnu/libQt5Location.so.5
> No symbol table info available.
> #3  0x7fea6703edc1 in QDeclarativeGeoMap::pluginReady() ()
>from /usr/lib/x86_64-linux-gnu/libQt5Location.so.5
> No symbol table info available.
> #4  0x7fea6703efc6 in 
> QDeclarativeGeoMap::setPlugin(QDeclarativeGeoServiceProvider*) () from 
> /usr/lib/x86_64-linux-gnu/libQt5Location.so.5
> No symbol table info available.
> #5  0x7fea670a29d1 in ?? ()
>from /usr/lib/x86_64-linux-gnu/libQt5Location.so.5
> No symbol table info available.
> #6  0x7fea670a3673 in QDeclarativeGeoMap::qt_metacall(QMetaObject::Call, 
> int, void**) () from /usr/lib/x86_64-linux-gnu/libQt5Location.so.5
> No symbol table info available.
> #7  0x7fea65ccdb27 in QQmlVMEMetaObject::metaCall(QObject*, 
> QMetaObject::Call, int, void**) () from 
> /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
> No symbol table info available.
> #8  0x7fea65ce4092 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
> No symbol table info available.
> #9  0x7fea65ce132a in QQmlPropertyPrivate::write(QObject*, 
> QQmlPropertyData const&, QVariant const&, QQmlContextData*, 
> QFlags)
> () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
> No symbol table info available.
> #10 0x7fea65c97f7d in 
> QV4::QObjectWrapper::setProperty(QV4::ExecutionEngine*, QObject*, 
> QQmlPropertyData*, QV4::Value const&) ()
>from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
> No symbol table info available.
> #11 0x7fea65c9893e in 
> QV4::QObjectWrapper::setQmlProperty(QV4::ExecutionEngine*, QQmlContextData*, 
> QObject*, QV4::String*, QV4::QObjectWrapper::RevisionMode, QV4::Value const&) 
> () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
> No 

Re: further iterations on the release process and user experience

[Martin Gysel via subsurface]

Am Montag, 15. Januar 2024, 01:34:05 CET schrieb Dirk Hohndel via subsurface:
> Not being able to leave your house, a laptop and internet connection...
> ideal conditions to keep dinking around with stuff :)
> > On Jan 13, 2024, at 10:53, Dirk wrote:
> > 
> > In order to address some of these concerns, I built a new download page
> > and some automation that keeps it updated. This happens with, at a
> > minimum, a 1h time lag so that all binaries show up at the same time;
> > this also gives us some margin of error if we merge something that fails
> > that allows us to not post a release. And of course there's a mechanism
> > to manually point at a different release.
> So this should now be the https://subsurface-divelog.org/latest-release/
> page - clearly showing that this is the Latest CICD Release.
> 
> In addition, there is a https://subsurface-divelog.org/current-release/
> Current Release page. With the goal to iterate this more slowly - maybe
> once a week. And, now that I had the time to figure out how this can work
> (see above), this even links to a SIGNED macOS DMG.
> > Finally, app signing.
> > Given how painful macOS makes it to install unsigned apps, I think I'll
> > need to figure out how to sign at least the "weekly" builds. I doubt that
> > I can truly automate that, but maybe I can figure out a way to keep up
> > with things.
> Done
> 
> > As for Windows - that's a harder problem. The signing mechanisms for
> > Windows are either prohibitively expensive (even with the generous
> > donations from some of you - we are talking around $300-500  a year plus
> > hardware cost (as I would need an actual real Windows machine for this --
> > apparently doing this in a VM no longer works) for what is essentially a
> > blessed random number. The old system that was more affordable
> > (~$100/year) has been killed by Microsoft when they started making
> > additional requirements (including allowing signing certificates only
> > when they are on hardware keys). And as  I mentioned before, I'm seeing a
> > lot more companies release unsigned apps for Windows again. If a better
> > and more realistically priced solution pops up, I'll happily revisit this
> > topic.
> Also, some googling and following countless broken links later... it appears
> there is a not quite as expensive option:
> https://cheapsslsecurity.com/fastssl/code-signing-certificate.html
> 
> With the required hardware token, a three year certificate is about $500
> with shipping - so $170/yr. That is still a lot, but seems more doable. Now
> all I would need is a Windows PC 藍

AFAIK you don't need a windows pc for this. At work, I'm able to sign windows 
apps on my 
linux system using a hardware token. that works just fine.
it's even possible to let more people use that token if you make it available 
over the 
network (usb over it)...

/martin


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