Created attachment 122508 [details] The system information bug report during testing of 4.2.5 SUMMARY Autosave will only save a file once per manual save after the specified time increment. Does not occur in versions 4.2.4 or lower. STEPS TO REPRODUCE 1. Manually Save file 2. Make changes to the document 3. Wait for x minutes to pass 4. Document will save 5. Make additional changes 6. wait x more minutes without manually saving 7. Autosave file is not replaced with an updated version 8. lose ur data if krita crashes :') OBSERVED RESULT An outdated autosave file near to the time the user last saved. EXPECTED RESULT An updated autosave with the most recent changes to the document within x minutes SOFTWARE/OS VERSIONS Windows: Windows 10 home v17763.678 macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION tiar was very helpful in getting me to this point thank you :)) I'm not super pressed to get the most recent krita update, now knowing I can just install an older version to fix this issue.
Eeek... This really bad.
Git commit a970b3a39af43f81bce78e45ee33fda2b8ce2740 by Agata Cacko. Committed on 10/09/2019 at 00:22. Pushed by tymond into branch 'krita/4.2'. Revert "Remove KisTool::notifyMdified" This reverts commit 8ef85fdd39aef257ae03a4fe07e9d8c92003e177. This commit fixes issue with autosave only saving once per manual save. Possibly it also fixes the issue with editing time being way lower than expected. --- Mentioned commit removed sending signal KisImage->notifyModified() by KisFreehandTool. Turned out that signal was important for autosave to work correctly and _possibly_ for counting time spent on the painting. Theoretically this signal should be also sent by strokes, rendering sending signal here redundant (hence the previous commit with "It is not used anymore" message). This requires further investigation and then recommitting these changes after making sure all logic is performed as before. Looks like the course of action with the signal from the Freehand tool was as follows: Freehand Tool sends ModifiedSignal -> Image Signal Router sends sigImageModified() -> KisDocument catches it and calls setModified( undoStackNotEmpty ) -> KisDocument does a lot of logic and then sends modified() Supposedly strokes call KisDocument::setModified(...), at least on master. I can't confirm it because I didn't check the relevant code yet. But if that's true, that should be enough - all relevant logic happens inside this function. On the other hand, practice seems to prove otherwise... M +7 -0 libs/ui/tool/kis_tool.cc M +3 -0 libs/ui/tool/kis_tool.h M +1 -0 libs/ui/tool/kis_tool_freehand.cc https://invent.kde.org/kde/krita/commit/a970b3a39af43f81bce78e45ee33fda2b8ce2740
Git commit d0602e6382bb901900decd6f6e42658b3277190e by Agata Cacko. Committed on 14/09/2019 at 14:30. Pushed by tymond into branch 'master'. Revert "Remove KisTool::notifyMdified" This reverts commit 8ef85fdd39aef257ae03a4fe07e9d8c92003e177. This commit fixes issue with autosave only saving once per manual save. Possibly it also fixes the issue with editing time being way lower than expected. --- Mentioned commit removed sending signal KisImage->notifyModified() by KisFreehandTool. Turned out that signal was important for autosave to work correctly and _possibly_ for counting time spent on the painting. Theoretically this signal should be also sent by strokes, rendering sending signal here redundant (hence the previous commit with "It is not used anymore" message). This requires further investigation and then recommitting these changes after making sure all logic is performed as before. Looks like the course of action with the signal from the Freehand tool was as follows: Freehand Tool sends ModifiedSignal -> Image Signal Router sends sigImageModified() -> KisDocument catches it and calls setModified( undoStackNotEmpty ) -> KisDocument does a lot of logic and then sends modified() Supposedly strokes call KisDocument::setModified(...), at least on master. I can't confirm it because I didn't check the relevant code yet. But if that's true, that should be enough - all relevant logic happens inside this function. On the other hand, practice seems to prove otherwise... M +7 -0 libs/ui/tool/kis_tool.cc M +3 -0 libs/ui/tool/kis_tool.h M +1 -0 libs/ui/tool/kis_tool_freehand.cc https://invent.kde.org/kde/krita/commit/d0602e6382bb901900decd6f6e42658b3277190e