Re: Something's weird with the dive computer parsing in the UDDF import

2024-03-22 Thread Henrik B A via subsurface 
Miika: Are you able to see what's wrong with the import, based on the files
I provided?

Henrik

On Sun, Mar 17, 2024 at 8:04 PM Miika Turkia via subsurface <
subsurface@subsurface-divelog.org> wrote:

> On Sun, Mar 17, 2024 at 8:59 PM Michael Keller via subsurface <
> subsurface@subsurface-divelog.org> wrote:
>
>> Hi Berthold.
>>
>>
>> On 17/03/24 21:16, Berthold Stoeger via subsurface wrote:
>>
>>
>>
>> I reworked quite a bit of the string handling in the parser recently. Did
>>
>> this work with older versions? Especially the dive buddy thing could be
>>
>> a consequence of the rework.
>>
>>
>> UDDF import / export uses XSLT to convert the Subsurface XML to / from
>> UDDF, so the parser / generator used is the same that is used to save and
>> load Subsurface log files - so if this was caused by a bug in the parser
>> then it is strange that this has not been reported already by users trying
>> to load / save log files.
>>
>
> Subsurface's own logs, whether in XML or in git storage, are not going
> through XSLT parsing. The XSLT file used for UDDF import is only used for
> that format, so it is quite limited user base that could face the issue.
> ___
> subsurface mailing list -- subsurface@subsurface-divelog.org
> To unsubscribe send an email to subsurface-le...@subsurface-divelog.org
>
___
subsurface mailing list -- subsurface@subsurface-divelog.org
To unsubscribe send an email to subsurface-le...@subsurface-divelog.org

Re: Something's weird with the dive computer parsing in the UDDF import

2024-03-17 Thread Henrik B A via subsurface 
On Sun, Mar 17, 2024, 09:16 Berthold Stoeger 
wrote:

> Hi Hendrik,
>
> On Samstag, 16. März 2024 10:31:15 CET Henrik B A via subsurface wrote:
>
> > It looks like the dive computer parsing is broken when importing UDDF
> files.
>
> I reworked quite a bit of the string handling in the parser recently. Did
> this work with older versions? Especially the dive buddy thing could be a
> consequence of the rework.
>

I believe the dive computer info was correct the last time I imported, but
that was several months ago

Henrik
___
subsurface mailing list -- subsurface@subsurface-divelog.org
To unsubscribe send an email to subsurface-le...@subsurface-divelog.org

Something's weird with the dive computer parsing in the UDDF import

2024-03-16 Thread Henrik B A via subsurface 
Hi!

It looks like the dive computer parsing is broken when importing UDDF files.

Dive #841 get different computers depending on which other dives it is
grouped with:

https://henrik.synth.no/files/fail.uddf
https://henrik.synth.no/files/fail2.uddf
https://henrik.synth.no/files/fail3.uddf

Additionally, dive buddy shows up as ", Some Name" instead of "Some Name"

Anyways, hope you all have a fantastic weekend and that you're getting a
dive or two.

Cheers,
Henrik
___
subsurface mailing list -- subsurface@subsurface-divelog.org
To unsubscribe send an email to subsurface-le...@subsurface-divelog.org

Large UDDF log file freezes Subsurface 5.0.8 on intel macOS 12.3

2022-03-29 Thread Henrik B A via subsurface 
Hi!

I have a large (75MB, ~1000 dives) UDDF log file exported from MacDive.
When importing this to Subsurface it freezes.  I have tried just letting it
ponder on, but after about 10 minutes I just force-quit the application.

If I export the same dives in the MacDive XML format instead, Subsurface
imports this pretty well.

I can send the file if anyone wants to take a look. Maybe Miika?

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

Re: Sponsoring Subsurface

2022-03-29 Thread Henrik B A via subsurface 
On Tue, Mar 29, 2022 at 1:09 AM Dirk Hohndel via subsurface <
subsurface@subsurface-divelog.org> wrote:

> So this has been a very, very often requested "feature". And I have always
> resisted - for many reasons.
>
> This is great news!

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

