Version: (using Devel) Installed from: Compiled sources For some of the Kipi plugins it is desirable to be able to use the main application window while the plugin is active. This is especially true for the web upload plugins, which completely lock the main application while uploading (see bug 194811 for example). However, this can only been done if the images that the plugin works on are locked against modification and deletion (including moving). This mechanism should be added to libkipi. Some things to consider: 1. It should work with all programs Kipi supports 2. It should work on all platforms 3. The lock should be lost when the application crashes etc. 4. It should work both on the physical file as on the host applications database (so for example, Digikam should also understand that the tags can't be changed when a photo is in the Flickr upload queue). Because of requirement 2 through 4, I think the most logical way to implement such a mechanism is to use an explicit signalling mechanism that is interpreted by the target application. This requires the cooperation of the authors of these host programs.
Marcel, Do you remember this feature to do ? We have already talk about by IRC. Gilles Caulier
How do the affected KIPI plugins store their lists? As KUrls? As KipiImageInfo? Moving operations from within digikam can be tracked, the task can be informed that a given url has been moved to another given place, and do the checks itself. As for deletion, IMO if a user deletes an image he does not want it to be processed anymore, so it's ok to drop it. For both cases signals can be made available within digikam. We could also provide wrapper lists in digikam code. Of course there must be API on the KIPI side. Dont know how to solve this. As for locking the main view, I think that the plugin should get a list of the affected images and store it itself instead of relying that the view remains locked. I dont think that any task that is a background task should have the power to restrain the user working in the main view.
>How do the affected KIPI plugins store their lists? As KUrls? >As KipiImageInfo? This depend. For multithreaded tool, KUrl is used, for others KipiImageInfo. At least Kurl list is always generated from KipiImageInfo is main thread. In fact, i think lock item feature is very important in digiKam, outside kipi-plugins/libkipi because of new BatchQueueManager. Lock items must be done internally in digiKam following BQM activity and after extended to kipi-interface. I think libkipi no need to be changed a lots here. The main implementation staying in kipi host core + kipi host interface. To resume : 1/ a plugin ask to host to play with items. 2/ host lock items because there are processed by an external tool. 3/ in gui, a mark must be visible over icon to bring user about lock state. 4/ when plugin is done, kipi host unlock items. I think 1/ and 4/ need small change in libkipi to request lock/unlock in kipi host from plugin. Gilles
I thought a bit about Marcel's comments, and I actually don't agree. I think it would require substantial effort to let every existing and future plugin handle each move and deletion signal. Maybe it's not even possible, for example when a list of photo's is handed over to an external application (although this is a purely hypothetical example, I don't believe there are currently plugins which do this. But you never know what the future may bring). Implementing a single lock and release operation on the other hand would be quite simple to add to the plugins. Of course, I can't speak for development effort needed for the host applications. I also don't agree with the comment that background tasks should be able to lock photo's in the main view. For the end user, the plugins are part of the application, so locking a photo would simply signal to the user that another part of the program is using it. For me, this seems the logical behaviour.
Marcel, This entry depend of lock feature talk in Genoa recently. The goal is to lock items processed in digiKam to prevent multiple action at the same time. For example, you rotate images and you try to move it as well during rotation process. The same lock mechanism must be done though kipi interface. A kipi tool which perform operations on item must lock items to prevent concurrent operations from users. Ex: I convert RAW to DNG, and during conversion, i go back in digiKam and i remove RAW files... Gilles Caulier