request for comments: suggest flow for saving to cloud storage

[Dirk Hohndel]

Hi

We have a somewhat silly issue where it is very easy to overwrite the
cloud storage file. If a user enters credentials on a new computer and
then, once they are verified, hits "save to cloud" the (empty) dive log
gets saved to the cloud. Similarly, if you close the current dive file
and then click "save to cloud", again the dive log gets overwritten.

Of course, it isn't lost, this is git after all, but this is extremely
hard to recover from for a typical user.

Here's an idea (based on a conversation with Linus), in two flavors:

Plam A: "save to cloud" is grayed out unless you first "open cloud
storage".  And it gets grayed out again once you close the dive file.

this of course leaves one interesting issue: how do you get your XML file
saved into the cloud (so an existing user who choses to switch to cloud
storage).

The obvious (??) answer is:
- open cloud storage (which is empty, presumably); this will first close
  any file you may have open
- IMPORT the XML file (which adds it to the empty dive log)
- save to cloud (which is now available since we first opened cloud
  storage)

That does seem awkward and strange. We looked at other ideas to check if
the transaction was actually deleting a lot / many / all / some dives and
they all had technical flaws and challenges that were really hard to work
around; this one is at least logical and straight forward.


Plan B: if the current dive file wasn't "opened from cloud storage",
change the text of the menu option from "Save to cloud storage" to
"Overwrite cloud storage" and add a confirmation dialog in that case.


This adds more UI changes (sorry, Willem) but seems slightly less awkward.

I'm open to other ideas as well.

There is an issue on GitHub that describes this, but internet on Bonaire
right now isn't cooperating. I hope I'll get this email out, but most web
site interactions have timed out for the last half hour or so.

/D