Silly problem with dive sites and GPS downloading
glance at acc.umu.se
Sun Sep 23 10:48:56 PDT 2018
On 23 September, 2018 - Berthold Stoeger wrote:
> Hi Linus,
> On Sunday, 23 September 2018 00:17:38 CEST Linus Torvalds wrote:
> > On Sat, Sep 22, 2018 at 2:35 PM Linus Torvalds
> > <torvalds at linux-foundation.org> wrote:
> > > But it's basically unfixable as it is now. As long as a "struct dive"
> > > contains that broken "uint32_t dive_site_uuid;" as the dive site
> > > descriptor, we *have* to create the dive site this way.
> > Side note: one possible solution is to get rid of that dive_site_uuid,
> > and replace it with a "struct divesite *ds" instead.
> This is actually on my TODO-list, notably when making import-dives undo-able.
> Just like on undo/redo of add-dives we have to remove/add implicitly generated
> dive-trips, on undo/redo of import-dives we'll have to remove/add new dive-
> I don't see the UI part as a problem. Doing away with the "uniq-id" of dives
> on desktop was quite easy and I think the same is true for dive-site uuids.
> Not sure you want to wait that long, though.
My first thought when I read Linus issues I thought this problem would
be solvable via your undo work.
Maybe we can focus on getting rid of dive_site_uuid first, to solve
this specific issue, and look at the general undo later.
Another thought was that the DLF-import tingie also just blindly creates
dive sites when it sees a gps coordinate. Any issues we have with the
Garmin download, is probably the same there.
Quite a bit OT, but continuing in that tangent, it might be time for the
DLF thingie to grow up and become a proper libdivecomputer backend,
instead of the subsurface specific importer we got right now. All the
usb-file-import infrastructure got created for the Garmin downloader.
Anton Lundin +46702-161604
More information about the subsurface