| Summary: | no warning if write permission is missing while commenting an image | ||
|---|---|---|---|
| Product: | [Applications] gwenview | Reporter: | augutus kling <augustus.kling> |
| Component: | general | Assignee: | Gwenview Bugs <gwenview-bugs-null> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | andrew.findlay, benni, hamboy95, kgw, myriam, px79, tagwerk19 |
| Priority: | NOR | ||
| Version: | 20.04.2 | ||
| Target Milestone: | --- | ||
| Platform: | Ubuntu | ||
| OS: | Linux | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=416258 | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
augutus kling
2006-09-03 18:17:18 UTC
I can still reproduce this bug in KDE 4.7.4/Gwenview 2.7.4 *** Bug 167066 has been marked as a duplicate of this bug. *** I can't reproduce this (Gwenview 4.10.1, Kubuntu 13.04). I can even add comments to read-only images. They seem to get stored by Nepomuk so no need to have write access to that file. Or am I missing something? If current versions of Gwenview store the comments in Nepmuk always, then this report is obsolete. Currently I do only have Gwenview 2.8.5 available and can't find image comments there at all. The closest thing I have is Plugins → Images → Metadata → Edit All Metadata… which also silently discards EXIF, IPTC and XMP data for readonly images. Can this be confirmed for current Gwenview versions? (In reply to comment #4) > If current versions of Gwenview store the comments in Nepmuk always, then > this report is obsolete. I'm not 100% sure, but it seems that gwenview has lost the functionality to change the jpeg comment. Everything you can edit in gwenview (rating, tags, description,...) is stored by Nepomuk. > Currently I do only have Gwenview 2.8.5 available and can't find image > comments there at all. The closest thing I have is Plugins → Images → > Metadata → Edit All Metadata… which also silently discards EXIF, IPTC and > XMP data for readonly images. Can this be confirmed for current Gwenview > versions? Yes, I can confirm this. As this is (probably) a bug in kipi plugins I'll assign this to kipi. *** Bug 312661 has been marked as a duplicate of this bug. *** Problem still present in Gwenview 4.14.3 on OpenSuSE 13.2 at 2015-04-02.
Tags, comments, and ratings are stored in extended file attributes so they cannot be saved if the file is not writeable.
Gwenview does not inform the user if it cannot write the attributes (it does output a message to stderr, but nothing shows in the GUI). It seems to cache the attributes for a while, so within the session where ratings etc are set it appears that they have been saved. This can lead to great frustration and waste of time.
To see what is going on, use:
getfattr -d <filename>
Preferred solution: show an error in the GUI if attributes cannot be saved.
related to last comment this file is not relevant of Metadata kipi tool. This one only play with file metadata, not nepomuk/baloo. Gilles Caulier Thank you for the bug report. As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved. Bug is still present in Gwenview 20.04.2 as shipped with OpenSuSE Leap 15.2. No useful error messages (even to stdout). Ratings seem to be cached within the session then lost. Description is lost as soon as you move to another image or change the star rating. |