Version: 0.10.0 (using KDE 4.2.2) OS: Linux Installed from: Compiled From Sources Wish: make it possible to upload images to flickr in a separate process, ie. so that digiKam is not locked for other work while images are uploading. Reason/ use case (is that what it is called?): This would be great when you are working through 200 images from last weekends sailing trip and you are on a slow internet connection. Then you can sort through some of your pictures, delete the worst, attach tags to them, mark some for uploading and then continue looking at a new group of pictures. (Unlike today - select 20 images for upload and... go shopping or something!)
strong support for this wish.
I also would love this feature, and in theory it is trivial to implement: changing the upload progress dialog from modal to non-modal does the trick. However, if this would be enabled, it will become possible to change or delete the photos that are currently in the upload queue. So the question is, is there a way to reliably lock the photos in the upload queue against manipulation, deletion or moving, which works reliably on all supported platforms and in all applications which the Kipi plugins target?
No, Lock is not yet implemented in libkipi. It still in my todo list. Gilles Caulier
Gilles, should a separate bug for this lock feature be opened? That way, this feature requist can be made to depend on it. And maybe other people can pick it up.
Yes, please, in kipi-plugins/libkipi KDE bugzilla component Gilles
I have been thinking about this for a few days: yes, the lock feature is a nice addition too - but i think it is not right to make it a requirement. It is possible for a reasonably well disciplined user to engineer workflows within the existing digikam software that avoids tampering with files tagged for upload. Also, it is nowhere near fatal to upload the wrong image to flickr...it is just a delete and retry. However, if it is possible to upload with flickr upload plugin without lock, the plugin must be able to process the queue without stopping at all problems (ie...list problems in a report window (+file?) after queue rather than stop at every problem). If files in the queue are deleted, the upload plugin must continue with the next file and not stopped. In other words, I am against making the upload in separate process a dependency of the lock feature (although it clearly will benefit from it). However, this may demand some more work on making the upload process robust from stopping due to minor problems.
I also do not see locking as a strict requirement. Anyhow, a feasible alternative would be to copy the necessary files to a temporary space and delete after upload. And what I would like very much would be a hook for a user script to be executed before upload
All export dialogs were changed to non-modal, but the transfer progress dialog is still blocking the interface. We plan to move the progress bar into main export dialog and this will allow main interface to be fully useful during transfer.
Shourya, This file include many point where muti-threading must be used to not overload GUI (main thread) - image resizing (this is already implemented in SendImages tool to imageresize.cpp. The class must be factored to libkipiplugins and API adjusted to be used by all tools as well. Note that we can apply metadata adjustments in resizing thread. - items uploading (from local computer to remote web service). - items downloading (from remote web service to local computer). Gilles
WARNING : with digiKam 6.0.0 and later, we will not support kipi interface anymore. All tools are now located in digiKam core as well for a plan to provide a more power-full integration with Batch Queue Manager and to be able to export a workflow on a web-service. All export tools are now available everywhere : album view, Image editor, Light table, and Showfoto. Previously, only album view from digiKam core was able to deal with export tools through libkipi. All export tools are now located here : https://cgit.kde.org/digikam.git/tree/core/utilities/assistants/webservices All export tools use now a dedicated interface to communicate with the application : - digiKam (database) : https://cgit.kde.org/digikam.git/tree/core/libs/database/utils/ifaces/dbinfoiface.h - Showfoto (files metadata) : https://cgit.kde.org/digikam.git/tree/core/utilities/assistants/common/dmetainfoiface.h There is not direct use of digiKam database for compatibility with Showfoto. We plan later to provide a dynamic loading of export tools using a plugins mechanism. This will reduce overloading of the internal core libraries. A dedicated devel branch have been created for that, but it's not yet complete: https://cgit.kde.org/digikam.git/tree/?h=development/dplugins But take a care, digiKam export tools as plugins will not be shared with another external application. API will still private and only shared between Showfoto and digiKam core. The experience with libkipi was bad and complex to maintain/extend in time. Gilles Caulier