Bug 185872

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