Bug 145253 - Disable edit metadata menu when image is read-only
Summary: Disable edit metadata menu when image is read-only
Status: RESOLVED WORKSFORME
Alias: None
Product: digikam
Classification: Applications
Component: Usability-Menus (show other bugs)
Version: 0.9.2
Platform: Debian stable Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-05-10 04:32 UTC by Brian Remedios
Modified: 2022-12-06 05:18 UTC (History)
1 user (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 Brian Remedios 2007-05-10 04:32:18 UTC
Version:           0.9.2-SVN (using KDE KDE 3.5.5)
Installed from:    Debian stable Packages
OS:                Linux

Digikam allows me to edit EXIF & IPTC tags even though the target image is read-only. In fact I can attempt to do a number of modifications via the Image submenu on read-only images.

When metadata edits are made to read-only images within the date folders they will seem to 'disappear' from them for some reason although they just 'flash' in the regular albums.

Digikam needs to either disable the edit-related menu choices (preferred) or display an error message after the fact telling the user why the changes can't be saved.
Comment 1 Mikolaj Machowski 2007-05-10 17:15:09 UTC
> Digikam needs to either disable the edit-related menu choices
> (preferred) or display an error message after the fact telling the user
> why the changes can't be saved.


Only metadata edits I hope. IE could be used to see "real photo", also
preview of some effects can be useful, not mentioning "Save as..."
option. Also some metadata can be saved in database and user may want to
make those corrections without possibility to change image itself.

I could be made only by changes in db structure taking notice about
status of image if it is read only. Also some visual feedback for user
could be useful. Already plethora of possibilities regarding changing of
metadata and syncing it can create problems.
Comment 2 Brian Remedios 2007-05-10 17:40:37 UTC
I understand how we can save metadata changes to the DB and/or the image itself so perhaps that need to be made more obvious to the user. If an image is read-only and the user edits the metadata and clicks Save then digikam could let the user know about this and offer to save the info to the DB and place a tiny alert flag beside the thumbnail denoting the inconsistency that needs to be resolved later.

The casual user isn't really aware of the DB in the background that helps out in so many areas.

Also, if I'm changing permissions files in the OS outside of a file browser I've noticed that the browser GUI tracks changes and updates the icons fairly quickly. I'm not sure how the notification mechanism works but could we leverage the same capability in Digikam to provide a real-time indicator of the permissions beside the thumbnail?
Comment 3 caulier.gilles 2013-11-25 17:05:08 UTC
Brian,

Since digiKam support XMP sidecar, all file are writable around metadata. So for me the approach will be a little bit different here...

Gilles Caulier
Comment 4 Justin Zobel 2022-11-06 09:25:04 UTC
Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version?

If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
Comment 5 Bug Janitor Service 2022-11-21 05:11:56 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 6 Bug Janitor Service 2022-12-06 05:18:28 UTC
This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!