Bug 185872 - Annotating a collapsed stack should annotate all images in the stack
Summary: Annotating a collapsed stack should annotate all images in the stack
Status: RESOLVED FIXED
Alias: None
Product: kphotoalbum
Classification: Unclassified
Component: Backend (show other bugs)
Version: SVN trunk (KDE4 version)
Platform: Unlisted Binaries Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: KPhotoAlbum Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-03-01 13:22 UTC by Jesper Pedersen
Modified: 2012-05-06 05:32 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Add images of a collapsed stack to ThumbnailWidget::selection() (1.93 KB, patch)
2012-04-22 23:49 UTC, Johannes Zarl-Zierl
Details
[PATCH 1/2] Allow inclusion of collapsed stacks for selection. (9.97 KB, patch)
2012-04-29 14:29 UTC, Johannes Zarl-Zierl
Details
[PATCH 2/2] Only use head of collapsed stacks for Viewer. (1.86 KB, patch)
2012-04-29 14:33 UTC, Johannes Zarl-Zierl
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jesper Pedersen 2009-03-01 13:22:53 UTC
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)
Comment 1 Johannes Zarl-Zierl 2012-04-22 23:49:18 UTC
Created attachment 70580 [details]
Add images of a collapsed stack to ThumbnailWidget::selection()
Comment 2 Miika Turkia 2012-04-23 04:06:29 UTC
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.)
Comment 3 Johannes Zarl-Zierl 2012-04-23 23:00:40 UTC
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).
Comment 4 Miika Turkia 2012-04-24 05:13:11 UTC
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
Comment 5 Johannes Zarl-Zierl 2012-04-29 14:29:22 UTC
Created attachment 70753 [details]
[PATCH 1/2] Allow inclusion of collapsed stacks for selection.
Comment 6 Johannes Zarl-Zierl 2012-04-29 14:33:24 UTC
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).
Comment 7 Miika Turkia 2012-05-06 05:32:09 UTC
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