Re: Scubapro/Uwatec Smartrak .slg files importing tool

[Robert C. Helling]

Hi,

> Am 13.11.2015 um 00:12 schrieb Salvador Cuñat :
> 
> As I'm not a QT guy, I'm coppying Tomaz in this mail, he will probably have a 
> solution.

I had the same problem on my Mac. I guess there is something missing in the 
cmake file. But not being able to do that I manually called uic on the 
corresponding .ui file and piped the output to a .h file in the include 
directory. 

Sorry, I am on a phone and don't have the specifics here. 

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

Re: [PATCH] mobile: divedetails page etc. improvements

[Lubomir I. Ivanov]

On 13 November 2015 at 05:56, Linus Torvalds
 wrote:
>
> On Nov 12, 2015 19:34, "Dirk Hohndel"  wrote:
>>
>>> On Nov 12, 2015, at 3:12 PM, Lubomir I. Ivanov 
>>> wrote:
>>>
>>> so here is the visual of the working POC:
>>>
>>> https://dl.dropboxusercontent.com/u/1627980/subsurface/mobile_dive_details_concept2.gif
>>
>> This is really cool - I especially like the beautiful rendering of the
>> dive profile :-)
>
> I never even knew before this masterpiece that I needed sharks in my
> profile. But now that I have seen them, nothing else will ever do.
>
> The only question in my mind is whether just one shark per profile is
> enough, or if we need more.
>

petition to enable creature icons in the profile!

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

Re: [PATCH] mobile: divedetails page etc. improvements

[Lubomir I. Ivanov]

On 13 November 2015 at 05:34, Dirk Hohndel  wrote:
>
> On Nov 12, 2015, at 3:12 PM, Lubomir I. Ivanov  wrote:
> alright...
>
> so here is the visual of the working POC:
> https://dl.dropboxusercontent.com/u/1627980/subsurface/mobile_dive_details_concept2.gif
>
>
> This is really cool - I especially like the beautiful rendering of the dive
> profile :-)
>

people don't believe me that i entered university with math and drawing exams.
sometimes i just "switch" to draw like a 5 y/o. ;-D

> I'll have to admit that the amount of activity on Subsurface-mobile
> makes me smile. I really hoped that a few people here would get
> into the idea of making a mobile app happen and would collaborate.
> We need more people working on our UIs (both DT and mobile).

i may eventually prepare an Android build setup here and see if i can
help with the mobile version some more.
ATM i'm just throwing ideas at Sebastian as i can't build our QMLs.

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

Re: Mac OSX SHEARWATER problems,

[Lubomir I. Ivanov]

On 13 November 2015 at 07:43, Willem Ferguson
 wrote:
> abort() called
> *** error for object 0x6008edd0: pointer being freed was not allocated
>
>
> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
> 0   libsystem_kernel.dylib 0x7fff92e95286 __pthread_kill + 10
> 1   libsystem_c.dylib 0x7fff861209b3 abort + 129
> 2   libsystem_malloc.dylib 0x7fff8bf721cb free + 428
> 3   org.subsurface-divelog 0x000101478794 free_prefs + 20
> 4   org.subsurface-divelog 0x0001011efe8d main + 2301
> 5   org.subsurface-divelog 0x0001011ef584 start + 52
>

the report is obvious, but on a quick look @ the source i can't pin
point the exect free() call which is the problem one.
all preferences seem to be allocated with with string_copy() and if a
preference is NULL free() should not be a problem.

i can't debug that on Win32, because my fake console exits too early.
the proposed patch is the following: make free_prefs() a NOP, until we
refactor the global preferences.
the one-time leaks won't do much harm.

patch attached.

lubomir
--

P.S. if someone has means to debug this properly, please go ahead.
From 98aa3a78f7b10d4a95cc83cecb5af151eecbcda0 Mon Sep 17 00:00:00 2001
From: "Lubomir I. Ivanov" 
Date: Fri, 13 Nov 2015 15:20:48 +0200
Subject: [PATCH] subsurfacestartup.c: leave free_prefs() empty