Re: MacOS will require programs to be notarised by Apple

2019-07-31 Thread Henrik B A 
On Wed, Jul 31, 2019 at 8:13 AM Dirk Hohndel  wrote:

> I looked into this. It's at the same time not hard and annoyingly painful
> to do :-/
>
> Can someone with the latest macOS try if this shows up as notarized?
>
> https://subsurface-divelog.org/downloads/test/Subsurface-4.9.0-35.dmg
>
> (note - this file is named Subsurface-4.9.0-35.dmg which is different from
> the
> https://subsurface-divelog.org/downloads/test/Subsurface-4.9.0-35-g29f5d15a6692.dmg
> I posted yesterday... this is intentional as I didn't want to break that
> test binary from yesterday by mistake... the one WITH the -g29f5d15a6692
> should be NOT notarized. The one with the shorter name without the SHA
> should BE notarized)
>
>
This looks helpful:
https://eclecticlight.co/2019/07/02/checking-whether-apps-are-notarized-using-signet/


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

Re: Facebook and Subsurface

2019-07-31 Thread Henrik B A 
On Wed, Jul 31, 2019 at 1:20 AM Dirk Hohndel  wrote:

> On Tue, Jul 30, 2019 at 11:25:42PM +0200, Robert Helling wrote:
> >
> > PS: When it comes to web forums for divers, I believe that for some
> time, scuba board is by far the most useful for divers. I look there
> regularly and have a notification set so I get an email once anybody
> mentions the word „subsurface“. Other programmers (like diving log or pasta
> deco) advertise new versions there. But I don’t know how useful that is.
> What I can see is that happy subsurface users advertise our program when
> the occasion comes up and others ask what software to use or how to solve
> problem x (for example dive planning).
>
> I keep forgetting to post on scubaboard. Grmbl. I knew that. Somehow I
> need to add this to my release workflow.
>

https://www.thediveforum.com is also a pretty active forum for divers.

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

Re: Information tab in desktop version

2019-04-18 Thread Henrik B A 
On Wed, Apr 17, 2019, 21:04 Doug Junkins  wrote:

> It is not clear to me why atmospheric pressure and dive mode were chosen
> as special fields that get added to the location label on the Notes tab as
> opposed to other fields like water and air temperature. Are those really
> the most important fields for the majority of Subsurface users to be
> treated uniquely? I am not sure the Location label should be overloaded to
> display these other fields, to be honest.
>

I agree, this doesn't seem relevant for most users.

Henrik

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

Re: Moving Divesites from One User to Another

2019-04-08 Thread Henrik B A 
On Mon, Apr 8, 2019 at 3:42 AM Michael Newman 
wrote:

> Well, this was a huge failure. I edited her xml file to include all 80
> dive sites that are in my ssrf file. The first time I opened her xml file
> in Subsurface, all those dive sites were there. I was able to add dive site
> locations to a few of her dives without entering the name and coordinates
> manually.
>
> But, once I saved the changes, Subsurface deleted all of the dive sites
> that were not actually her dives. So, instead of 80 dive sites her xml file
> now has only three.
>

Yes, this has been a serious problem with Subsurface since the start, since
dive sites aren't treated as first class citizens. Dive sites just
disappear if you happen to not have it linked to a dive :(

There is work underway to revamp the whole dive site database logic,
though, so there's hope that even I can use Subsurface as my main dive
logging software some time in the future.  Really looking forward to it! :)

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

Re: dive site handling

2019-02-24 Thread Henrik B A 
On Sun, Feb 24, 2019 at 8:40 PM Dirk Hohndel  wrote:

> Would those be referenced by planned dives? Or do you really mean
> "unreferenced", i.e. you create a dive site, save the dive file and quit
> the app, and then later add a dive at that site?
> Just making sure I understand the model you are proposing.
>

Create a dive site, quit the app, do a dive, log it, attach it the dive
site to the dive.   Nothing related to the "dive planner" as such.This
is part of what I mean with dive sites as a first class citizen.

