Max,
It was indeed an issue I had introduced :(
Anyway, now fixed. Thanks for reporting this issue.
Pascal.
--
Pascal Obry / Magny Les Hameaux (78)
The best way to travel is by means of imagination
http://v2p.fr.eu.org
http://www.obry.net
gpg --keyserver keys.gnupg.net --recv-key
Max,
> you did great work with the local caching,
Thanks.
> but I think you messed
> something up with the key bindings.
> Ctrl+d was duplicate before, now the "reset cache" button blinks if I
> hit ctrl+d. But the key bindings for the cache buttons are not in the
> prefs panel.
Indeed I can
On Thu 04 Jul 2013 09:06:04 PM CEST, Pascal Obry wrote:
>
> Another round in the local-copy support:
>
> Ok, here is a new version, since last time:
>
> - I have verified that moving a picture (local copy) in the map works fine
> - I have enabled the writing of .xmp for local copies
> - I have disa
Another round in the local-copy support:
Ok, here is a new version, since last time:
- I have verified that moving a picture (local copy) in the map works fine
- I have enabled the writing of .xmp for local copies
- I have disabled removing a file if some modification on the local copy
has been
Am Mittwoch, 3. Juli 2013, 21:26:38 schrieb Pascal Obry:
> Not really. Today the interface has only 2 buttons. One to set in cache
> and one to reset it. The sync is not part of the interface, the goal is
> to do whatever is needed for the user to not have to care for this.
Ok, so I am curious to
Roland,
> I just think that the autosync-on-start wouldn't be very obvious for the
> user.
> In case he doesn't know and he wants to sync the images with the external
> storage but keep them cached afterwards, he would first have to uncache them
> and recache them afterwards. Under the assump
Hi again,
Am Mittwoch, 3. Juli 2013, 20:28:59 schrieb Pascal Obry:
> We could have both but I would really prefer not having another button
> for this.
I just think that the autosync-on-start wouldn't be very obvious for the user.
In case he doesn't know and he wants to sync the images with the
Hi Pascal,
Hope you are fine with me adding my own opinion.
Am Mittwoch, 3. Juli 2013, 16:17:22 schrieb Pascal Obry:
> > You are taking for granted that the user will further develop the
> > image once the external drive is available.
>
> Right!
>
> > But it may not happening, even more in our
Hi Roland,
> Hope you are fine with me adding my own opinion.
Sure!
> I think it's essential that the user is not required to touch every single
> picture again just to export it to the external storage. Imagine a film strip
> of let's say 200 images which you edited offline and now want to s
Jose,
> You are taking for granted that the user will further develop the
> image once the external drive is available.
Right!
> But it may not happening, even more in our implementation in which as
> we are store the full raw image the user can even have exported and
> delivered the final imag
On Wed, Jul 3, 2013 at 3:51 PM, Pascal Obry wrote:
>
> Jose,
>
>> We have to think also about corner cases. To name a few:
>
> Sure! Devil are in the details :)
>
>> + What happens if the user caches some images, process them "offline"
>> and then plug the external storage back but forgets to syn
Jose,
> We have to think also about corner cases. To name a few:
Sure! Devil are in the details :)
> + What happens if the user caches some images, process them "offline"
> and then plug the external storage back but forgets to sync them back.
There is nothing to forget since there is nothing
We have to think also about corner cases. To name a few:
+ What happens if the user caches some images, process them "offline"
and then plug the external storage back but forgets to sync them back.
He will keep editing the cached images, or having the last edits in
the laptop, but those images won
Johannes,
> nice, thanks for that :)
Pull-request created. After a full review it looks ok to me.
Pascal.
--
Pascal Obry / Magny Les Hameaux (78)
The best way to travel is by means of imagination
http://v2p.fr.eu.org
http://www.obry.net
gpg --keyserver keys.gnupg.net --recv-key
On Tue, Jul 2, 2013 at 2:15 PM, Pascal Obry wrote:
> Johannes,
>
> > what do you need to store in the database? is it just one bit `cached' or
> > `not cached' ? i guess that could be hidden in the flags field..
>
> I've done that. Even simpler indeed!
>
> Thanks for the feedback. New version pus
Johannes,
> what do you need to store in the database? is it just one bit `cached' or
> `not cached' ? i guess that could be hidden in the flags field..
I've done that. Even simpler indeed!
Thanks for the feedback. New version pushed on GitHub.
I'll probably send a pull-request later today afte
Rob,
> Just a note of concern regarding the comment " when accessing a picture, if
> not found on the original storage we
> look into the cache". That sort of implies to me that the original image
> will be moved rather than copied to the cache device and then I get all sort
> of paranoid abou
Hi Ivan,
> really interesting feature!
Thanks!
> I fear I have lost an important step here:
> when my storage is unavailable and I work on local cache copy, how to
> resync xmp sidecar file to the storage, when again available?
> Does the "remove" button sync back to remote storage? Is there a w
net
Subject: Re: [darktable-devel] Support for local copy
Hi Pascal,
really interesting feature!
You can see my comment inline:
Il 02/07/2013 09:11, Pascal Obry ha scritto:
> [cut]
> *** Some usage scenario (based on my needs):
>
>- you import a set of pictures from the camera. You get
Hi Pascal,
really interesting feature!
You can see my comment inline:
Il 02/07/2013 09:11, Pascal Obry ha scritto:
> [cut]
> *** Some usage scenario (based on my needs):
>
>- you import a set of pictures from the camera. You get local copy
> of them before moving them in a RAID storage for sa
Another idea for local copy.
Imagine I have some images on a slow external drive (old 2GB USB 2.0,
network location over 10Mbit/s wire or whatever).
In this case, what I want is that any picture I edit is automagically
"checked out" into the local cache on my fast internal (possibly SSD)
drive
This feature kicks ass!
I've been thinking about a feature like this a year ago when I was
commuting a lot and used a tiny netbook to do some editing on the train.
Very cool you added this!
.mm
--
This SF.net email is s
Johannes,
> nice, that sounds really simple :)
Thanks! Indeed far more simple that I thought initially...
> what do you need to store in the database? is it just one bit `cached' or
> `not cached' ?
Right.
> i guess that could be hidden in the flags field..
Will look at this, it would be even
nice, that sounds really simple :)
what do you need to store in the database? is it just one bit `cached' or
`not cached' ? i guess that could be hidden in the flags field..
anyways, cool feature.
cheers,
-jo
On Tue, Jul 2, 2013 at 9:11 AM, Pascal Obry wrote:
> Some news about this work.
>
>
Some news about this work.
*** The context:
- this is mainly for netbook users I suppose. desktop should always
have access to the original pictures.
- having original pictures on the local hard drive of a notebook is
dangerous given the lifetime of an hard drive!
*** The goal:
- make it
25 matches
Mail list logo
