OK. I just submitted a pull request on the monster branch to add Option 1 below. I’ll work on a combination of options 2 and 3 once I have the dive site import working. At least there is something there to get started with so I can test the import function.
Regarding the import, I’m thinking about having a checkbox that allows you to ignore sites with X meters (to be defined in an input box) from an existing dive site, but I’m wondering if that should be a silent ignore, or should there be a log visible showing whether each site was imported or ignored. Or, alternatively, do I replicated the functionality to import dives from a dive computer where each site to be imported needs to be selected before executing the import? -Doug > On Apr 10, 2019, at 8:28 AM, Dirk Hohndel <[email protected]> wrote: > > On Sat, Apr 06, 2019 at 12:52:59PM -0700, Doug Junkins wrote: >> I’ve been thinking about the code to export dive sites to an XML file and >> wanted to get feedback on the three approaches I see as options: >> >> 1) Add a radio button to the Export dialog that selects “Subsurface dive >> sites XML”. The “Selected dives” or “All dives” selection would work to >> export either all of the dive sites in the table or just those associated >> with the selected dives. The upside of this is that it is very simple to >> implement (to be honest, I’ve already done it, but I’m not convinced it is >> the right long term answer.) The downside is that there is no way to export >> dive sites that are not yet associated with a dive unless you dump all dive >> sites. > > I think this is a logical extension of what we have - but it continues to > treat dive sites as second class entities. > >> 2) The second option is to add an “Export dive site” button to the “Dive >> site management” form that Berthold added for the dive site and undo branch. >> This would allow the export of the individual dive sites, whether or not >> there is a dive associated with them yet. An “Export all dive sites” button >> could also be added to the Dive sites tab next to the existing “Purge unused >> dive sites” button. >> >> 3) The third option is to add a selection box to the table on the Dive sites >> tab that allows you to select a set of dive sites that you want to export >> and then a button that exports the selected dive sites. A toggle button to >> toggle all sites on or off could be included as well. This offers the most >> flexibility to select exactly which sites you want in the XML file and >> avoids having a lot of individual files if you’re exporting several sites. > > I think a combination of 2) and 3) is what we really want. If dive sites > are first class citizens, then we need to be able to select one, some, or > all of them in the dive site list and then export those. > >> I’m leaning towards the last option. It is probably also the most >> challenging for me to code given my limited Qt experience, but I’m willing >> to take a stab at it. > > Frankly, I'd start with 1) simply because it's consistent with what we > have and in a pinch it gives most users what they need. If you export all > dive sites then it's fairly easy to import the ones that you want into a > different dive log. > > Once that works, I'd tackle the additions to the UI to be able to select > which dive sites to export. I'm happy to help with the Qt side of that > (and I'm sure that Berthold would say the same). > > /D
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
