Bug 186767 - batch process of a folder does not process all images in folder
Summary: batch process of a folder does not process all images in folder
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: BatchQueueManager-Core (show other bugs)
Version: 0.10.0
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-03-10 12:46 UTC by Nadav Kavalerchik
Modified: 2019-07-28 21:32 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 6.2.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nadav Kavalerchik 2009-03-10 12:46:53 UTC
Version:           0.10.0 (rev.: 933374) (using 4.2.1 (KDE 4.2.1), Debian packages)
Compiler:          cc
OS:                Linux (x86_64) release 2.6.26-1-amd64

i right clicked a folder and choose "Batch Process" and then resize (but it is true for all options) and i saw that only one image was showing on the list.

later, i figured it out that it was the first selected image (that gets automatically selected when i click any folder) that was shown on the batch process dialog.

de-selecting all images and right clicking the batch process works ok now.

i guess, when right clicking a folder for batch process should select all images in the folder. at least this is what i expect.

is this intentional ?
Comment 1 caulier.gilles 2009-03-10 12:57:52 UTC
>is this intentional ?

No. the behavior must be your one. I'm not sure if bug is in digiKam kipi-interface or in plugin.

Note : this bug is definitively fixed using Batch Queue Manager implemented in 0.11.0:

http://www.digikam.org/drupal/node/427

Gilles Caulier
Comment 2 Nadav Kavalerchik 2009-03-10 14:32:09 UTC
you got me completely off track (in a good way) 
about this bug after i read about :
the Batch Queue Manager is very very impressive !

i must ask you:
will it be able to virtually apply a list of batch action on a virtual folder
that is not really holding the images (so i will not have redundant images on my system.)

i regularly apply some batch processing to images and then upload them to my website. (http://GrowOrganic.Info/wordpress/ (in hebrew))

i would really like to have a folder that is actually a virtual replication to a real folder that has some batch actions applied to it. (resize + rename + compress + add some XMP keywords/tags + a filter (maybe)...)

sorry for the irrelevant post, here, i got really excited with your new Batch Queue Manager link :-)
Comment 3 caulier.gilles 2009-03-10 14:42:54 UTC
>you got me completely off track (in a good way) 
>about this bug after i read about :
>the Batch Queue Manager is very very impressive !

Thanks

>i must ask you:
>will it be able to virtually apply a list of batch action on a virtual folder
>that is not really holding the images (so i will not have redundant images on
>my system.)

Yes, you can. open BQM (press "b") go to Tags folder view, and Drag & Drop and album to a Queue. That all

>i regularly apply some batch processing to images and then upload them to my
>website. (http://GrowOrganic.Info/wordpress/ (in hebrew))
>i would really like to have a folder that is actually a virtual replication to
>a real folder that has some batch actions applied to it. (

resize => tool is done.
rename => tool is done.
compress => settings can be changed in file format converter
add some XMP keywords/tags => not yet done. planed.
filter  => tool is done.

>sorry for the irrelevant post, here, i got really excited with your new Batch
>Queue Manager link :-)

No problem.

Gilles Caulier
Comment 4 Nadav Kavalerchik 2009-03-10 18:29:40 UTC
since i use 0.10 svn version...
how can i use the BQM ?
Comment 5 caulier.gilles 2009-03-10 19:23:09 UTC
There is a devel branche here :

http://websvn.kde.org/branches/extragear/graphics/digikam/0.11/

Gilles Caulier
Comment 6 Andi Clemens 2010-10-01 20:34:46 UTC

*** This bug has been marked as a duplicate of bug 125042 ***
Comment 7 caulier.gilles 2019-07-28 21:32:31 UTC
Fixed with bug #125042