Dirk, This definitely helpful as I figure out where different functions are defined. I already found the get_depth_string() function and have got working code to add both the depth and temperature stats with the labels defined properly based on the unit preferences. I just want to finish up some testing/code cleanup while I’m on my way to Montreal this afternoon. Once that’s done I will do a pull request.
Ultimately, my next step is going to be to look at redoing the stats widget in a better way, but I want to get these two additions committed before starting that conversation. This has been a good exercise to get familiar with the code base and to start to understand Qt. -Doug > On Mar 6, 2019, at 12:28 PM, Dirk Hohndel <[email protected]> wrote: > > Hi Doug, > > Thanks for taking a stab at this. > > asprintf is the right idea - except we have our own flavors of that which do > work on all our platforms. Look at core/format.h > > printing things in feet or meters is actually fairly easy. Look at > get_depth_string() - you can call this both with a depth_t or with mm and it > will do the right thing. > And then if you want to group things 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 <[email protected]> wrote: >> >> 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 <stdio.h> on OS X, but on Linux it looks like I need to >> define _GNU_SOURCE in the source file. For now it is simply warning of an >> implicit definition of asprintf when compiling on Linux. >> >> 2) The depth range labels are hardcoded in Meters. I haven’t started >> figuring out how to apply the unit preferences to them. The labels are >> written into the structure in core/statistics.c (same as the trip location >> and the dive mode/type). At some point I think it would make sense to move >> those into the Qt widgets since it is a bit of a hack right now using the >> *location string to label each line in the statistics that is not a year or >> month. >> >> -Doug >> > <0001-Add-statistics-by-dive-depth.patch> >> >> >> >>> On Mar 5, 2019, at 10:25 AM, Doug Junkins <[email protected]> wrote: >>> >>> As long as we don’t call it Subsurface X... >>> >>>> On Mar 5, 2019, at 9:56 AM, Dirk Hohndel <[email protected]> wrote: >>>> >>>> 4.9 is the next release that I hoped to start working on about two weeks >>>> ago (which clearly didn't happen). Just for context. >>>> >>>> If and when we redo the divesite logic (and discussion on this seems to >>>> have fallen dormant again - which could mean that Linus and Berthold are >>>> busy writing code... or more likely that Linus is drowning in Linux merge >>>> window pull requests and Berthold is back focusing on the undo code) that >>>> will likely be a Subsurface 5.0 thing (not that our version numbers mean a >>>> lot, but now that Linux is at 5.0, we need to catch up... just kidding... >>>> this is a fairly significant change…) >>> >>> Yeah, I’m watching the discussion in the thread about undo and realize we >>> are a ways away from refactoring the divesite logic. >>> >>>>> On Mar 5, 2019, at 9:50 AM, Doug Junkins <[email protected]> >>>>> wrote: >>>>> >>>>> I’m a little late to the game here, but one thing I would like to see >>>>> (besides a way to share divesites between multiple users) is some more >>>>> detailed statistics. >>>>> >>>>> The “yearly statistics” are a good starting point, but I would like to >>>>> see my statistics based on things like depth of the dive, water >>>>> temperature, people I dove with, and tags. I also think now that the >>>>> filter system is updated and more usable, the statistics should be based >>>>> on the filtered list of dives (or have an option to display statistics on >>>>> the filtered divelist.) >>>>> >>>>> Doing a quick search for “statistics” in the User Forum indicates that >>>>> this is something people would like to see, but it was closely tied to >>>>> the filter update as far as I can tell. If no one else is already working >>>>> on updating the stats widgets, I can take a stab at it. >>>> >>>> Statistics are definitely something where I'm open to new categories. We >>>> should make sure we understand how we want to visualize that - another sad >>>> story of me doing a poor job of creating a shared vision with the key >>>> developers and then seeing that implemented. >>>> So let's talk about what you want to show and how. >>> >>> 1) I see depth and temperature as the low-hanging fruit since they don’t >>> involve the issue with dives having multiple buddies or tags. They would >>> make a good first step since the same logic and visualization that is used >>> to split the yearly statistics into trips and types could be used with >>> depths and temperatures in buckets. Something like 10m buckets for max >>> depth and 5ºC for minimum temperature would make sense. This would provide >>> some nice additional stats with minimum effort. >>> >>> 2) Whether to do the statistics on the filtered divelist or the full >>> divelist would be the next question to answer. One option would be to add a >>> menu item below the “Yearly statistics” called “Filtered statistics.” When >>> that is fully functional, it could replace the “Yearly statistics” if we >>> decide it makes sense. >>> >>> 3) People and tags could be added next if we can agree on the logic of how >>> to handle dives with multiple people and/or tags. My choice would be that >>> the categorization would be for each person you dove with, even if that >>> means that a dive shows shows up in multiple people’s stats. For example, >>> if I dove with Bob 3 times and Jim 4 times and both Bob and Jim 2 times, >>> the stats would show that I dove with Bob 5 times and Jim 6 times, even >>> though the summary shows I only dove 9 times. The same logic would apply to >>> tags. >>> >>> 4) The presentation of the statistics could be addressed later. Some stats >>> lend themselves to a bar chart or line chart presentation. Having a >>> framework for graphical visualization of stats would be useful, but it is >>> probably beyond my capabilities at this point. >>> >>> Let me see if I can do a mockup of what I’m talking about for #1 and #2. >>> >>> -Doug >>> >>> >> > _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
