The current features / requirements sound good to me, too.
Best Regards,
Ingmar
"Félix C. Morency" <[email protected]>schrieb:
I'm also interested in such a feature!-F
------------------------------------------------------------------------------ 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
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