I might even research some dive sites weeks or months before a trip, and
then use that as a base for navigating to the dive sites when I get there
to go diving.


> The issue with not pruning unreferenced dive sites is that over time you
> might accrue a lot of garbage in your dive file. E.g., whenever you dive
> with a Garmin Descent or similar dive computer (there are none right now)
> that store GPS data, that creates a new dive site. Typically I then switch
> to the existing one if I have been at this site before, which creates an
> unreferenced site. Having all of those accumulate over time might be
> annoying.
>

I see the point, but as of now very few dive computers have  that feature.
After a basic, simple dive site database is in  place, we can use that to
suggest (or automatically choose) the correct dive site for the user based
on GPS position.

Henrik

(Resending, I first sent this only to Dirk)
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: dive site handling

2019-02-24 Thread Henrik B A 
On Sun, Feb 24, 2019 at 9:20 PM Berthold Stoeger 
wrote:

> One could have a "prune unused dive sites" button. And for GPS-enabled
> dive
> computer users an "auto-prune unused dive sites" option.
>

Good idea!


> To me it seems somewhat questionable to create a new dive site for every
> new
> GPS location anyway. Perhaps detach these two things?
>

I agree, good thinking.

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

Re: dive site handling

2019-02-24 Thread Henrik B A 
On Sun, Feb 24, 2019, 15:34 Willem Ferguson 
wrote:

> On 2019/02/24 16:16, Henrik B A wrote:
> >
> > An online shared DB could be nice as well, but that's a completely
> > different beast IMHO. Also, many sites aren't shareable: They could be
> > on private ground, or be secret (risk of artifact theft etc).
>
> Hi Henrik,
>
> This is a good start. Now, which features and/or facilities should the
> dive site info in a private cloud have?
>


Oh, I am just referring to the regular online cloud backup at
cloud.subsurface-divelog.org. So it would not be any different from the
local XML.

Henrik

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

Re: dive site handling

2019-02-24 Thread Henrik B A 
On Sat, Feb 23, 2019, 23:16 Robert Helling  wrote:

>  But what I was hoping for was that the Subsurface users could create
> their own database: Sharing logbook entries has a lot of privacy issues but
> I think many of our users would be willing to share dive site information
> they collect if they can participate from this data. If we could implement
> this I think it would be really cool. Many details would have to be worked
> out (how to deal with languages, which fields would we share, coordinates,
> names, notes?)
>

For the initial rework, let's just keep it easy and simple, each user with
his/her own dive sites in the local XML (or private cloud obviously).

An online shared DB could be nice as well, but that's a completely
different beast IMHO. Also, many sites aren't shareable: They could be on
private ground, or be secret (risk of artifact theft etc).

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

Re: dive site handling

2019-02-24 Thread Henrik B A 
On Sat, Feb 23, 2019 at 6:32 PM Dirk Hohndel  wrote:

> I believe Henrik's proposal pre-dated us adding the country field. I see
> no reason to remove the country field.
>

No, my initial propose had Site name, Location and Country.  But I got so
much opposition from even mentioning anything resembling a taxonomy, so my
proposal (that you pasted in the OP)  is stripped down dive site database
proposal with only Site name & GPS.  It is a bare bones thing that all
other fanciness could build upon :)

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

Re: dive site handling

2019-02-24 Thread Henrik B A 
On Sat, Feb 23, 2019 at 6:31 PM Dirk Hohndel  wrote:

> Unreferenced dive sites should not be stored when saving data. But the
> user can of course create multiple, redundant dive sites when doing
> multiple dives at the same site.
>

Hm, I believe we should be able to have unreferenced dive sites in our
database. E.g. for planning purposes.

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

Re: dive site handling

2019-02-24 Thread Henrik B A 
On Sat, Feb 23, 2019 at 10:21 AM Willem Ferguson <
willemfergu...@zoology.up.ac.za> wrote:

> 1) I have never been convinced that writing the dive locations into the
> dive log XML is the best solution.
>

