Patches to add Context Menu to Images

Guido Lerch guido.lerch at gmail.com
Tue Nov 3 14:41:16 PST 2015


Hi Robert

2015-11-03 21:34 GMT+01:00 Robert C. Helling <helling at atdotde.de>:

> Hi Guido,
>
> On 03 Nov 2015, at 17:21, Guido Lerch <guido.lerch at gmail.com> wrote:
>
> This set of patches enables users to use the mouse and a context menu to:
>
>
> I think the interference between these and my Drag and Drop patch should
> be very small, so yes, of course, go ahead, let’s sort this out together!
>
> For me the next step would be the possibility to shift the time of images
> in the profile using the mouse.
>
> 1. Add images from files/web
> 2. Delete selected images
> 3. Delete all images
>
>
>
> If there is no objection, I am going to work on a local file based
> management
> of images again that can be selected via the preferences, so people that
> don't
> want that don't have to.
>
>
> I must say, I am still not convinced about your „local file based
> management“ solution. It seems to me besides the actual copying of the
> files to a folder (possibly the magic dropbox or own cloud folder) this is
> a subset of what we already do with the image hashes. And there, when I
> wrote that, I decided that I would not do the coping as the cicurmstances
> where this makes sense (given the possible data size and issues of
> reediting etc) we should better let the user do this explicitly.
>

Maybe you and I need to sit together for me to better understand the
hashing.  In general I think ! I know what it's there for but this doesn't
solve
my dislike that i have to ask subsurface to find my moved images once I
have relocated them. I actually think, sorry, this is very user unfriendly.
I have tried it and dislike it.

Here is how I work ...
I come home from a day or multiple day trip, I select the appropriate dives
and I point it directly to my SD card, selecting what I would like
to keep. Those are dive related images, hence I have a dropbox folder for
it as I really want to save and secure them.
With my solution, I select all dives, select all the images and the nice
subsurface image handling saves the correct files to each dive.
This takes a while, I don't care...
Once done, I go through the dives and delete those images, I don' want,
typically duplicates as I am doing burst once in a while. My way
would check if the files are used in other dives and if not delete from the
managed location.
Result, I have all pictures I want in a managed location, I also have them
in the original location as my code would never delete in the original\
locations. Managed, selected, fine .. done. I leave the sync. to DropBox,
Box, Google Drive, whatever.

>
> Plus there is this proposal by Dirk, to sort this out once and for all in
> a way that is compatible with could saving. I think this whole context
> needs a bit more thinking before we can start implementing as otherwise we
> will very likely throw away stuff we write now or even worse run into a
> legacy problem.
>

I get that point too but ... cloud saving is resource intense and much
slower than local. I don't dispute what Dirk envisions but why not have
an easy approach, cheap, no GIT stuff and selectable by the user. We can
extend any time.
Today, without managing, handling images it's cumbersome IMHO. I don't get
the benefit of calculating hashes if the images are managed
upfront. Hashes are more like ... I lost them, where are they? Unless I
miss something ...
My 2 cents.


> Just my $.02.
>
> Best
> Robert
>
>


-- 
Best regards,
Guido
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20151103/b15cb8ea/attachment.html>


More information about the subsurface mailing list