Bug 411790 - File layers don't refresh if they are created from the convert context menu in layer stack.
Summary: File layers don't refresh if they are created from the convert context menu i...
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: Layer Stack (show other bugs)
Version: git master (please specify the git hash!)
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Dmitry Kazakov
URL:
Keywords:
: 413894 422375 (view as bug list)
Depends on:
Blocks:
 
Reported: 2019-09-10 11:36 UTC by Raghavendra kamath
Modified: 2020-08-01 10:49 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Raghavendra kamath 2019-09-10 11:36:03 UTC
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
Comment 1 Ahab Greybeard 2019-09-13 13:34:33 UTC
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?
Comment 2 Ahab Greybeard 2019-09-13 14:09:46 UTC
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.
Comment 3 Raghavendra kamath 2019-09-13 14:14:31 UTC
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
Comment 4 Ahab Greybeard 2019-09-13 14:59:09 UTC
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).
Comment 5 wolthera 2020-04-25 09:43:35 UTC
*** Bug 413894 has been marked as a duplicate of this bug. ***
Comment 6 Dmitry Kazakov 2020-07-31 07:25:38 UTC
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.
Comment 7 Dmitry Kazakov 2020-07-31 08:26:02 UTC
Okay, locking problem is unrelated :)
Comment 8 Dmitry Kazakov 2020-07-31 21:39:11 UTC
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
Comment 9 Dmitry Kazakov 2020-07-31 22:10:30 UTC
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
Comment 10 Dmitry Kazakov 2020-08-01 10:49:34 UTC
*** Bug 422375 has been marked as a duplicate of this bug. ***