[Digikam-users] Differences of behaviour since last upgrade
Gilles Caulier
caulier.gilles at gmail.com
Mon Aug 19 11:42:20 BST 2013
2013/8/19 Marie-Noëlle Augendre <mnaugendre at gmail.com>
> Apart from the undisplayed title mentioned in my previous thread, there
> are others things that I'm not so satisfied with:
>
> 1) at launching time, Digikam spends time to search new pictures. I don't
> need this as I always import pictures straight into Digikam, and never used
> it in the past. But I don't find the way to deactivate this function. It
> used to be in the configuration menu, I think, but I cannot find it now.
>
Option have been removed. Since 2.x, this option is obsolete due to the
differs analysis done in background after that digiKam is started.
Typically the scan method has changed like this :
- before 2.x, scan for new albums + new items is done at startup, before to
show main GUI. This scan at startup mode can be disabled in Setup/Misc.
- after 2.x, scan core implementation have been changed to only register
new albums in DB at startup, and to scan new items after than main GUI
appears. It's done through a separated thread and scaning progress is
reported to ProgressMAnager from status bar.
I work as you. My startup take few seconds only. I manage around 250Gb of
photo. it's fast and do not perturb me in my workflow (as main GUI is
imediatly here and usable as well)...
>
> 2) queues of the batch tool manager act somewhat strangely/inconsistently:
> - you can have several queues, but when you close the BTM window,
> elements are not removed from the queues. Consequently, any Ctrl-B will add
> new elements to a former queue that is not empty, and whose elements have
> already been treated.
>
BQM is not a stand alone window, as Light Table in fact. If you want to
clean a queue, just delete it from list.
> - when I want to delete already treated elements from a queue, that's
> Ok for the current queue (the one which tab is opened). But when I want to
> do the same on other queues, although elements have been treated too, they
> are considered to not have been and I get a message saying that elements
> remain that have not been treated yet
>
There is a report already in Bugzilla about.
> - as far as I understand, the execute button work for all the queues at
> the same time.
>
Not exactly. Queue are processed one by one. items in queue can be
processedin parallel if right option is checked.
> There is no option to run only the current queue, no way to move an
> element from a queue to another one...
>
It's not yet implemented.
> in that way, the ability to manage several queues at the same time is
> quite limited.
>
But may be I don't use these queues as they should be, but I didn't any
> configuration settings on the matter. Advice on the matter would be
> appreciated.
>
Do you tried to store queue settings in a workflow and apply it to a new
one ?
Gilles Caulier
>
> Marie-Noëlle
>
>
> --
> <http://fr.ulule.com/aigoual-aubrac/>
>
> *De l'AIgoual à l'Aubrac, un voyage photographique en Cévennes et Lozère*
> Un livre à offrir ou à s'offrir, en souscription jusqu'au 31 août 2013.
> Cliquer sur l'image ci-dessus ou ce lien pour en savoir plus<http://fr.ulule.com/aigoual-aubrac/>
>
> _______________________________________________
> Digikam-users mailing list
> Digikam-users at kde.org
> https://mail.kde.org/mailman/listinfo/digikam-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20130819/f8ac40f3/attachment.html>
More information about the Digikam-users
mailing list