On Sat, Feb 14, 2015 at 11:02:47AM +0100, Robert C. Helling wrote: > Hi, > > now, after 4.4 is out, might be a good time to improve the way we store > images. Here are some thoughts as how to proceed. Before I start coding I > would like to hear your comments (and help is of course appreciated). > > Currently, we store a local filename (with absolute path) in an event that > represents the image. This is of course not portable when you have several > computers where your images reside at different paths. And you also lose your > dive-image associations when moving he image files around on the file system. > > One could try to implement some “image base directory” plus relative path > kind of thing but I guess that is quite fragile and becomes complicated at > least when different OSes are involved. > > So my proposal would be the following: > > 1) We keep the file name (and this is how we present a file to the user) but > now interpret it as “original file name”. > > 2) Upon successfully loading an image from that path we compute a hash of the > image file and store that hash as well with the event (maybe escaped into the > filename since there is only a single string).
We can always change the syntax. Would it make sense to store three strings? picture-filename path hash > 3) We maintain a dictionary (QHash) where the image hashes are the keys and > local filenames are the values. That QHash gets loaded at startup and saved > upon quit to a local file (and is not dive log specific but refers to a > computer or maybe to a user of that computer). What would be file > name/location for that file. Is there a per user subsurface directory? I hadn't thought about making this machine specific. Hmm, that's an interesting idea. Not sure where we would store this... I guess we could put it in the default directory? Just like Linus did with the git files. > 4) We provide a function that scans a directory (and subdirectories) for > image files and inserts those to the QHash as well (possibly overriding > keys). > > 5) When loading an image with the original file name fails, we look up the > hash in the QHash and load that file instead. We do _not_ check that the hash > is correct (as the image might have been edited). Also interesting logic. > Combining 4) and 5) one can use the same image files in a totally different > directory structure (e.g. keep all images asa back up in a single directory) > on a different computer and still display them with the dive. > > 6) Whenever we successfully load an image to display, we compute the hash and > insert it in the QHash. So the QHash will then have possibly multiple hashes for the same image. Also interesting idea. > 7) Besides a fileselector for adding new images, the user can also enter a > URL. That URL can either relate directly to an image or to an html where we > use all <img> tags. If those non-local files match times to be associated to > a dive, we download them to a local image cache and add the local path in the > cache to the QHash. We use the URL to the image file as “original file name” > (possibly with a different event for non-local images). We provide some way > to purge that cache. OK And yes, I have started using Qt for core functionality where the advanced data structures help us. There are quite a few such function in qthelper.cpp for example /D _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
