Bug 125042

Summary: Batch Rename Image from Album do not select all album images
Product: [Applications] digikam Reporter: Jérôme Martin <jerome.f.martin>
Component: AdvancedRename-fileAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: caulier.gilles, consultant.internet, nadavkav, tschenser
Priority: NOR    
Version: 0.8.1   
Target Milestone: ---   
Platform: Mandriva RPMs   
OS: Linux   
Latest Commit: Version Fixed In: 1.5.0
Sentry Crash Report:
Attachments: Screenshot describing problem

Description Jérôme Martin 2006-04-06 14:27:02 UTC
Version:           0.8.1 (using KDE KDE 3.4.2)
Installed from:    Mandriva RPMs
OS:                Linux

I left-click on an album and select batch rename image in the popup menu.
Batch Rename Image dialog opens but only the first image is added and not all images from album.
Comment 1 caulier.gilles 2006-04-06 14:32:37 UTC
This is not right : go to an album and unselect all items ("select/select none" menu entry). Now start Batch Rename image tool : all items from current album are available in the list.

This is want mean (and it's logic) that the tool use the current selected items from an album, or, if none, all items. 

Gilles Caulier
Comment 2 Jérôme Martin 2006-04-06 15:11:47 UTC
Yes, but for me what is logic is:
 - when I make an action in album list it takes all album images
 - when the action is made in images list, it takes selected images

Another related question is why selecting an album select the first image. Without such feature, I would not see anything and do not enter this bug :)
Comment 3 Mikolaj Machowski 2007-11-19 22:44:10 UTC
Jerome is right. In such situation user can expect menu will automatically select all images without further actions from the user.
Comment 4 caulier.gilles 2008-12-04 15:56:24 UTC
Mik,

This depand of current selection processed by user. For me this entry is invalid...

Andi, Marcel, Arnd ?

Gilles Caulier
Comment 5 Andi Clemens 2008-12-04 16:09:23 UTC
I don't know, for me it sounds right. When I select an album in folder view and want to apply batch actions on it, I expect it to select all images. When I select an image range in the thumbnail view, I expect it to take only those images.

Andi
Comment 6 caulier.gilles 2008-12-04 16:17:07 UTC
And for me the behaviors is fine currently...

Gilles Caulier
Comment 7 Andi Clemens 2009-10-19 00:43:50 UTC
I still think the behavior is wrong. Right click an album, Batch->Export to Flickr.
I expect digiKam to add all images to FlickrExport, not the first item in the iconview.
Otherwise I would have chosen the main menu entry.

So we either need to change this behavior or remove the actions from the album context menu completely.
Comment 8 Andi Clemens 2009-10-19 00:49:09 UTC
To me this is clear :) I mean what is an album? An album is a collection of images.
So when I right click on an album and say Export to Flickr, I want to export the ALBUM (a collection of images), or, in other words, I want ALL of the images to be exported.

With the current implementation it is not possible anyway, since we simply use the global action from the export menu, which always acts on the selected images.

So again: Either change this completely or just remove it.
I would vote for removing the KIPI menus from the album context menu.
Comment 9 caulier.gilles 2009-10-19 08:58:53 UTC
>So again: Either change this completely or just remove it.
>I would vote for removing the KIPI menus from the album context menu.

If yu do it, you will see a new entry fro users to restore it (:=))). I have already tried to do it in the past...

Gilles
Comment 10 Andi Clemens 2009-10-19 11:07:24 UTC
That's the problem with users :-)

No really, the behavior is just wrong. Imagine dolphin: 
I right click on a folder to delete it, and it just removes the first image (or the selected ones in split view mode) instead the whole folder :-)

The way it is now the export menu simply doesn't make sense. "Import" makes sense, but "Export" and "Batch" simply behave not correctly.

We should gather other opinions on this :)
Comment 11 Jens Mueller 2010-01-07 21:48:23 UTC
(In reply to comment #8)
> To me this is clear :) I mean what is an album? An album is a collection of
> images.
> So when I right click on an album and say Export to Flickr, I want to export
> the ALBUM (a collection of images), or, in other words, I want ALL of the
> images to be exported.

IMHO i give the point to Andi, if I selelect a Album I want want to operate on my selection (in this case the whole album).
Another point is: There is a realy nice & powerfull toy, called BQM, with color adjust, advanced rename, rotate, color correction, reencode, shear - Why do we have these single kipi batch tools ins album right click menu and the general menu bar. I find it confusing having different tools for the same thing. So I suggest to drop them and pull in a BQM link.

Jens
Comment 12 Andi Clemens 2010-01-07 22:21:13 UTC
As I wrote AdvancedRename, I removed the "rename" KIPI plugin, since it doesn't make sense anymore.
But some of the other KIPI tools are not (yet) BQM tools, so they are still usable in some way.
Still I think that our current behavior is wrong, selecting an album should select all images... but I made my point clear before already :-)
Comment 13 pierre 2010-04-21 22:08:47 UTC
Export Plugins Problems

I am a user who discovers that digiKam and previously used Acdsee Windows.
I am pleasantly surprised by the amount of exports offered digiKam.

When handling image collections (albums), and you select one or more images for which you wish to apply a given action (eg rotation, renumbering, export to picasa, Piwigo etc. ...) that This action applies to the selection.

As a user, I note that this simple concept, logical and full of common sense does not apply to exports from other to picasa and Piwigo (I have not tested the others).

In fact only the first frame of the selection is exported!

It is absurd to have to ask the user to select the images in folders! (This may however be suggested)

Do not tell me that it is not a bug!

I suggest some consistency in the development of similar plugins.

Regards, PG

(Translated from french by http://translate.google.com)
Comment 14 Frédéric COIFFIER 2010-05-07 15:53:53 UTC
Pierre,
Concerning Piwigo export plugin, it's not the expected behaviour. So, could you open a new bug report ?
I can't reproduce the problem, so I'll be glad if you could provide me some debug log.
Comment 15 Jens Mueller 2010-05-07 18:01:46 UTC
Created attachment 43343 [details]
Screenshot describing problem

Frederic, this is nothing specific to piwigo, it is the same for all exporters. The usability problem is that all context-menu actions like 'New', 'Rename', 'Open in File Manager', 'Delete', 'Options' work on the current selection - the album, only export options work on selected images inside album.

Regards, Jens
Comment 16 Andi Clemens 2010-09-25 17:26:55 UTC
I could provide a solution for the export problem:
When an action is hovered in the export menu, select all images in the album automatically. When the action is triggered, images get deselected again.

This works pretty well... what do you think? 
Commit will follow...
Comment 17 Andi Clemens 2010-09-25 17:28:17 UTC
SVN commit 1179475 by aclemens:

Auto-select all images in an album when an action in the export menu is
hovered.

CCBUG: 125042

 M  +11 -0     contextmenuhelper.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1179475
Comment 18 Andi Clemens 2010-09-25 17:32:59 UTC
The problem is that if you decide not to export the album, all images are still selected.
I can not use "aboutToHide()" for deselection, because this signal is emitted too early, so that no image will be exported.
Comment 19 Andi Clemens 2010-09-30 20:39:31 UTC
SVN commit 1181333 by aclemens:

Use a timer to deselect the images when export menu loses focus.

BUG: 125042

 M  +2 -1      NEWS  
 M  +11 -4     digikam/contextmenuhelper.cpp  
 M  +1 -0      digikam/contextmenuhelper.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1181333
Comment 20 Andi Clemens 2010-10-01 20:34:46 UTC
*** Bug 186767 has been marked as a duplicate of this bug. ***