SUMMARY When you create a file layer from the right click context menu in the layer stack. If the user edits the file layer and then saves and closes it , the file layer contents do not get updated in the original document unless it is closed and opened again. STEPS TO REPRODUCE 1. Open Krita and create new document 2. add a new layer scribble something on it and right click on it and go to convert > to file layer. save the file somewhere 3. now click on the folder icon besides this newly created file layer and when krita opens it edit it or scribble more on it. Then save and close it . 4. check the original document for changes OBSERVED RESULT File layer contents are not updated EXPECTED RESULT file layer should reflect the newly edited content SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.16.5 KDE Frameworks Version: 5.61.0 Qt Version: 5.13.0 Kernel Version: 5.2.13-arch1-1-ARCH OS Type: 64-bit Processors: 8 × Intel® Core™ i7-4790K CPU @ 4.00GHz Memory: 15.6 GiB of RAM
Using the latest 4.3.0-prealpha (git cb4306b) appimage, I find that the file layer contents in the original document/image are updated as soon as the opened file layer image-file (.png) has been edited and saved. I notice that the file layer .png file contains any off-canvas content and so can be larger than the original image size. Is it possible that you had a file layer .png opened that was bigger than the original document and you were making changes in a place that was off-canvas in the original image?
In my previous comment, I was working in a file I had already opened from disk. In this case, the original image is updated after the file layer has been edited and Saved. In the case you specified, for a new document, not saved, then yes, the file layer is not updated after the file layer image is edited and saved. In addition in this case, if I then close the opened file layer .png and save the original document, then reopen it, the file layer .png can't be found. Krita is looking for it at a 'mangled' version of the actual storage location. I can then manually specify the actual location and the situation is recovered from that point on.
Can you check with the right click context menu that you get in the layer stack. i noticed that a new file layer created from the contents of the file itself had this problem rather than the file that has been brought from outside. the problem happens specifically from the convert to file layer context menu
Yes, I used the convert to file layer option from the context menu on the layer. My initial Comment 1 was because I was working on an already opened .kra file and not a newly created document as you specified. My comment 2 notes the difference between those situations. Do you also see an attempt to reference the file layer .png file at a 'mangled' file location name in the situation I described? I wonder if this may be an interaction with my OS and DE (Debian 10 and MATE).
*** Bug 413894 has been marked as a duplicate of this bug. ***
I can also add that modifying the file layer using the "Folder" icon in the layers docker locks up the canvas of the image, so it becomes unresponsive.
Okay, locking problem is unrelated :)
Git commit a72eb7495b66edd923408ed8819b591890289b2f by Dmitry Kazakov. Committed on 31/07/2020 at 21:31. Pushed by dkazakov into branch 'master'. Fix update of file layers created via "Convert to" menu `FileSystemWatcherWrapper` works with absolute paths, but `KisSafeDocumentLoader` works with the original path as it was passed to the layer. We should unify these paths in `KisSafeDocumentLoader::fileChanged()`. The patch also fixes lost connections, when the file is temporary deleted (moved) and its recreation is delayed by something. Previously, FileSystemWatcherWrapper::slotFileChanged could just forget about it. Now it maintains a list of missing files in `m_lostFilesAbsenceCounter` and tries to reconnect to them with 200 ms intervals. PS: The tracked file may be removed/recreated because of QSaveFile functionality. M +5 -0 libs/global/kis_signal_compressor.cpp M +2 -0 libs/global/kis_signal_compressor.h M +62 -12 libs/ui/kis_safe_document_loader.cpp https://invent.kde.org/graphics/krita/commit/a72eb7495b66edd923408ed8819b591890289b2f
Git commit 1b912acc814f616772ef17a1a5020af257d45d51 by Dmitry Kazakov. Committed on 31/07/2020 at 21:39. Pushed by dkazakov into branch 'krita/4.3'. Fix update of file layers created via "Convert to" menu `FileSystemWatcherWrapper` works with absolute paths, but `KisSafeDocumentLoader` works with the original path as it was passed to the layer. We should unify these paths in `KisSafeDocumentLoader::fileChanged()`. The patch also fixes lost connections, when the file is temporary deleted (moved) and its recreation is delayed by something. Previously, FileSystemWatcherWrapper::slotFileChanged could just forget about it. Now it maintains a list of missing files in `m_lostFilesAbsenceCounter` and tries to reconnect to them with 200 ms intervals. PS: The tracked file may be removed/recreated because of QSaveFile functionality. M +5 -0 libs/global/kis_signal_compressor.cpp M +2 -0 libs/global/kis_signal_compressor.h M +62 -12 libs/ui/kis_safe_document_loader.cpp https://invent.kde.org/graphics/krita/commit/1b912acc814f616772ef17a1a5020af257d45d51
*** Bug 422375 has been marked as a duplicate of this bug. ***