I disagree.  The  XML is an excellent location for the dive sites, it makes
sharing and handling the log so much easier.


> 2) One should be able to do dive site management when there is no Internet
> access.
>

Solved by having it all in the same XML file.

> 3) If there is a local database of dive sites on my computer, does this
> get backed up on the cloud in the same way as the dive log? What would the
> recovery options be if I lost my local dive site data?
>
If the dive sites live together with your dives, there is no problem.

> 3) I have on occasion used Internet-based information about dive sites,
> but these databases never included my dive sites and therefore has not been
> very useful.
>
Once in a while I've been able to find info about certain dive spots that
have been interesting when planning new dives, but I haven't felt the need
to connect this to Subsurface (or in my case, MacDive).  I have just copied
the relevant info (gps, how to get there etc) over to MacDive.

> I would love to hear the opinion of divers (such as Henrik) who use dive
> site databases more extensively.
>
I don't, so I haven't got much to tell, I'm afraid :)

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

Re: dive site handling

2019-02-24 Thread Henrik B A 
On Fri, Feb 22, 2019 at 9:37 PM Dirk Hohndel  wrote:

> One of the many threads we had on this is archived here (and yeah, the
> list archive is a bit painful...)
> http://lists.subsurface-divelog.org/pipermail/subsurface/2016-April/025412.html
> In that thread I pushed back hard on Henrik's idea for reasons that I'm
> sure I felt strongly about back then (I am not subtle...). Reading this
> again nearly three years later... I don't think I called that one
> correctly. So ignore my push back and let's start with Henrik's design idea.
>

Thanks! I think that was the final straw that made me give up contributing
to Subsurface.  No hard feelings, though, it's all water under the bridge.
I'm excited that a proper dive site database is been given a second (third?
fourth?) chance :)

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

Re: New icons

2018-06-04 Thread Henrik B A 
On Mon, Jun 4, 2018, 19:44 Dirk Hohndel  wrote:

>
> I will admit that I feel many of the new icons aren't as nice as the old
> ones.
> They feel "blocky" and "old" to me.
> Obviously I'm not a graphic designer and I'll be the first to admit that
> I'd have
> ZERO talent to do any better - but after coming back to this email and the
> screen shots a few times... I'm not in love with the new look.
>

I wanted to chime in here as well. Unification of icon names and other
changes here: very cool. Should be put in a separate PR.

But many of the new icons feels bulky, cluttered, and less clean. E.g. the
he/O2/n icons have some arrows (?) in the corners that I don't understand.

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

Re: Formatting Dive tags string

2018-04-06 Thread Henrik B A 
On Thu, Apr 5, 2018 at 11:29 PM, Berthold Stoeger <
bstoe...@mail.tuwien.ac.at> wrote:

>
> I'm disappointed to learn that git only does 7-bit ASCII tags...? ☹
>

You shouldn't be.  It does:

$ git tag øl
$ git tag 
$ git tag
øl


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

Re: Subsurface as a Snap?

2017-12-21 Thread Henrik B A 
On Thu, Dec 21, 2017 at 3:39 PM, Dirk Hohndel  wrote:

> Snap and Flatpak both are different takes on what we already have with
> AppImage.
> The goal of AppImage was to have fewer builds to worry about. And it
> brilliantly does that.
> So unless there is something that is a) better and b) completely replaces
> AppImage, I'm
> not sure why we'd spend time on it.
>

It was just a thought.  With Ubuntu (and others) embracing Snap, and with
all major distributions supported, and a central package repository
available, it might reach a larger user base and be easier to support.  I
obviously base this conclusion on absolutely nothing :D

Happy holidays!

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

Subsurface as a Snap?

2017-12-21 Thread Henrik B A 
Has anyone looked into how feasible it would be to build Subsurface as a
Snap?  It would be an alternative to the AppImage.

Ref. https://docs.snapcraft.io/build-snaps/c

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

Re: lots of activity

2017-11-26 Thread Henrik B A 
On Sun, Nov 26, 2017 at 1:13 AM, Dirk Hohndel  wrote:

