Hi Dirk, I¹ve put some thoughts into this. Not an easy topic as people might have very individual requirements on this topic. I suggest to take a step-wise approach, determining who would benefit quickly depending on the complexity of the implementation.
Let me explain my case. * I love to take films and pictures * I¹d like to assign them to dives * I¹d like to use my mouse to add or delete them (have patches for this already) * I¹d appreciate if the loading doesn¹t take too long (no idea on how to do async loading yet with threads but would be interested to dig into) * I would like to have them stored in a way I can access them from different computers * I do NOT expect them to load on mobile. >From my perspective, implementing a V1, the easiest is to allow managing pictures ³locally² in the way I send a few test patches already. I don't know how Google drive or Box work in detail but I know with DropBox I can synchronise my pictures across computers and even on my iPhone. If we allow the copy process from the source medial (SD card for example) to a local DropBox location we already have achieved a lot. I have the patches running with the last master and it works very nicely. Files are copied automatically during the loading, the new location is stored based on the user preferences. Images that are used in multiple dives are not being physically deleted on delete. If the preference to manage images is switched off images are not deleted physically either and last but not least, images are not deleted if the managed location has changed. More comments below Guido From: subsurface <[email protected]> on behalf of Dirk Hohndel <[email protected]> Date: Thursday 22 October 2015 14:08 To: Subsurface Mailing List <[email protected]> Subject: storing pictures > So I've been thinking about this for a while and I'm not sure what we do > right now is the right thing after all. > > So when a user adds pictures to their dive file, the dive file itself > should contain information how to find the picture and (possibly?) a > thumbnail of the picture (so if the picture isn't available for whatever > reason, we can at least show a thumbnail. > > So what does "information how to find the picture" mean? > > - simplest case, it's a file:// url - i.e., where on my local computer > - of course it has a hash which allows us to find it again if it was moved > > But Subsurface should have a preference option that allows the user to > specify a network base way to store pictures as well could be done with radio buttons like O store locally O store remotely (e.g. unc path) > > - cloud storage: pictures are no longer stored as part of the users' > branch in the git repo - that makes remote operations over super > slow/bad networks harder and makes the first sync take forever. > Instead the cloud storage should allow users to upload their pictures > directly into their picture directory on the cloud server and then to > download them "on demand" (i.e., if the user clicks on a picture to see > the full sized version) - but of course look for a local cached copy, > first. So if I open my repo on my phone it only downloads the picture if > I tap on it (pictures currently aren't implemented there, anyway). Can¹t comment on this as I am not experienced enough > - Dropbox / Google drive / other shared storage mechanisma: allow in the > preferences to tell Subsurface how data can be uploaded / downloaded. > This can be as easy as a subdirectory of the "magic directory" that is > used for this cloud data storage. And then use hash-based names to find > the pictures there. This is what I played with > > Is this reasonable? What am I missing? I know that Guido has started to > look into this, as has Robert... please comment / make suggestions how the > idea can be improved. > > I want pictures to be easy to get to from any device, but I don't want > them to bloat the git repository as they do today. > > /D > _______________________________________________ > subsurface mailing list > [email protected] > http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface >
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
