Re: Printing/Exporting statistics

Hi, > On 28. Jun 2021, at 17:11, Berthold Stoeger > wrote: > > Indeed, that was one of my concerns when porting the original QGraphicsScene > code to QtQuick/QSG (which, for the records, is the worst API I have ever > used). My plan back then was to build alternative frontends, e.g. for tabular

Re: Printing/Exporting statistics

On 2021/06/28 14:05, Robert Helling via subsurface wrote: Hi, a couple of days ago, I had the idea that it might be useful if the user could print the statistics plots or export those as images. But I could not figure out how to do that. The profile can be rendered as a QImage but the

Re: Printing/Exporting statistics

Hi Robert, On Montag, 28. Juni 2021 14:05:38 CEST Robert Helling via subsurface wrote: > a couple of days ago, I had the idea that it might be useful if the user > could print the statistics plots or export those as images. But I could not > figure out how to do that. The profile can be

Printing/Exporting statistics

Hi, a couple of days ago, I had the idea that it might be useful if the user could print the statistics plots or export those as images. But I could not figure out how to do that. The profile can be rendered as a QImage but the statistics uses GL functionality and I don’t understand to use

Dive selection and the statistics code

Dear all, Concerning the new statistics module, there have been requests to enable the selection and analysis of subsets of dives. One use-case being the examination of outliers. In the current desktop build, you can select items in the charts (e.g. bars in bar charts or individual dives in

Re: some more feedback on the statistics widgets we have

Hi Peter, On Mittwoch, 13. Jänner 2021 08:10:26 CET Peter Zaal via subsurface wrote: > I now see this is the same issue with using the Filter and switching views: > from 'normal' view (all 4 parts Info, Profile, Dive List and Map are > visible), then select Filter. The Map is now replaced with th

Re: some more feedback on the statistics widgets we have

On Tue, Jan 12, 2021 at 9:57 PM Dirk Hohndel via subsurface < subsurface@subsurface-divelog.org> wrote: > - when closing the statistics on desktop, the dividers aren't restored to > their previous positions > We talked about completely replacing the dividers with something b

some more feedback on the statistics widgets we have

Berthold, I know you know this, but just documenting it here so I don't forget: - when closing the statistics on desktop, the dividers aren't restored to their previous positions We talked about completely replacing the dividers with something better, but I'm not sure if you ha

iOS build 4.9.10.334 with dive statistics

I've been away from testing for months. I just downloaded the new iOS release with an early view of the statistics. I'll check it out properly, but the initial impressions are excellent. Very usable on my iPhone6 running iOS 12.5.1. I played around with a variety of views, binning.

Re: Feedback and testing of the dive statistics

> On Jan 10, 2021, at 10:42 PM, Michal Sawicz wrote: > > Hey, > > W dniu 11.01.2021 o 01:46, Dirk Hohndel pisze: >>> On Jan 10, 2021, at 3:14 PM, Dirk Hohndel via subsurface >>> wrote: >>> >>> I have fixed all of the trees that are used to create the builds in >>> downloads/test, deleted

Re: Feedback and testing of the dive statistics

Hey again, W dniu 11.01.2021 o 07:42, Michal Sawicz pisze: Hey, W dniu 11.01.2021 o 01:46, Dirk Hohndel pisze: On Jan 10, 2021, at 3:14 PM, Dirk Hohndel via subsurface wrote: I have fixed all of the trees that are used to create the builds in downloads/test, deleted the existing builds

Re: Feedback and testing of the dive statistics

Hey, W dniu 11.01.2021 o 01:46, Dirk Hohndel pisze: On Jan 10, 2021, at 3:14 PM, Dirk Hohndel via subsurface wrote: I have fixed all of the trees that are used to create the builds in downloads/test, deleted the existing builds there that had invalid version information and triggered new

Re: Feedback and testing of the dive statistics

> On Jan 10, 2021, at 3:14 PM, Dirk Hohndel via subsurface > wrote: > > I have fixed all of the trees that are used to create the builds in > downloads/test, deleted the existing builds there that had invalid version > information and triggered new builds that have already started to popula

Re: Feedback and testing of the dive statistics

> On Jan 10, 2021, at 3:03 PM, Dirk Hohndel via subsurface > wrote: > > New test binaries should be ready very soon. I noticed that something went > weird when a faulty push to master confused my build servers and need to > restart all of those builds for the latest master. Ugh. Unfortun

Re: Feedback and testing of the dive statistics

nd Q4. >> But it also didn’t change when selecting Quarterly or Monthly. Then I >> figured this is probably some statistics thing (I told you I am a noob in >> statistics), and indeed it is. I do understand a little about the difference >> between mean and median, but is Q

Re: Statistics code for desktop (and soon mobile)

> On Jan 10, 2021, at 2:06 PM, Rick Walsh wrote: > I have just had a short play with the statistics with the latest daily > Windows build (subsurface-4.9.10-260-gbd26d8407f28.exe) and I must say this > looks great. It is ridiculously easy to create meaningful (and meaningless!)

Re: Statistics code for desktop (and soon mobile)

wrote: > > Right, I didn't test the AppImage. Silly me. I'll add that to my list. > > > AppImage is fixed, also Subsurface now reacts more gracefully if the > QtCharts QML modules can't be found. > Instead of a crash the statistics chart is simply empty. What we

Re: Feedback and testing of the dive statistics

e is Q2 and Q4. > But it also didn’t change when selecting Quarterly or Monthly. Then I > figured this is probably some statistics thing (I told you I am a noob in > statistics), and indeed it is. I do understand a little about the > difference between mean and median, but is Q1 and Q3 somethi

Re: Feedback and testing of the dive statistics

imilar it seems. > Ofcourse I had some peek previews of the statistics in this mailing list and > knew a little about what was possible. But what I did was *before* going > through all the options myself, I made a list of the things I would like to > know about my dives. And then just

Feedback and testing of the dive statistics

Hi all, Warning: long mail! So I finally got around to do some proper testing and looking at the new statistics module in Subsurface. I did follow the development of the on the side in this mailing list, and it looked so nice that although being a developer myself (but not C/C++) and

Re: Statistics code for desktop (and soon mobile)

uite inaccessible. If you click on "Add constraint", a list of all possible constraints is shown. I Need to look at the user manual to see if this aspect has been explained clearly. This is possibly my fault. It is fantastic that you actually looked at the statistics option and that

Re: Statistics code for desktop (and soon mobile)

elect" possibility to add constraints. >>> For example my Depth over Date Scattergraph looks like this: >>> >>> Now to have a look at a single holiday I can add a constraint over a >>> range of dates, for example 1.1.2017 to 1.1.2018. This works fine! But

Re: Statistics code for desktop (and soon mobile)

1.1.2018. This works fine! But >> the cherry on top would be if I could simply drag a rectangle over the >> points in 2017, and set the constraints like this (Sort of a "Zoom into >> range" functionality). > > That is an inte

Re: Statistics code for desktop (and soon mobile)

ng up, Max O2 for instance shows unused cylinders which i had > hidden with the checkbox in preferences so i have unhidden them and gone > through and purged my log of those unwanted cylinders, this looks a bit > better now with less noise. Interesting. I wonder if this is something whe

Re: Statistics code for desktop (and soon mobile)

lculate SAC, so it should already be defined. > That is an interesting idea. But don't hold your breath. Currently we are changing the rendering engine to port the statistics to mobile and this will take some time. I thought so, but I just wanted to plant a seed ;-) > Note that there

Re: Statistics code for desktop (and soon mobile)

hools closed it’s going to be hard to keep up productivity for day job and then equally for hobby): * Why is the dive list disabled when the stats are open? I might want to change the selection and have the statistics apply only to selected dives. The filter helps in this direction but may