> For those not subscribed to the changes on GitHub, a lot is going on.
> Berthold, Lubomir, Jan, and Stefan are all on a role. 72 commits from the
> four of them in two weeks.
> In the meantime Anton and I reworked our Travis CI support. We now have
> continuous builds of all of our platforms for every PR as well as every
> merge / push. Including Android and Mac (both of those are unsigned which
> makes them slightly harder to use).
>

This is such good news!  Fantastic work everyone!

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

Re: Subsurface-mobile with BT and BLE support [was Re: updates to libdc with ABI change]

2017-06-30 Thread Henrik B A 
On Fri, Jun 30, 2017 at 10:37 AM, Davide DB  wrote:

> So I got lost among all the hectic activities on BT/BLE download.
> What's the latest apk to play with?
>

Pick the latest from http://subsurface-divelog.org/downloads/test/

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

Re: [PATCH 2/2] Add a travis build of subsurface

2017-02-06 Thread Henrik B A 
Fantastic work Anton.  This is a great step forward :)

Henrik

On Sun, Feb 5, 2017 at 11:26 PM, Anton Lundin  wrote:
> This runs a subsurface script/build.sh build in travis-ci, and runs the
> tests afterwards.
>
> The build runs on the Ubuntu Trusty image, but due to the fact that the
> Qt shipped there is to old, it installs a Qt 5.8 from qt.io , and with
> some trickery caches it.
>
> Hacked out are things that doesn't build with Qt 5.8, and the rest is
> built against WebEngine.
>
> The tests currently fail, and I really don't know why, but its a clear
> indication that they aren't run that often. This cam makes sure they are
> run at least. The actual testing is just commented out for that reason.
>
> Signed-off-by: Anton Lundin 
> ---
>  .travis.yml| 47 +
>  qt-installer-noninteractive.qs | 60 
> ++
>  2 files changed, 107 insertions(+)
>  create mode 100644 .travis.yml
>  create mode 100644 qt-installer-noninteractive.qs
>
> diff --git a/.travis.yml b/.travis.yml
> new file mode 100644
> index 000..6240ffe
> --- /dev/null
> +++ b/.travis.yml
> @@ -0,0 +1,47 @@
> +language: c++
> +
> +dist: trusty
> +
> +cache:
> +directories:
> +- Qt
> +
> +addons:
> +apt:
> +packages:
> +- git
> +- g++
> +- make
> +- autoconf
> +- automake
> +- libtool
> +- cmake
> +- pkg-config
> +- libxml2-dev
> +- libxslt1-dev
> +- libzip-dev
> +- libsqlite3-dev
> +- libusb-1.0-0-dev
> +- libssl-dev
> +- libssh2-1-dev
> +- libcurl4-openssl-dev
> +# Not a subsurface dependency, but a Qt dependency
> +- mesa-common-dev
> +
> +before_install:
> +- if [ ! -e Qt/5.8 ] ; then
> +  rm -rf Qt ;
> +  wget 
> http://download.qt.io/official_releases/qt/5.8/5.8.0/qt-opensource-linux-x64-android-5.8.0.run
>  ;
> +  chmod +x ./qt-opensource-linux-x64-android-5.8.0.run ;
> +  ./qt-opensource-linux-x64-android-5.8.0.run -platform minimal 
> --script qt-installer-noninteractive.qs --no-force-installations ;
> +  fi
> +
> +script:
> +- perl -pi -e 's/BUILDGRANTLEE=1/BUILDGRANTLEE=0/' scripts/build.sh
> +- perl -pi -e 's/BUILDMARBLE=1/BUILDMARBLE=0/' scripts/build.sh
> +- perl -pi -e 's/-DNO_PRINTING=OFF/-DNO_PRINTING=ON -DNO_MARBLE=ON 
> -DUSE_WEBENGINE=ON/' scripts/build.sh
> +- export CMAKE_PREFIX_PATH=$PWD/Qt/5.8/gcc_64/lib/cmake ;
> +  cd .. ;
> +  bash -e ./subsurface/scripts/build.sh
> +#- cd subsurface/build ; env CTEST_OUTPUT_ON_FAILURE=1 make check
> +#- cd subsurface/build-mobile ; env CTEST_OUTPUT_ON_FAILURE=1 make check
> diff --git a/qt-installer-noninteractive.qs b/qt-installer-noninteractive.qs
> new file mode 100644
> index 000..b6c6c2a
> --- /dev/null
> +++ b/qt-installer-noninteractive.qs
> @@ -0,0 +1,60 @@
> +// http://stackoverflow.com/a/34032216/78204
> +
> +function Controller() {
> +installer.autoRejectMessageBoxes();
> +installer.setMessageBoxAutomaticAnswer("OverwriteTargetDirectory", 
> QMessageBox.Yes);
> +installer.installationFinished.connect(function() {
> +gui.clickButton(buttons.NextButton);
> +})
> +}
> +
> +Controller.prototype.WelcomePageCallback = function() {
> +gui.clickButton(buttons.NextButton);
> +}
> +
> +Controller.prototype.CredentialsPageCallback = function() {
> +gui.clickButton(buttons.NextButton);
> +}
> +
> +Controller.prototype.IntroductionPageCallback = function() {
> +gui.clickButton(buttons.NextButton);
> +}
> +
> +Controller.prototype.TargetDirectoryPageCallback = function()
> +{
> +
> //gui.currentPageWidget().TargetDirectoryLineEdit.setText(installer.value("HomeDir")
>  + "/Qt");
> +
> gui.currentPageWidget().TargetDirectoryLineEdit.setText(installer.value("InstallerDirPath")
>  + "/Qt");
> +//gui.currentPageWidget().TargetDirectoryLineEdit.setText("/scratch/Qt");
> +gui.clickButton(buttons.NextButton);
> +}
> +
> +Controller.prototype.ComponentSelectionPageCallback = function() {
> +var widget = gui.currentPageWidget();
> +
> +widget.selectAll();
> +widget.deselectComponent('qt.58.src');
> +
> +gui.clickButton(buttons.NextButton);
> +}
> +
> +Controller.prototype.LicenseAgreementPageCallback = function() {
> +gui.currentPageWidget().AcceptLicenseRadioButton.setChecked(true);
> +gui.clickButton(buttons.NextButton);
> +}
> +
> +Controller.prototype.StartMenuDirectoryPageCallback = function() {
> +gui.clickButton(buttons.NextButton);
> +}
> +
> +Controller.prototype.ReadyForInstallationPageCallback = function()
> +{
> +gui.clickButton(buttons.NextButton);
> +}
> +
> +Controller.prototype.FinishedPageCallback = function() {
> +var checkBoxForm =

Re: New Subsurface-mobile Beta for Android [was: Re: Subsurface 4.7 / 5.0]

2017-01-22 Thread Henrik B A 
On Sun, Jan 22, 2017 at 12:58 AM, Dirk Hohndel  wrote:
> On Sat, Jan 21, 2017 at 02:21:43PM -0800, Dirk Hohndel wrote:
>>
>> Here's my plan for right now. Fix things so we go back to Kirigami 1.
>> See if I can build a working Android APK. Once I have that, check where
>> we are with an iOS package.
>
> A new Android APK has been pushed to BETA on Google Play and is also
> available in downloads/daily.

Thanks a lot for your work on this!  Having the possibility of
checking out older dives and dive sites on the go is super useful, so
I really hope we don't abandon this.

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

Re: Request for information for user manual: SmartTrac

2017-01-05 Thread Henrik B A 
On Thu, Jan 5, 2017 at 1:02 PM, Robert Helling  wrote:
> Hi,
>
> On 05 Jan 2017, at 10:17, Willem Ferguson 
> wrote:
>
> Does anyone have any information about this? It is listed as a new feature
> of Subsurface V4.6 Beta V1.
>
>
> you get a bit of information by doing
>
> git log
>
> and then
>  /[to get into search mode]SmartTrac

GitHub is also helpful:

https://github.com/Subsurface-divelog/subsurface/search?q=SmartTrak=Commits=✓

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

Re: Using GitHub

2017-01-05 Thread Henrik B A 
On Thu, Jan 5, 2017 at 7:29 AM, Willem Ferguson
 wrote:
> For those not familiar with GitHub, is it possible to write a brief text on
> how to use GitHub for Subsurface?
>
> How does one submit a patch? Does one have to do the edits online within
> GitHub inside a browser or can one upload files with changes? The tutorial
> is not clear.

Just use GitHub's excellent documentation:
https://help.github.com/articles/creating-a-pull-request/

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

Re: [torvalds/subsurface] QWebEngine and fix for images from web (#128)

2017-01-01 Thread Henrik B A 
On Sun, Jan 1, 2017 at 11:24 AM, Tomaz Canabrava  wrote:

>
> On Sun, Jan 1, 2017 at 10:58 AM, Robert Helling 
> wrote:
>>
>> On 01 Jan 2017, at 10:26, Robert C. Helling 
>> wrote:
>>
>> Sure I could do that. But my "legacy" point is that there are many forks
>> of Linus' repository. So you will be sending people this mail a few times
>> in the future.
>>
>>
>> Just compare
>>
>> https://github.com/Subsurface-divelog/subsurface/network/members
>>
>> to
>>
>> https://github.com/dirkhh/subsurface/network/members
>>
>
> True, as I'm also one f the members of torvalds, but considering that
> subsurface-develop is a new repo on github, I don't see any problems
> let's remember that we have around 10 active developers so the number of
> members there doesn't really matter.
>

It seems that it's actually possible to transfer a repo (while creating
redirects and maintaining forks/users/stars!)  from one user/organization
to another: https://github.com/blog/1508-repository-redirects-are-here

So a solution might be for Dirk to delete Subsurface-divelog/subsurface and
transfer torvalds/subsurface in its place.

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

Re: [torvalds/subsurface] QWebEngine and fix for images from web (#128)

2016-12-31 Thread Henrik B A 
31. des. 2016 08.54 skrev "Robert Helling" :


will do.

Maybe someone knows (i haven’t been able to quickly find an answer): My
github repository of subsurface was cloned from Linus’ a long time ago.
When I try to create a pull request on the github webpage, I cannot do it
relative to Subsurface-divelog/subsurface as Github is not aware of it
being related to torvalds/subsurface. How do I tell Github about that
connection?



Just delete your existing github repo and fork the new one.  Your local
repo will point to the new one if it has the same name.

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

Re: Beta announcement

2016-12-30 Thread Henrik B A 
On Fri, Dec 30, 2016 at 2:46 PM, Henrik B A <hen...@synth.no> wrote:
> On Thu, Dec 29, 2016 at 9:29 PM, Dirk Hohndel <d...@hohndel.org> wrote:
>>
>> Pull requests with updates welcome
>
> https://github.com/Subsurface-divelog/subsurface doesn't seem to get
> updated, but https://github.com/torvalds/subsurface already has
> several PRs.  Which should we use?

Oops, those PRs were ancient.  Should maybe be closed & removed?

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

Re: Beta announcement

2016-12-30 Thread Henrik B A 
On Thu, Dec 29, 2016 at 9:29 PM, Dirk Hohndel  wrote:
>
> Pull requests with updates welcome

https://github.com/Subsurface-divelog/subsurface doesn't seem to get
updated, but https://github.com/torvalds/subsurface already has
several PRs.  Which should we use?

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

Re: Beta announcement

2016-12-29 Thread Henrik B A 
29. des. 2016 17.59 skrev "Dirk Hohndel" :

I will give up on trac as bug tracker and use github issues. And I will
encourage people
to send me pull requests instead of sending patches.

github.com/Subsurface-divelog/subsurface

This needs work, of course. Changes to the Readme, changes to our web site,
lots of
stuff. But since you brought it up, yes, that's where I'm going.


Nice!

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