I'm also interested in such a feature!
-F
On Wed, Oct 15, 2014 at 9:19 PM, Taylor Braun-Jones <[email protected]>
wrote:
> On Wed, Oct 15, 2014 at 8:15 AM, Khlebnikov, Rostislav <
> [email protected]> wrote:
>
>> Hi Miklos,
>>
>> This goes in line with my earlier email regarding the incremental saving
>> (meaning saving only the stuff that changed since the scene was opened). I
>> believe that implementing this is relatively important before implementing
>> auto-save as it will speed up the saving process significantly and will
>> reduce load on the hard drive. At least in my case where 80% of the project
>> file is the original image data that never changes.
>>
>> I will start working on this very soon - I wanted to wait until the new
>> release but likely I will just start working on this in the current master
>> if it builds correctly.
>>
>> I guess we could work on this in parallel. It'd be great if you could
>> figure out how to handle new changes to data nodes while they are being
>> auto-saved in a separate thread. Should a data clone be made (likely too
>> much memory consumption)? Should the writers support interruption of the
>> saving process? What do you think?
>>
>> I would then concentrate on supporting the separate "open project" and
>> "import data" actions, support for time stamp tracking to detect what
>> really changed, and re-packing only changed data on save.
>>
>> How I saw the auto-save working then was - "open project" - save the
>> location of temp folder used for scene loading as well as record that in
>> the persistent storage using QSetting-like mechanism. During work - save
>> the changes to this folder (will also speed up the normal saving process as
>> only changes since last auto save would have to be written to temp folder
>> and packing would have to be performed). On fresh start - check if the exit
>> was clean and if temp folder saved in persistent storage is available - try
>> to recover the scene from there.
>>
>> That's a big email I wrote :) Anyway - it'd be nice to hear from you as
>> well as MITK core developers with thoughts on this.
>>
>> Rostislav.
>>
>> > On 15 Oct 2014, at 12:38, "Miklos Espak" <[email protected]> wrote:
>> >
>> > Hi All,
>> >
>> > is anybody interested in an auto-save feature for MITK?
>>
>
> Yes, this is something we are interested in.
>
> Rostislav, your design proposal sounds good to me. It's basically in line
> with what I had in mind too.
>
> Regards,
> Taylor
>
>
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://p.sf.net/sfu/Zoho
> _______________________________________________
> mitk-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mitk-users
>
>
--
Félix C. Morency, M.Sc.
Plateforme d’analyse et de visualisation d’images
Centre Hospitalier Universitaire de Sherbrooke
Centre de recherche clinique Étienne-Le Bel
Local Z5-3031 | 819.346.1110 ext 16634
------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
_______________________________________________
mitk-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mitk-users