There is a bug on OSX where free() is called on non-allocated
memory in free_prefs(). Most of the preferences are not freed
in free_prefs() while copy_string() is used on them, so let's
not free() any pointers in free_prefs() and leave them
as one-time leaks.

Signed-off-by: Lubomir I. Ivanov 
--
a "free of non-allocated pointer" was reported by Willem on
OSX. i can't debug that on Windows because the console here
exits before free_prefs() is even reached.

overall this change is harmless.

Tomaz did say that he has plans to remove the global prefs struct
at some point.
---
 subsurface-core/subsurfacestartup.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/subsurface-core/subsurfacestartup.c b/subsurface-core/subsurfacestartup.c
index 13cbbfa..8656f3f 100644
--- a/subsurface-core/subsurfacestartup.c
+++ b/subsurface-core/subsurfacestartup.c
@@ -311,11 +311,5 @@ void copy_prefs(struct preferences *src, struct preferences *dest)
  */
 void free_prefs(void)
 {
-	free((void*)prefs.default_cylinder);
-	free((void*)prefs.divelist_font);
-	free((void*)prefs.cloud_storage_password);
-	free(prefs.proxy_host);
-	free(prefs.proxy_user);
-	free(prefs.proxy_pass);
-	free(prefs.userid);
+	// nop
 }
-- 
1.7.11.msysgit.0

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

Re: Scubapro/Uwatec Smartrak .slg files importing tool

[Dirk Hohndel]

> On Nov 13, 2015, at 12:02 AM, Robert C. Helling  
> wrote:
> 
> Hi,
> 
>> Am 13.11.2015 um 00:12 schrieb Salvador Cuñat :
>> 
>> As I'm not a QT guy, I'm coppying Tomaz in this mail, he will probably have 
>> a solution.
> 
> I had the same problem on my Mac. I guess there is something missing in the 
> cmake file. But not being able to do that I manually called uic on the 
> corresponding .ui file and piped the output to a .h file in the include 
> directory. 

Tomaz ended up changing the way that uic is run in one of the most recent 
patches... we now need to explicitly call it (this used to be automatic but the 
automatic mechanism failed at times and caused build failures so he switched to 
manual mode)

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

Working on the QML UI [was: Re: [PATCH] mobile: divedetails page etc. improvements]

[Dirk Hohndel]

> On Nov 13, 2015, at 4:45 AM, Lubomir I. Ivanov  wrote:
> 
> On 13 November 2015 at 05:34, Dirk Hohndel  wrote:
>> 
>> On Nov 12, 2015, at 3:12 PM, Lubomir I. Ivanov  wrote:
>> alright...
>> 
>> so here is the visual of the working POC:
>> https://dl.dropboxusercontent.com/u/1627980/subsurface/mobile_dive_details_concept2.gif
>> 
>> 
>> This is really cool - I especially like the beautiful rendering of the dive
>> profile :-)
>> 
> 
> people don't believe me that i entered university with math and drawing exams.
> sometimes i just "switch" to draw like a 5 y/o. ;-D

I can draw like a 5y/o with the best of them!

>> I'll have to admit that the amount of activity on Subsurface-mobile
>> makes me smile. I really hoped that a few people here would get
>> into the idea of making a mobile app happen and would collaborate.
>> We need more people working on our UIs (both DT and mobile).
> 
> i may eventually prepare an Android build setup here and see if i can
> help with the mobile version some more.
> ATM i'm just throwing ideas at Sebastian as i can't build our QMLs.

I cannot stress enough how much I think we need more people
working on the mobile app. So by all means, PLEASE do that!
Having Sebastian be the single developer (just like Tomaz is
usually the single developer for the desktop UI) is just not a
good way to do this.

I have tried to talk a few other external people into this
(Hi Stephen) and am still hoping that we'll get more people
contributing to Subsurface-mobile this way, but I would like
to really encourage everyone here to please play with the
QML.

