| Summary: | GROUP : grouped pictures are not processed together except the first one (Renaming, Tags, Metadata, Labels, etc.) | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | philippe.quaglia |
| Component: | Albums-ItemGroup | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | caulier.gilles, flo.hennig, freisim93, janox, metzpinguin, mnaugendre |
| Priority: | NOR | ||
| Version: | 5.0.0 | ||
| Target Milestone: | --- | ||
| Platform: | Ubuntu | ||
| OS: | Linux | ||
| Latest Commit: | http://commits.kde.org/digikam/5f6aa8656cf333e8949b10660407e8c8a0c0cc4f | Version Fixed In: | 5.4.0 |
| Sentry Crash Report: | |||
|
Description
philippe.quaglia
2012-02-21 19:24:25 UTC
IMO, intuition is not clear as to whether grouped images are affected or not. It is possible to add additional menu entries to the popups that appear on drag and drop, but there will be some smaller complications with details. Alternatively, we can add a setup option if grouped images shall be affected by operations on the lead image. This had the advantage of clearing the situation for rating etc. as well. It gets a bit more complex: What about the desc edit sidebar? Kipi plugins? I believe a solution with one setup option for metadata operations can be enough, for all other cases, only the visible images will be affected, the user can always expand all groups in the view. Opinions? Hello, when dragging a tag to a picture, there is a pop-up menu asking if the tag should be applied to the current picture or to all the pictures. There may be an additionnal question when we are above grouped pictures. I'm not skilled enough to see the other induced complications. However your proposal of a default setting may do the job as well. Regards. I initially planned to extend this context menu, but there are quite a few ways to edit metadata without drag and drop, be it the right sidebar, the context menu, or the icon view overlays for e.g. rating. For all these, the dragdrop menu approach will not work, or even raise the question which scope the operation actually has. There's also some implications case of a tag dragged on empty space or on a selection of pictures, where we currently offer three possibilities in the menu. And I have the reverse problem: having removed tags from grouped pictures, it appears that only the 'head of group' has been affected. So these tags are still assigned to pictures that I cannot find, as they are hidden. *** Bug 249302 has been marked as a duplicate of this bug. *** *** Bug 362411 has been marked as a duplicate of this bug. *** This file still valid with last digiKam 5.0.0 ? Gilles Caulier Yes, I guess it is still valid, the behaviour is still exactly the same. Also still valid in version 5.1.0. Git commit 5f6aa8656cf333e8949b10660407e8c8a0c0cc4f by Maik Qualmann. Committed on 08/11/2016 at 21:11. Pushed by mqualmann into branch 'master'. apply patch #102005 from Simon Frei to adjust grouping behavior FIXED-IN: 5.4.0 M +2 -1 NEWS M +1 -1 app/items/digikamimageview.cpp M +29 -18 app/items/imagecategorizedview.cpp M +6 -3 app/items/imagecategorizedview.h M +0 -27 app/items/imageviewutilities.cpp M +12 -3 app/views/digikamview.cpp M +96 -49 app/views/tableview/tableview.cpp M +10 -4 app/views/tableview/tableview.h M +0 -24 app/views/tableview/tableview_model.cpp M +0 -2 app/views/tableview/tableview_model.h M +13 -0 libs/database/item/imageinfolist.cpp M +2 -1 libs/database/item/imageinfolist.h M +1 -0 libs/models/imagefiltermodel.h M +0 -1 libs/tags/tagslineeditoverlay.cpp http://commits.kde.org/digikam/5f6aa8656cf333e8949b10660407e8c8a0c0cc4f |