When annotating a stack that is collapsed all images in the stack should be annotated, not just the topmost one. (At least that was what I expected would happen when I tried it the first time)
Created attachment 70580 [details] Add images of a collapsed stack to ThumbnailWidget::selection()
The expansion of the selection should be dependent on the action that is being performed. I like it when tagging collapsed stack tags all images in the stack but it should not open each and every image on Viewer. E.g. I have the developed images of RAW files as head of stack and normally want to see only those when viewing images and generating HTML pages for others to see. Thus only the stack head should be used. The current implementation also tags only single images when tagging straight from the Viewer. (When images to be viewed are selected, only the one selected image is tagged, not the whole stack as stack is implicitly expanded. When no images are selected - that is all the images in current thumbnail set are being viewed, Viewer started by hitting return key - only the top image of stack is tagged.)
Thanks for pointing out the problem with the Viewer. I can see two possible solutions to that: either make the Viewer use a new method unexpandedSelection() instead of selection() , or add a GUI-element in the Thumbnail view to toggle the behaviour according to ones need (this would work even for people who use stacking in other ways then the one you described). In my own (biased) view, I would still want to add this patch, because without it such basic things like tagging and drag&drop don't work correctly. Miika, what do you think about the two proposed remedies for your use-case? Do you have other ideas, still? > The current implementation also tags only single images when tagging straight from the > Viewer. (When images to be viewed are selected, only the one selected image is tagged, not > the whole stack as stack is implicitly expanded. When no images are selected - that is all the > images in current thumbnail set are being viewed, Viewer started by hitting return key - only > the top image of stack is tagged.) Can you explain this a little more in detail? As I see it, the patch doesn't change anything in the Viewer behaviour, does it? Once you start the Viewer, with the current patch the stacks are already expanded. (And since you don't have any visual feedback in the Viewer, if the current image belongs to a stack, it would be surprising if some expansion happened when tagging from the Viewer).
On Tue, Apr 24, 2012 at 2:00 AM, Johannes Zarl <isilmendil@gmx.net> wrote: > --- Comment #3 from Johannes Zarl <isilmendil@gmx.net> --- > Thanks for pointing out the problem with the Viewer. I can see two possible > solutions to that: either make the Viewer use a new method > unexpandedSelection() instead of selection() , or add a GUI-element in the > Thumbnail view to toggle the behaviour according to ones need (this would work > even for people who use stacking in other ways then the one you described). > > In my own (biased) view, I would still want to add this patch, because without > it such basic things like tagging and drag&drop don't work correctly. > > Miika, what do you think about the two proposed remedies for your use-case? Do > you have other ideas, still? With the original way KPA works I can easily expand stacks if I want to view each image in the Viewer or generate HTML pages with them. So personally I do not see need to make this feature configurable. To make it behave differently depending on the context, you could also add a parameter to the selection() function to choose the mode of operation. However, I also do want to see this change when tagging stacked images. >> The current implementation also tags only single images when tagging straight from the >> Viewer. (When images to be viewed are selected, only the one selected image is tagged, not >> the whole stack as stack is implicitly expanded. When no images are selected - that is all the >> images in current thumbnail set are being viewed, Viewer started by hitting return key - only >> the top image of stack is tagged.) > > Can you explain this a little more in detail? As I see it, the patch doesn't > change anything in the Viewer behaviour, does it? Once you start the Viewer, > with the current patch the stacks are already expanded. (And since you don't > have any visual feedback in the Viewer, if the current image belongs to a > stack, it would be surprising if some expansion happened when tagging from the > Viewer). With the patch applied I expected that when I tag images from the Viewer, the whole stack would have been tagged, but it was not. However, if the above change is made, the Viewer should behave as I would expect it to behave. However, a stack indicator e.g. in Viewer's InfoBox might be a good idea. The change in Viewer behavior with the patch is that the Viewer displays each and every image within the selected stacks. And before it only displayed the top image. (Unless of course the stack was expanded in thumbnail view.) miika
Created attachment 70753 [details] [PATCH 1/2] Allow inclusion of collapsed stacks for selection.
Created attachment 70754 [details] [PATCH 2/2] Only use head of collapsed stacks for Viewer. This patch should fit the use-case described by Miika (old behaviour is more intuitive for Viewer).
Git commit 9d8b73d2ec0e121e7a44286db93789dc235fd1a5 by Miika Turkia, on behalf of Johannes Zarl. Committed on 29/04/2012 at 15:34. Pushed by mturkia into branch 'master'. Allow inclusion of collapsed stacks for selection. By default, ThumbnailFacade::selection now includes images of collapsed stacks, not just the stack head. You can revert to the old behaviour by using ThumbnailFacade::selection(ThumbnailView::NoExpandCollapsedStacks) M +2 -2 ThumbnailView/KeyboardEventHandler.cpp M +1 -1 ThumbnailView/SelectionInteraction.cpp M +1 -1 ThumbnailView/SelectionMaintainer.cpp M +1 -1 ThumbnailView/ThumbnailDND.cpp M +3 -3 ThumbnailView/ThumbnailFacade.cpp M +1 -1 ThumbnailView/ThumbnailFacade.h M +29 -6 ThumbnailView/ThumbnailWidget.cpp M +1 -1 ThumbnailView/ThumbnailWidget.h M +1 -0 ThumbnailView/enums.h http://commits.kde.org/kphotoalbum/9d8b73d2ec0e121e7a44286db93789dc235fd1a5