And oh btw - you can quite easily test the QML on the desktop.
Simply enable SUBSURFACE_MOBILE in the cmake (easily
done with ccmake ) and you can build subsurface-mobile
on your Linux box (yeah, I know you're usually on Windows, 
Lubomir, but I also know you have a Linux VM somewhere). 
And then you can work on the QML code and test it quite efficiently.

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

[PATCH] SmartTrak import - Add building out of source tree

[Salvador Cuñat]

Enables auto uic in smtk-import directory and sets
CMAKE_INCLUDE_CURRENT_DIR to ON

Signed-off-by: Salvador Cuñat 
---
 smtk-import/CMakeLists.txt | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/smtk-import/CMakeLists.txt b/smtk-import/CMakeLists.txt
index 93fbb84..c49eeac 100644
--- a/smtk-import/CMakeLists.txt
+++ b/smtk-import/CMakeLists.txt
@@ -1,10 +1,12 @@
+set(CMAKE_AUTOUIC ON)
+set(CMAKE_INCLUDE_CURRENT_DIR ON)
 set(SMTK_IMPORT_SRCS
smartrak.c
smrtk2ssrfc_window.ui
smrtk2ssrfc_window.h
smrtk2ssrfc_window.cpp
 )
-source_group("SmartTrak Import libs" FILES ${SMTK_IMPORT_SRCS})
 
+source_group("SmartTrak Import libs" FILES ${SMTK_IMPORT_SRCS})
 add_library(smtk_import STATIC ${SMTK_IMPORT_SRCS})
 target_link_libraries(smtk_import subsurface_corelib 
${SUBSURFACE_LINK_LIBRARIES})
-- 
2.6.2

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

Re: Scubapro/Uwatec Smartrak .slg files importing tool

[Salvador Cuñat]

Good evening.

2015-11-13 16:00 GMT+01:00 Dirk Hohndel :

>
> > On Nov 13, 2015, at 12:02 AM, Robert C. Helling <
> rob...@euve10195.vserver.de> wrote:
> >
> > I had the same problem on my Mac. I guess there is something missing in
> the cmake file. But not being able to do that I manually called uic on the
> corresponding .ui file and piped the output to a .h file in the include
> directory.
>
> Tomaz ended up changing the way that uic is run in one of the most recent
> patches... we now need to explicitly call it (this used to be automatic but
> the automatic mechanism failed at times and caused build failures so he
> switched to manual mode)
>
>
That it was.  Patch sent.
Pedro, would you be so kind to give it a try after applying the patch ?

Regards.

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

Re: Scubapro/Uwatec Smartrak .slg files importing tool

[Pedro Neves]

On 13-11-2015 18:30, Salvador Cuñat wrote:


Pedro, would you be so kind to give it a try after applying the patch ?




Will do. I'll get back to you ASAP.

Cheers:

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

Re: Scubapro/Uwatec Smartrak .slg files importing tool

[Pedro Neves]

On 13-11-2015 18:30, Salvador Cuñat wrote:

Pedro, would you be so kind to give it a try after applying the patch ?




Salva:

It's works just fine. After aplying the patch it builds and I can 
sucessfully convert some old files.

I'll test a few more later on.

All the best and thanks for your work.

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

Re: Scubapro/Uwatec Smartrak .slg files importing tool

[Salvador Cuñat]

Hi Pedro.

2015-11-13 19:44 GMT+01:00 Pedro Neves :

>
> It's works just fine. After aplying the patch it builds and I can
> sucessfully convert some old files.
> I'll test a few more later on.
>
> All the best and thanks for your work.
>
>
Thanks for testing it.
Remember to use new files for the import.  You can then import the  .xml to
your actual log.

BTW, I have had problems while renumbering a big number of dives.  There is
no problem with little numbers, but big ones seem to hang Subsurface, at
least in my good old 32 bits machine.  I was thinking about take a look at
the renumbering algorithm.

Regards.

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

Re: Subsurface website banner

[Joakim Bygdell]