Re: Statistics code for desktop (and soon mobile)

cherry on top would be if I could simply drag a rectangle over the > points in 2017, and set the constraints like this (Sort of a "Zoom into > range" functionality). That is an interesting idea. But don't hold your breath. Currently we are changing the rendering engine to

Re: Statistics code for desktop (and soon mobile)

rface < > subsurface@subsurface-divelog.org> wrote: > > > > Are there cool ‘recipes’ that should be available by default? SAC rate > over time binned by water temperature, things like that? > > That's a cool idea. Someone else brought up the idea that we shou

Re: Statistics code for desktop (and soon mobile)

have a way to save "configurations" for the statistics - and it might make sense to add few predefined configurations to get people started. I like it. Devil is likely in the details (picking good sets, etc), but it's a good direction! /D

Re: Statistics code for desktop (and soon mobile)

with the current AppImage (which > works perfectly now). I didn't find anything "buggy" and there isn't much > to complain about (the most German compliment ever). I like it! :-) > > I don't have too many dives (86), and everything is open circuit, so it's

Re: Statistics code for desktop (and soon mobile)

en circuit, so it's maybe a bit harder to get interesting statistics, but I did find: * My SAC sucks and didn't get much better over the years, but gets better at the end of the holidays. And less SAC in warmer water (makes sense, but I didn't think about it before I played

Re: Statistics code for desktop (and soon mobile)

Hi, > On 8. Jan 2021, at 21:31, Dirk Hohndel via subsurface > wrote: > > So we have working binaries for all platforms, but we have heard basically no > feedback on the new statistics feature. > No indication that anyone has tested this, likes it, hates it, has > s

Re: Statistics code for desktop (and soon mobile)

On Fri, Jan 8, 2021 at 12:31 PM Dirk Hohndel via subsurface wrote: > > So we have working binaries for all platforms, but we have heard basically no > feedback on the new statistics feature. So I didn't test the pre-built binaries, but I did test my own. I very much like the

Re: Statistics code for desktop (and soon mobile)

> >>>> Right, I didn't test the AppImage. Silly me. I'll add that to my list. >>> >>> AppImage is fixed, also Subsurface now reacts more gracefully if the >>> QtCharts QML modules can't be found. >>> Instead of a crash the statist

Re: Statistics code for desktop (and soon mobile)

> On Jan 8, 2021, at 12:42 PM, Martin de Weger wrote: > > I have played with it a bit, and it looks great. I haven’t looked into it > deep enough to say I actually tested it. And that's great input already. It's so complex, "testing" it is hard. But just knowing that you played with it is gr

Re: Statistics code for desktop (and soon mobile)

: >>> >>> >>> >>> On Jan 3, 2021, at 3:44 PM, Dirk Hohndel via subsurface >>> wrote: >>> >>> Right, I didn't test the AppImage. Silly me. I'll add that to my list. >> >> AppImage is fixed, also Subsurface

Statistics code for desktop (and soon mobile)

d that to my list. > > AppImage is fixed, also Subsurface now reacts more gracefully if the QtCharts > QML modules can't be found. > Instead of a crash the statistics chart is simply empty. What we really need > is a reasonable error message (or alternative disable the statist

Re: new statistics code merged

> On Jan 3, 2021, at 3:44 PM, Dirk Hohndel via subsurface > wrote: > > Right, I didn't test the AppImage. Silly me. I'll add that to my list. AppImage is fixed, also Subsurface now reacts more gracefully if the QtCharts QML modules can't be found. Instead of a cr

Re: Building statistics

Doug Junkins wrote: > > I ran into the same problems as Robert trying to build the > bstoeger-statistics branch on MacOS 10.15.7 with Qt 5.15.2 installed with > QtCharts, but haven’t had a chance to dig into the issue yet (other than > confirming that adding #include fixes the m

Re: Building statistics

I ran into the same problems as Robert trying to build the bstoeger-statistics branch on MacOS 10.15.7 with Qt 5.15.2 installed with QtCharts, but haven’t had a chance to dig into the issue yet (other than confirming that adding #include fixes the missing std::isnan() reference.) -Doug >

Re: Building statistics

Oh yes, all my tests of the statistics code have been on macOS 10.15. What I think you are seeing is that not all required QML modules and plugins were automatically moved into the app folder. I have a few family things to take care of this morning, but I'll try a clean build and make sure

Re: Building statistics

Hi Robert, On Freitag, 1. Jänner 2021 16:00:28 CET Robert Helling via subsurface wrote: > First thing I noticed was that the compiler complains about not knowing > about std::isnan(). But since there is (and is suggested by the compiler) > isnan(), I changed all occurrences in this way. Maybe I a

Building statistics

Hi, first: Happy new year everybody! After mostly ignoring it for several weeks due to time constraints, I finally got around to check out the new statistics stuff and tried to build it. Maybe I am the first to attempt this under Mac OS, but so far I have not succeeded. I should mention, I

Re: RFC: Statistics in Subsurface

> On Sep 27, 2020, at 7:21 AM, Willem Ferguson via subsurface > wrote: > I think there is some misunderstanding, or am I myself misunderstanding?? See > inline below. I think I misunderstood you. >>> >>> 1) UI for selecting variables to be plotted. At this stage just two >>> comboxes as di

Fwd: Re: RFC: Statistics in Subsurface

On 2020/09/27 15:13, Dirk Hohndel wrote: I think there is some misunderstanding, or am I myself misunderstanding?? See inline below. Hi Willem, adding the Subsurface developer list to this thread On Sep 27, 2020, at 5:34 AM, Willem Ferguson wrote: A quick question about the use of C++

Re: RFC: Statistics in Subsurface

Hi Willem, adding the Subsurface developer list to this thread > On Sep 27, 2020, at 5:34 AM, Willem Ferguson > wrote: > > A quick question about the use of C++ and QML in writing code for presenting > graphs. In general, my leaning is towards QML simply because making anything > mobile-frie

Re: RFC: Statistics in Subsurface

Dear all, On Dienstag, 12. Mai 2020 00:02:06 CEST Dirk Hohndel wrote: > Here's a crazy idea how this could look for example: > > The filters are built incrementally, with a drop down menu that allows you > to add criteria or constraints. Like date range, tags, people, etc I posted a first rough

Re: RFC: Statistics in Subsurface

dots indicate the water temperature of each dive. The temperature vs SAC scatterplot would be one of the few statistics I'd like to see, because it's the one that I personally think might be the best correlation. Not that I've really ever tested it. You have those "SAC vs dep

Re: RFC: Statistics in Subsurface

ithout cluttering the > interface. > This appears to be useful independently of the statistics topic. Yes, I really think of this as two related, yet independent developments. > So far, the string-based searches (tags, people, etc) seem to work fine. > Others, such as temperature (

Re: RFC: Statistics in Subsurface

ng such a multi-constraint filter and so far I like the idea, as it allows for more filter criteria (e.g. depth, day-of- week, month-of-year, phase-of-the-moon, etc) without cluttering the interface. This appears to be useful independently of the statistics topic. So far, the string-based se

Re: Re: RFC: Statistics in Subsurface

temperature of each dive. The temperature vs SAC scatterplot would be one of the few statistics I'd like to see, because it's the one that I personally think might be the best correlation. Not that I've really ever tested it. You have those "SAC vs depth" and "SAC

Fwd: Re: RFC: Statistics in Subsurface

On 2020/05/16 18:22, Dirk Hohndel wrote: I'd argue that's six (but that's because of my potential additions): two values: - 1) Bar chart - 2) Dot graph - 3) Scatter plot three values: - 4) Stacked bar chart - 5) Dot graph with colors - 6) Scatter plot with colors. We need to think about the

Re: RFC: Statistics in Subsurface

t; western world) we work from top left, top right, bottom left, bottom >> right, and the logical Workflow would be to have the dive list as >> input, which is then filtered, then the statistics selected and >> finally the output. This workflow could also be applied as sort of a

Re: RFC: Statistics in Subsurface (Willem Ferguson)

> On May 14, 2020, at 1:09 PM, Hartley Horwitz via subsurface > wrote: > > I know this plot as a 'beeswarm'. I'm not sure if that's a universally used > term, but I use those in Spotfire (a large statistics tool). I thought I > should show the same

Re: RFC: Statistics in Subsurface (Willem Ferguson)

> -- Forwarded message -- > From: Willem Ferguson > To: Subsurface Mailing List > Cc: > Bcc: > Date: Thu, 14 May 2020 21:04:14 +0200 > Subject: Fwd: Re: RFC: Statistics in Subsurface > > ….snip > I attach a suggestion that, to me, what it does

Re: RFC: Statistics in Subsurface

I really like this. And it very much matches what was said in the video that Pedro mentioned: "Show all the data when possible". And it does that perfectly. So yes, I like that and I think it's a really cool way to visualize SAC rates. I need to spend time to think through all the 'y-axis' values

Fwd: Re: RFC: Statistics in Subsurface

al labels. They are also a complete pain to read. I would argue that the readability of a horizontal chart is actually much better than the vertical one that you so strongly argue for. I did a quick survey of some of the other dive logs that have screen shots of their statistics pages up on

Re: RFC: Statistics in Subsurface

ht", "Stats selection bottom left", "Stats display bottom > right". This is with the reasoning that (in the western world) we work from > top left, top right, bottom left, bottom right, and the logical Workflow > would be to have the dive list as input, which is th

Re: RFC: Statistics in Subsurface

en't adequate for the purpose. > I want to make a call that, if we are dealing with representing statistics, > we actually use the proper statistics representations that we are all used > to. Most likely that is either some variant of a box and whiskers diagram or > a vertic

Re: RFC: Statistics in Subsurface

t;, "Stats selection bottom left", "Stats display bottom right". This is with the reasoning that (in the western world) we work from top left, top right, bottom left, bottom right, and the logical Workflow would be to have the dive list as input, which is then filtered, then the st

Re: RFC: Statistics in Subsurface

I think it's great statistics are being tackled again, and it's excellent to have several mock-ups to discuss so hopefully some consensus can be made before people spend countless hours on code that ends up rejected because the presentation isn't as desired. On Thu, 14 May 202

Re: RFC: Statistics in Subsurface

when turned 90 degrees :-) /D On May 13, 2020, at 12:53 PM, Hartley Horwitz <mailto:hhr...@gmail.com>> wrote: I"ve attached 3 graphs showing the statistics summary.  Once again I showed them to a work colleague.  He found the upper 2 graphs easiest to understand. ...Hart

Re: RFC: Statistics in Subsurface

12:53 PM, Hartley Horwitz wrote: > > I"ve attached 3 graphs showing the statistics summary. Once again I showed > them to a work colleague. He found the upper 2 graphs easiest to understand. > > > ...Hartley > > On Wed, May 13, 2020 at 3:24 PM Dirk Hohndel <

Re: RFC: Statistics in Subsurface

of SAC.or PO2 On Wed, May 13, 2020, 22:54 Hartley Horwitz via subsurface < subsurface@subsurface-divelog.org> wrote: > I"ve attached 3 graphs showing the statistics summary. Once again I > showed them to a work colleague. He found the upper 2 graphs easiest to > unders

Re: RFC: Statistics in Subsurface

I"ve attached 3 graphs showing the statistics summary. Once again I showed them to a work colleague. He found the upper 2 graphs easiest to understand. ...Hartley On Wed, May 13, 2020 at 3:24 PM Dirk Hohndel wrote: > That is excellent input! > > Your final point is one th

Re: RFC: Statistics in Subsurface

> On May 13, 2020, at 10:00 AM, Pedro Neves wrote: >> >> Also (and I've seen this in other places), why the horizontal bars for >> years? I would most likely have always done vertical bars, but again, maybe >> there's a good reason that I'm missing? > > > My inspiration for some of the thin

Re: RFC: Statistics in Subsurface

On 13/05/20 16:50, Dirk Hohndel wrote: The zero based bar charts with whiskers for for min / max are interesting. Why do you prefer those over the floating bars (indicating min/max) with a line or dot to mark the average? I think either is fine, I'm just curious if you have a reason for picki

Re: RFC: Statistics in Subsurface

Hi PedroOn May 13, 2020, at 6:26 AM, Pedro Neves via subsurface wrote:Adding my comments to this discussion...I am so happy to hear more voices in this conversation.Attached you'll find a list of the stats I currently have for my logs. I use the csv export facili

Re: RFC: Statistics in Subsurface

> On May 12, 2020, at 6:38 PM, Hartley Horwitz via subsurface > wrote: > > Here's a crazy idea how this could look for example: > > > > The filters are built incrementally, with a drop down menu that allows you > > to add criteria or constraints. Like date range, tags, people, etc > > > > I r

Re: RFC: Statistics in Subsurface

> On May 12, 2020, at 7:00 PM, Hartley Horwitz via subsurface > wrote: > > I keep saying "candlestick" when I mean to say "box and whiskers". My > mistake. You are spot on correct, the error is mine. > > As much as I use stats in my job, I wonder what the value of knowing the > upper quarti

Re: RFC: Statistics in Subsurface

> -- Forwarded message -- > From: Dirk Hohndel > To: Willem Ferguson > Cc: Subsurface Mailing List > Bcc: > Date: Tue, 12 May 2020 14:24:28 -0700 > Subject: Re: RFC: Statistics in Subsurface > > On May 12, 2020, at 12:41 PM, Willem Ferguson < >

Re: RFC: Statistics in Subsurface

> > -- Forwarded message -- > From: Berthold Stoeger > To: Dirk Hohndel > Cc: willemfergu...@zoology.up.ac.za, subsurface@subsurface-divelog.org > Bcc: > Date: Tue, 12 May 2020 07:46:00 +0200 > Subject: Re: RFC: Statistics in Subsurface > On Dienstag,

Re: RFC: Statistics in Subsurface

ags in a meaningful way - one could have a mutually exclusive set of three tags (say, air, nitrox, trimix) and create statistics over them. Of course the results become "strange" if dives potentially have multiple of those tags. Again, to get this "mostly right" is fairly easy. To co

Fwd: Re: RFC: Statistics in Subsurface

Forwarded Message Subject:Re: RFC: Statistics in Subsurface Date: Tue, 12 May 2020 21:41:08 +0200 From: Willem Ferguson Reply-To: willemfergu...@zoology.up.ac.za Organization: University of Pretoria To: Dirk Hohndel On 2020/05/12 20:49, Dirk

Re: RFC: Statistics in Subsurface

aching dive or non-teaching dive) has absolutely > no impact on how this should be visually represented... > >> It would help, in this discussion, if one were to distinguish between the >> filtering aspect and the statistics display aspect and state that with >> respect to the a

Re: RFC: Statistics in Subsurface

ould be visually represented... > It would help, in this discussion, if one were to distinguish between the > filtering aspect and the statistics display aspect and state that with > respect to the argument. In Dirk's artwork above, I am not sure how the > constraints will be used

Re: RFC: Statistics in Subsurface

On Dienstag, 12. Mai 2020 00:02:06 CEST Dirk Hohndel wrote: > Here's a crazy idea how this could look for example: > > The filters are built incrementally, with a drop down menu that allows you > to add criteria or constraints. Like date range, tags, people, etc > > once the user picks one, that

Re: RFC: Statistics in Subsurface

ayer on top. Let's not introduce QML where not absolutely > > necessary. > You are correct. It isn't necessary. > But at the same time, assuming we want to go down this rabbit hole of using > this as a way to define groupings in statistics, then yes, we most likely > wa

Re: RFC: Statistics in Subsurface

Mechanisms to store filter "sets" and >> combine them to extract dive list information that is stored in the >> yearly-statistics table. > > Such presets should be rather easy to implement and are useful independently > of statistics. I can prototype such a thing at the

Re: Fwd: RFC: Statistics in Subsurface

rmation that is stored in the > yearly-statistics table. Such presets should be rather easy to implement and are useful independently of statistics. I can prototype such a thing at the end of the week (the next few days I'll be busy with work-related things). There is one crucial design decision

Re: Fwd: RFC: Statistics in Subsurface

hat 'set' (boat dives > 40min) - pick different filter settings (dive with tag 'boat', 30-39:59 duration) - name that 'set' combine a group of 'sets' into a group which gives you the slicing of the dives that you want Now offer those sets as rows in the

Re: Proposal: Statistics in Subsurface

Hi Tomaz > On May 8, 2020, at 6:40 AM, Tomaz Canabrava wrote: > > (Puff) > > This was my last serious attempt to do something userfull to subsurface, > almost 4 years ago. I basically gave up with around 120 - 140 commits because > no way I did pleased everyone. To this day I consider my fai

Re: Proposal: Statistics in Subsurface

that I’m using for a personal project, not qt quick charts, that thing is broken by design, that I think it can work. Best Tomaz On Thu, 7 May 2020 at 21:47 Chirana Gheorghita Eugeniu Theodor via subsurface wrote: > I would redesign the statistics page on using a default chart and a > dropd

Re: Proposal: Statistics in Subsurface

I would redesign the statistics page on using a default chart and a dropdown at the top to select more granular things like yearly, monthly. when selected the chart just readjust dinamic Only one tab. more tabs gets confusing and crowdint the screen. Just an idea. On Thu, May 7, 2020, 18:37 Dirk

Re: Proposal: Statistics in Subsurface

On Thu, 2020-05-07 at 14:37 +0200, Willem Ferguson via subsurface wrote: > I have been thinking a long time about graphical statistics > facilities > for Subsurface, that is presenting the dive statistics as bar graphs > or > other types of graphics. This is a topic that w

Proposal: Statistics in Subsurface

I have been thinking  a long time about graphical statistics facilities for Subsurface, that is presenting the dive statistics as bar graphs or other types of graphics. 1) In doing so, I looked at the yearly statistics as implemented at the moment and realised that this is actually a pretty

Re: RFC: Subsurface Statistics tab

hu, 12 Dec 2019 23:14:31 -0600 > Subject: Re: RFC: Subsurface Statistics tab > Hey guys, > > Preview of what bryan and i have been working on. Finally had some time > after the holiday to put some thinking and ideas together. What you’ll see > is probably more of a future version due

Re: RFC: Subsurface Statistics tab

Looks interesting! On Fri, Dec 13, 2019 at 5:14 AM ♠ Jordan Reiser ♠ wrote: > > Hey guys, > > Preview of what bryan and i have been working on. Finally had some time after > the holiday to put some thinking and ideas together. What you’ll see is > probably more of a future version due to the li

Re: RFC: Subsurface Statistics tab

Hey guys, Preview of what bryan and i have been working on. Finally had some time after the holiday to put some thinking and ideas together. What you’ll see is probably more of a future version due to the limitations of qt but we’re working through it. Check out the link below, the way i’m thinki

Re: RFC: Subsurface Statistics tab

> On Nov 26, 2019, at 3:24 AM, Bryan Oliver wrote: > > > Again, very open to better ideas. Our two main constraints so far have been > > "finding great design" and then "with the design ideas we have, finding how > > to implement them given the UI toolkits we have decided to use". Moving to >

Re: RFC: Subsurface Statistics tab

> > Attached a screenshot of a concept of rearranging the statistics tab. The > old design was not space efficient. This one provides all the information > in the statistics tab of the present master. Important thing is that it > frees a fairly large area at the bottom of the tab. The

Re: RFC: Subsurface Statistics tab

n has gauges. ...Hartley From: Dirk Hohndel > To: Willem Ferguson , "♠ Jordan Reiser > ♠" > Cc: Subsurface Mailing List > Bcc: > Date: Mon, 25 Nov 2019 14:53:31 -0800 > Subject: Re: RFC: Subsurface Statistics tab > > On Nov 24, 2019, at 10:09 AM, Willem Ferg

Re: RFC: Subsurface Statistics tab

> On Nov 24, 2019, at 10:09 AM, Willem Ferguson > wrote: > > Attached a screenshot of a concept of rearranging the statistics tab. The old > design was not space efficient. This one provides all the information in the > statistics tab of the present master. Important thing

RFC: Subsurface Statistics tab

Attached a screenshot of a concept of rearranging the statistics tab. The old design was not space efficient. This one provides all the information in the statistics tab of the present master. Important thing is that it frees a fairly large area at the bottom of the tab. The plan is to use

Re: Yearly statistics update

by a certain distance (30ft or 10m, for > example), you can use M_OR_FT(10, 30) (defined in units.h) > > Does this help? > > /D > >> On Mar 5, 2019, at 4:18 PM, Doug Junkins wrote: >> >> Here is a quick patch to demo the addition of an “All (by depth stats

Re: Yearly statistics update

demo the addition of an “All (by depth stats)” group > in the Yearly Statistics widget. > > Two caveats: > > 1) I used asprintf to format the labels for the depth ranges. That works fine > including on OS X, but on Linux it looks like I need to define > _GNU_SOURCE in

Yearly statistics update

Here is a quick patch to demo the addition of an “All (by depth stats)” group in the Yearly Statistics widget. Two caveats: 1) I used asprintf to format the labels for the depth ranges. That works fine including on OS X, but on Linux it looks like I need to define _GNU_SOURCE in the source

Re: Statistics

Tomaz, I took a look at the statistics-qwt branch. A few comments: (1) many of the commits are missing an SOB (and, frankly, better commit messages) (2) CMakeList.txt: at least on ArchLinux (which I thought you used as well) there doesn't appear to be Qwt6 cmake integration. Di

Re: Statistics

orks for non hidpi screens if we have less columns, I think the problem here is that I tested against all trips that I have. I'm working on the Yearly Statistics now and I think it would be easier to See. > davide@mobile > > On Aug 22, 2017 12:24, "Willem Ferguson" >

Re: Statistics

ld be very > valuable to include the number of dives in brackets after the name of the > trip, e.g. the trip to Hoodsport may be indicated as *Hoodsport, WA, USA > (6)*. The six in brackets would indicates that this trip comprised six > dives and that the leftmost bar for Hoodsport summar

  1   2   >