| Summary: | Tools should be able to lock photos in application while processing is done in background | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Pieter Edelman <p.edelman> |
| Component: | BatchQueueManager-Core | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | REPORTED --- | ||
| Severity: | wishlist | CC: | caulier.gilles, marcel.wiesweg |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Pieter Edelman
2009-06-03 15:51:41 UTC
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 |