> On 13 Nov 2015, at 01:29, Salvador Cuñat  wrote:
> 
> Good night.
> 
> I also like the banner idea (and Willem's daughter guidelines), *but*,  I 
> like actual simplicity in color and shape too.  I mean, the photo in the 
> banner should have a much paler background to reduce the contrast with the 
> rest of the page and don't keep calling attention on it.  Perhaps blurring 
> the sides until moltening with the background of the page will also help.

I agree with you Salva, the black portion of the right hand side of the image 
should not exist.
Rather the image should start to fade where the blue-black border is to white.
Going from the darkest point at the far left to fully blend in to the 
background after something like 75% of the image width to the right.
Basically, Corall - diver - blue water -> white backgound

> 
> Just  an opinion from someone with the same artistic sensibility than a 
> beduin spadrille.
> 
> Regards
> 
> Salva.
> 
> 
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

/Jocke

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

Re: [PATCH] mobile: divedetails page etc. improvements

[Joakim Bygdell]

> On 12 Nov 2015, at 13:22, Sebastian Kügler  wrote:
> 
> On Wednesday, November 11, 2015 20:45:53 Dirk Hohndel wrote:
>> On Thu, Nov 12, 2015 at 01:27:54AM +, Sebastian Kügler wrote:
>>> Heya,
>>> 
>>> Some more work on the mobile version, especially on the divelist and 
> details.
>> 
>> Great!
>> 
>>> - bugfix for label overflow in dive list
>>> - don't create the expensive profilewidget for every frame painted by the 
> item
>>> - kill warnings due to conditional build of subsurface-mobile (#0006)
>>> - other cleanups (#0001, #0003)
>>> - further layout and styling improvements (all the other patches)
>> 
>> It's coming along. How hard will it be to swipe sideways from dive to dive
>> when in dive detail mode? So I tap on one of the dives and I just swipe
>> left and right to get to the previous / next dive instead of having to go
>> back to the dive list between dives?
> 
> Not entirely trivial as the dives are currently not items next to each other. 
> Adding previous/next in general shouldn't be too hard, and we could hook it 
> up 
> to swipe gestures, but it won't look completely natural since we're not 
> having 
> dives as separate items next to each other. I'll give it some more thinking.
> 
>>> Most visible is probably the rework of the dive profile page, aside various 
> text
>>> display fixes.
>> 
>> Yes, this looks nice. Just the profile needs more work. Lubomir and Tomaz
>> are most likely able to help you with the magic of making that work
>> better.
> 
> I'll check with them to explain the rendering to me. Ideally, the graph 
> should 
> be rendered at exactly the resolution we want it in, so we get smooth fonts. 
> Sizing already seems a bit better, thought I can't say exactly which of the 
> changes brought that about.

Another thing is that the canvas should be aware of the width of the screen, 
right now you only see the left hand portion of the profile.


> 
>> I took the patches as submitted, including the CloudStorage.qml - you can
>> just update that in your next series. That seemed easier than asking you
>> to refactor and resubmit - I really want to keep the momentum going...
> 
> Thanks, appreciate it.
> 
>> As you have noticed I'm adding the location service to Subsurface-mobile
>> so that we can drop the companion apps and have it all integrated into one
>> app...
> 
> Very cool.
> 
> -- 
> sebas
> 
> Sebastian Kügler|http://vizZzion.org | 
> http://kde.org 
> 
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org 
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface 
> 
/Jocke

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

Re: Scubapro/Uwatec Smartrak .slg files importing tool

[Pedro Neves]

On 13-11-2015 18:54, Salvador Cuñat wrote:


Thanks for testing it.

No worries.
You know, one of the things I've found really interesting is the fact 
that all the bookmarks are imported from the slg files.
I wish libdivecomputer did the same when downloading dives from my 
Uwatecs into Subsurface, as the bookmarks are something I use a lot on 
my work.


Take care:

Pedro


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

Re: Scubapro/Uwatec Smartrak .slg files importing tool

[Salvador Cuñat]

2015-11-13 21:01 GMT+01:00 Pedro Neves :

>
> You know, one of the things I've found really interesting is the fact that
> all the bookmarks are imported from the slg files.
> I wish libdivecomputer did the same when downloading dives from my Uwatecs
> into Subsurface, as the bookmarks are something I use a lot on my work.
>
>
H,  if you are diving a Galileo,  I'm not sure that all of them are
your bookmarks.
Profile import is done via libdivecomputer and, actually, it can't
distinguish between a bookmark, an ascent alarm  or the safety stop
countdown triggered at 5m deep.  So, yes, they are your bookmarks a many
other unrelated things  :-)

What I haven't still figured out how to manage, are those fancy marks a
user could put on SmartTrak's profiles.  They are, surprisingly, stored
relatives to (x,y) coordinates of the profile graph, so trying to convert
them to time related events is, at least, unaccurate, politely speaking  ;-)

Regards.

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

Re: [PATCH] mobile: divedetails page etc. improvements

[Sebastian Kügler]

On Friday, November 13, 2015 14:32:34 Lubomir I. Ivanov wrote:
>  It's coming along. How hard will it be to swipe sideways from dive to
>  dive
>  when in dive detail mode? So I tap on one of the dives and I just swipe
>  left and right to get to the previous / next dive instead of having to
>  go
>  back to the dive list between dives?
> >>>
> >>> Not entirely trivial as the dives are currently not items next to each
> >>> other.
> >>> Adding previous/next in general shouldn't be too hard, and we could hook
> >>> it up
> >>> to swipe gestures, but it won't look completely natural since we're not
> >>> having
> >>> dives as separate items next to each other. I'll give it some more
> >>> thinking.
> >>>
> >>
> >> hello,
> >>
> >> here is a concept with some QML source code (attached), which can help
> >> you get started.
> >> basically you need two 2 dive containers (dive details) - the current
> >> one which is displayed and another one which is the one which comes
> >> after the user swipes.
> >> the one which comes as new, can be populated with data on the go. if
> >> this is slow, some sort of buffering is an option - e.g. 2 dives ahead
> >> and 2 behind.
> >>
> >>
https://dl.dropboxusercontent.com/u/1627980/subsurface/mobile_dive_details_concept.gif
> >>
> >> what i don't like in this experiment is that i have a SwipeArea that
> >> handles the swipe gestures, inside a Flickable and the 2 Dives are
> >> inside the SwipeArea. normally you would want a Flickable per Dive,
> >> because if the user Flicks a dive (say, to look at the dive notes at
> >> the bottom) and then decides to swipe to the next dive the next dive
> >> Flickable contentY should be at 0, while the old Dive flickable
> >> contentY should be where the user left it.
> >>
> >> i couldn't get a Flickable inside a SwipeArea to work - no matter the
> >> usage of preventStealing and propagateComposedEvents.
> >> my current solution is to simply reset the single Flickable contentY
> >> to 0 on each swipe, which creates a bit of a glitch.
> >>
> >
> > alright...
> >
> > so here is the visual of the working POC:
> >
https://dl.dropboxusercontent.com/u/1627980/subsurface/mobile_dive_details_concept2.gif
> >
> > i restructured the classes a little and now it works the following way:
> > - one DiveContainer that defines a navigation callback (i.e.
> > left/right) and includes 2 Dives
> > - each Dive contains a SwipeArea inside a Flickable. the actual dive
> > details are inside the SwipeArea itself.
> >
> > this is a workaround as i would have preferred to have one SwipeArea
> > over the whole DiveContainer and not for each Dive; the solution is
> > tolerable as long as we don't have thousands of Dive instances. one
> > Flickable per Dive is desired though, like seen in the visual/GIF.
> >
> > attached is the updated source (with comments this time).
> > hope that helps, Sebastian.
> >
>
> latest iteration of the test project here.
>
> in the previous version stuff inside the SwipeArea was not clickable -
> so we can't have a dive details pane with buttons inside of it, which
> obviously isn't acceptable.
> the challenge here is that we have a scroll area (Flickable), inside
> of which there is an area which captures swipes (SwipeArea) and inside
> of it there could be buttons.
> ...a bit of a complicated mess, but it's doable in QML.
>
> this modification adds single touch support for that via tracking if
> the mouse is still over the last pressed element  - e.g. see
> 'diveDetailsMouseArea' in DiveDetails.
> if so, the Dive class captures the click and emits the clicked()
> signal to 'diveDetailsMouseArea'
> there could be better solutions, but i don't know of them.
>
> this allows the the user to click, say on the dive details to execute
> some action, while he/she can still swipe or flick/scroll the dive.
>
> i've also cleaned up the SwipeArea a little.

Hah, nice!

For my taste, the code especially in SwipeArea is a bit low-level, making it
hard to maintain. The javascript running on the change notifier signals may
also slow down the whole thing. In my experience, especially input logic can
be quite brittle, not necessarily something you want to maintain for a long
time.

On the other hand, QtQuick's ListView provides already what we need. So here's
a slightly different approach: we use a listview will delegates sized to fit
exactly in the viewport. We re-use the divelist's model for this listview as
well, and we set the listview to snap to items when scrolling: pronto: we
a=have swiping.

This means that we show usually one item (and when swiping left/right between
items two partial items), so we can tell the listview to keep the number of
items rendered in check, ListView is equipped to do that with the
ListView.cacheBuffer property, which essentially says: "keep delegates for
this number of pixels left and right ready", so it will dynamically render
more items and delete the delegates as needed.
As a bonus, we don't ha

Re: [PATCH] mobile: divedetails page etc. improvements

[Sebastian Kügler]

On Thursday, November 12, 2015 19:56:41 Linus Torvalds wrote:
> On Nov 12, 2015 19:34, "Dirk Hohndel"  wrote:
> >
> >> On Nov 12, 2015, at 3:12 PM, Lubomir I. Ivanov  wrote:
> >>
> >> so here is the visual of the working POC:
> >> https://dl.dropboxusercontent.com/u/1627980/subsurface/mobile_dive_details_concept2.gif
> >
> > This is really cool - I especially like the beautiful rendering of the dive 
> > profile :-)
> 
> I never even knew before this masterpiece that I needed sharks in my profile. 
> But now that I have seen them, nothing else will ever do.
> 
> The only question in my mind is whether just one shark per profile is enough, 
> or if we need more.

