Doug, On Sonntag, 14. April 2019 18:43:33 CEST Doug Junkins wrote: > I’ve been looking at the code to try to figure out the best way to add the > capability to import an XML file of dive sites to the Subsurface dive site > table. Looking at the existing dive log import code, it may be possible to > simply modify the dive log import code to be able to process an XML file > that only includes dive sites. > > This would involve modifying the ‘process_imported_dives’ function in > core/divelist.c to not filter sites that are not used by the imported dives > and to process files even if the number of imported dives is zero. This > would keep the XML import code consolidated in one place, but it would blur > the separation of dive processing and dive site processing that we are > trying to create. > > The other alternative is to replicate the ‘process_imported_dives’ function > as something like ‘process_imported_divesites’ in core/divesites.c and add > a new, separate menu option to import dive site XML files, but then there a > lot of duplicate code to maintain.
I think I would prefer the second option. Conceptually, these are different things and we are more flexible that way. We might present the user different merging options (determine duplicates by name, by distance), prefer data from old or imported dive sites, etc. The whole process_imported_divesites logic is only a few lines. I wonder if we need such a function at all. Checking for duplicates could be done in the UndoCommand. If you give me a day or two I will write such a command. The only thing to do then is to get the parser to return a dive_site_table. Berthold _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
