SUMMARY Comic manager removes the page after saving that file. You can add the page back in as it still exists in the page folder. But will continue to be removed every time you save. STEPS TO REPRODUCE 1. Create multiple pages in comic manager 2. Open one page, draw something and save OBSERVED RESULT That page will save, but disappear from the manager. EXPECTED RESULT Page is saved and stays in order in the comic manager. SOFTWARE/OS VERSIONS Windows: 10 macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
So, this is probably related to https://bugs.kde.org/show_bug.cgi?id=389544 The code is setup for handling Krita's backup system(which is what is getting the pages removed, because they kind of get renamed and the file watching system then gets confused), which works on Linux, but on windows it doesn't work for file layers, and thus it doesn't work for this system either. Either we figure out why this is broken on Windows(as we need to fix the other bugs as well some time), or I need to hack together my own filesystemwatcher to ensure pages are updated appropriately and you won't be able to accidentally open removed pages.
*** Bug 409307 has been marked as a duplicate of this bug. ***
Git commit ff338de7354fc170645af1a435267d1024546654 by Wolthera van Hövell tot Westerflier. Committed on 04/09/2019 at 16:02. Pushed by woltherav into branch 'master'. Possibly fix File Layer loading and comics manager page updating on windows. Windows has a pretty slow file system, which means when we check whether our updated file exists, windows hasn't gotten to renaming it yet, making Krita think there's no file at all... So this puts a little bit of a delay in our two checks of whether the file still exists and needs to be readded to the filesystemwatcher again. This currently works as expected on Linux, now we need to test if it works on Windows. Related: bug 389544 M +8 -4 libs/ui/kis_safe_document_loader.cpp M +11 -3 plugins/python/comics_project_management_tools/comics_project_manager_docker.py https://invent.kde.org/kde/krita/commit/ff338de7354fc170645af1a435267d1024546654
I can confirm this is fixed in today's Krita: Next. So for next time, whenever we use a QFileSystemWatcher in combination with Krita, we will need to remember that not just do we need to double check that the file exists(due the renaming to backup system we have), but also to delay this check about 100 to 200 milliseconds, because Window's filesystem is too slow. If you still see this happening with today's Krita: Next, don't hesitate to reopen this report.
Git commit dfbd4763c44ebfd1846fd2d8f26fca74fe99822e by Wolthera van Hövell, on behalf of Wolthera van Hövell tot Westerflier. Committed on 10/09/2019 at 10:32. Pushed by woltherav into branch 'cherry-pick-ff338de7'. Possibly fix File Layer loading and comics manager page updating on windows. Windows has a pretty slow file system, which means when we check whether our updated file exists, windows hasn't gotten to renaming it yet, making Krita think there's no file at all... So this puts a little bit of a delay in our two checks of whether the file still exists and needs to be readded to the filesystemwatcher again. This currently works as expected on Linux, now we need to test if it works on Windows. Related: bug 389544 (cherry picked from commit ff338de7354fc170645af1a435267d1024546654) M +8 -4 libs/ui/kis_safe_document_loader.cpp M +11 -3 plugins/python/comics_project_management_tools/comics_project_manager_docker.py https://invent.kde.org/kde/krita/commit/dfbd4763c44ebfd1846fd2d8f26fca74fe99822e