follow-up dillemma: left or right shark...
-- 
sebas

Sebastian Kügler|http://vizZzion.org| http://kde.org

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

Re: Scubapro/Uwatec Smartrak .slg files importing tool

[Pedro Neves]

On 13-11-2015 21:05, Salvador Cuñat wrote:



H,  if you are diving a Galileo,  I'm not sure that all of them 
are your bookmarks.
No. I have a couple o Tec 2G's which I only use in gauge mode, so 
there's no chance of those being safey stop counts...



What I haven't still figured out how to manage, are those fancy marks 
a user could put on SmartTrak's profiles.  They are, surprisingly, 
stored relatives to (x,y) coordinates of the profile graph, so trying 
to convert them to time related events is, at least, unaccurate, 
politely speaking  ;-)


Yes. Those "fancy marks" are the bookmarks I'd like to get into 
subsurface (there's an open ticket in trac for it: #150). In my case 
they get stored in the DC, whenever I press the button UW. The divetime 
goes back to 00:00 (although it keeps counting on a corner of the 
screen) and when the dives are downloaded into SmarTrak they show up on 
the profile. However, when dives are imported into SS directly, the 
bookmarks don't show up.


It's no big deal... It's just that would be nice to have it directly on 
Subsurface.


Anyway, thanks again...

Cheers:

Pedro

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

Re: [PATCH] mobile: divedetails page etc. improvements

[Lubomir I. Ivanov]

On 13 November 2015 at 23:14, Sebastian Kügler  wrote:
> Hah, nice!
>
> For my taste, the code especially in SwipeArea is a bit low-level, making it
> hard to maintain. The javascript running on the change notifier signals may
> also slow down the whole thing. In my experience, especially input logic can
> be quite brittle, not necessarily something you want to maintain for a long
> time.

i'm used to writing/maintain things like that in languages/frameworks
where built-in components are not sufficient for all the crazy client
UI extravaganza in commissioned projects.
e.g. a BuiltInComponentX covers 90% features but the client wants it
to do 10% backflips in such a way that the time investment of
modifying the existing component is more than re-writing the whole
thing from scratch.

>
> On the other hand, QtQuick's ListView provides already what we need. So here's
> a slightly different approach: we use a listview will delegates sized to fit
> exactly in the viewport. We re-use the divelist's model for this listview as
> well, and we set the listview to snap to items when scrolling: pronto: we
> a=have swiping.
>
> This means that we show usually one item (and when swiping left/right between
> items two partial items), so we can tell the listview to keep the number of
> items rendered in check, ListView is equipped to do that with the
> ListView.cacheBuffer property, which essentially says: "keep delegates for
> this number of pixels left and right ready", so it will dynamically render
> more items and delete the delegates as needed.
> As a bonus, we don't have to copy a whole lot of data between divelist and
> details view, we just set the detail's listview.currentItem to whatever the
> user picked in the overview list (and possibly avoid animations).
>
> Do I make sense to you? If not, proof-of-concept attached. It's quite minimal
> and only shows the very basic mechanism.
>

nice...so ListView pretty much does what's required here out of the
box. also Flickable and MouseAreas in the delegate item *just work* -
i've just tested that.
plus the buffering, which is a great bonus!

as long as there no performance issues, this is pretty much good to go
in the source.

> I quite like what you have done in the delegate. I'd like to split viewing and
> editing dives into separate UIs, one optimized for viewing, one optimized for
> editing (e.g. showing the profile in the editing page is not very useful, on
> the other hand the TextEdit widgets in the details view make it visually quite
> heavy. We should probably do something like to the current details delegate
> (and repurpose / cut down the current detailswidget purely for editing.
>

for the main application something which was an important topic at
some point in time (discussions between Dirk and Tomaz mostly) was to
be able to edit in place. this can be seen in the MainTab class ATM.
so i'm not sure if everyone will agree on a separate dive edit page
for the mobile UI, but this can be solved with a DiveEdit overlay of
sorts - i.e. when you swipe the ListView to a dive, click over the
details and a rectangle opens on top of static texts with some
TextEdit fields...or a DiveEdit can simply replace the static text
container until the editing is finished. not sure about the exact
implications and if this is the best choice.

---

BTW, i'm getting a crash on Win32 when i build the mobile application.
it says that the main application rectangle is wrong and enters a long
loop of allocating GB of memory, until it runs out.

if i manually set "width" and "height" in the ApplicationWindow of
main.qml it ignores them but it runs in a huge window!
the UI looks quite bad here, but that's probably because i'm using the
Windows XP them on Windows 7. :-)

any idea how to run the UI in a reasonable desktop resolution e.g. 480x800px?

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

Re: [PATCH] mobile: divedetails page etc. improvements

[Linus Torvalds]

On Fri, Nov 13, 2015 at 1:16 PM, Sebastian Kügler  wrote:
> On Thursday, November 12, 2015 19:56:41 Linus Torvalds wrote:
>>
>> I never even knew before this masterpiece that I needed sharks in my 
>> profile. But now that I have seen them, nothing else will ever do.
>>
>> The only question in my mind is whether just one shark per profile is 
>> enough, or if we need more.
>
> follow-up dillemma: left or right shark...

Dilemma?

The whole internet knows that left shark is where it's at.

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

Re: [PATCH] mobile: divedetails page etc. improvements

[Dirk Hohndel]

> On Nov 13, 2015, at 3:26 PM, Linus Torvalds  
> wrote:
> 
> On Fri, Nov 13, 2015 at 1:16 PM, Sebastian Kügler  wrote:
>> On Thursday, November 12, 2015 19:56:41 Linus Torvalds wrote:
>>> 
>>> I never even knew before this masterpiece that I needed sharks in my 
>>> profile. But now that I have seen them, nothing else will ever do.
>>> 
>>> The only question in my mind is whether just one shark per profile is 
>>> enough, or if we need more.
>> 
>> follow-up dillemma: left or right shark...
> 
> Dilemma?
> 
> The whole internet knows that left shark is where it's at.

Clearly - it's all about the left shark.

And for those lucky people who didn't see the Superbowl half time show...

http://knowyourmeme.com/memes/super-bowl-xlix-halftime-shark 


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

Re: [PATCH] mobile: divedetails page etc. improvements

[Dirk Hohndel]

> On Nov 13, 2015, at 1:59 PM, Lubomir I. Ivanov  wrote:
> 
>> I quite like what you have done in the delegate. I'd like to split viewing 
>> and
>> editing dives into separate UIs, one optimized for viewing, one optimized for
>> editing (e.g. showing the profile in the editing page is not very useful, on
>> the other hand the TextEdit widgets in the details view make it visually 
>> quite
>> heavy. We should probably do something like to the current details delegate
>> (and repurpose / cut down the current detailswidget purely for editing.
>> 
> 
> for the main application something which was an important topic at
> some point in time (discussions between Dirk and Tomaz mostly) was to
> be able to edit in place. this can be seen in the MainTab class ATM.
> so i'm not sure if everyone will agree on a separate dive edit page
> for the mobile UI, but this can be solved with a DiveEdit overlay of
> sorts - i.e. when you swipe the ListView to a dive, click over the
> details and a rectangle opens on top of static texts with some
> TextEdit fields...or a DiveEdit can simply replace the static text
> container until the editing is finished. not sure about the exact
> implications and if this is the best choice.

I was quite adamant that I wanted in place editing on the desktop.
It just feels natural. On the mobile app I'll be happy to accept what's
reasonable or what gives us the most maintainable / most user friendly
experience.

The overlay technique you propose sounds interesting, but also quite
fragile. So if we have an edit button and then the profile is removed and
we change elects around to make the data entry easier, I'm ok with that.

> BTW, i'm getting a crash on Win32 when i build the mobile application.
> it says that the main application rectangle is wrong and enters a long
> loop of allocating GB of memory, until it runs out.

Intersting. I admit I never tried that :-)

> if i manually set "width" and "height" in the ApplicationWindow of
> main.qml it ignores them but it runs in a huge window!
> the UI looks quite bad here, but that's probably because i'm using the
> Windows XP them on Windows 7. :-)

So you are saying it fits perfectly with the rest of your experience?
(sorry, couldn't resist).

Yeah, the UI on the desktop does look awkward, but to me that's
nothing more than having the ability to build and do quick tests,
the target platforms are Android and iOS here...

> any idea how to run the UI in a reasonable desktop resolution e.g. 480x800px?

Not a clue :-)

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

mobile app vs. companion app

[Dirk Hohndel]

So I thought about this some more (and Linus also chimed in) and changed
direction.

With the latest master Subsurface-mobile can "mostly" replace the
companion app. You can enter your user id (but there are no "sign up" or
"send me forgotten user id" options, yet) and can then upload the GPS
fixes it records. You can't set the time / distance thresholds, those are
hardcoded.

But as far as I can tell all that is missing are a few small things on the
edges, the core of what the companion app can do is there and appears to
be working in my minimal testing.

And of course you can ALSO apply the GPS fixes to dives that are loaded on
the device - so now there are two possible work flows

a) you have a dive computer that can download to your tablet / phone:
   you're golden, you can do it all on your device. Track GPS, download
   dives, merge in GPS locations

b) you connect your dive computer to your laptop; now you have two options
   b1) use cloud storage; after you entered everything on the laptop, save
   cloud storage, load from cloud storage on your device, merge GPS
   locations, save back to cloud storage
   b2) the old fashioned way; push from device to Subsurface webservice
   load from webservice and merge in locations on your laptop

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