[Digikam-devel] Review Request 113519: Very draft implemetation of External Tools feature for BQM

Yuri Samoilenko kinnalru at gmail.com
Tue Nov 5 14:13:06 GMT 2013



> On Nov. 4, 2013, 4:25 p.m., Gilles Caulier wrote:
> > Ship It!
> 
> Gilles Caulier wrote:
>     >The core of the patch in moving Queue processing internals out of overburdened QueueMgrWindow to simple QueueMgr.
>     
>     This is a good way.
>     
>     >QueueMgr responsible for procession only one queue from begining to the end. 
>     
>     ok.
>     
>     >To implement "group-file-passing-to-extrenal-tool" QueueMgr intercept all signals from underlying taksk and and composing "result url list" which >will be sended to external tool in the end.
>     
>     Why you need to intercept all task to compose a target url list ? This list already exist in QueueSettings. Or perhaps you need to know which item have been properly processed or not (in case of task failure for ex)
>     
>     I don't take a look in your code yet. The way to separate internal queue processing from QueueMgrWindow is good, but in this case, processing work as expected as previous implementation embedded in QueueMgrWindow ?
>     Do you try all possibility of BQM here (renaming, selecting target album, processing more than one queue, using or not parallelization of items, etc...), and of course without to use file group processing at end of queue workflow.
>     
>     About configuring of External Tools implemented, do you store/restore these settings through workflow manager, to be able to play back it later ?
>     
>     Gilles Caulier
>     
>
> 
> Yuri Samoilenko wrote:
>     >Why you need to intercept all task to compose a target url list ? This list already exist in QueueSettings. Or perhaps you need to know which item have been properly processed or not (in case of task failure for ex)
>     
>     Yes, I want to operate on successfuly processed items i.e. on result of all workflow.
>     
>     >but in this case, processing work as expected as previous implementation embedded in QueueMgrWindow ?
>     
>     Yes it must, I hope. this patch is not ready for applying yet, I need to check way I'am on(right way?)
>     
>     > Do you try all possibility of BQM here...
>     
>     Not yet, but will necessarily. I will test BQM for regressions before final review.
>     
>     >About configuring of External Tools implemented do you store/restore these settings through workflow manager, to be able to play back it later ?
>     
>     Probably not, if I understand you. What means "to be able to play back it later"? Like "redo"? With regard to "External Tools" 'configuring' is just a custom name of external processor. For example such processor: 
>     
>     while read image; do                                                                                                                                                                                                                                     
>             cp $image /mnt/webdav/backup/photo
>     done <&0
>     
>     >store/restore these settings through workflow manager
>     
>     Does workflow manager has own config subsystem(I will search...)?
>     
>
> 
> Yuri Samoilenko wrote:
>     And onw more question. I have almost same ETRunner and ETWidget implementation in kipi plugin and BMQ, It is allowed to use cpp/h files from kipi in core directly(e.g. through #include "../../../kipi/plugins")? If not how can I share code from kipi plugin with digikam core?
> 
> Gilles Caulier wrote:
>     >>About configuring of External Tools implemented do you store/restore these settings through workflow manager, to be able to play back it later ?
>     
>     >Probably not, if I understand you. What means "to be able to play back it later"? Like "redo"? With regard to "External Tools" 'configuring' is just a custom name of >external processor. For example such processor: 
>     >
>     >while read image; do                                                                                                                                                                                                                                     
>     >        cp $image /mnt/webdav/backup/photo
>     >done <&0
>     
>     No. Workflow BQM concept is a way to store queuesettings plus list of tools assigned in a dedicated XML settings files stored in digiKam config directory from home folder.
>     
>     When you create a new Queue with new items, you can reload these settings and assign it to queue as well.
>     
>     Your external tools configuration must be managed by WorkflowMngr class, as it's done for others queue settings.
>     
>     
>     >store/restore these settings through workflow manager
>     
>     Does workflow manager has own config subsystem(I will search...)?
>     
>     It's an XML file stored in ~/kde4/share/apps/digikam/queue.xml
>     
>     >And onw more question. I have almost same ETRunner and ETWidget implementation in kipi plugin and BMQ, It is allowed to use cpp/h files from kipi in core >directly(e.g. through #include "../../../kipi/plugins")? If not how can I share code from kipi plugin with digikam core?
>     
>     Definitively no. kipi-plugins is independent of digiKam and vis versa.
>     
>     Gilles Caulier

>When you create a new Queue with new items, you can reload these settings and assign it to queue as well.Your external tools configuration must be managed by WorkflowMngr class, as it's done for others queue settings.

Ok. I understand.


- Yuri


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113519/#review42963
-----------------------------------------------------------


On Oct. 31, 2013, 1:32 p.m., Yuri Samoilenko wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113519/
> -----------------------------------------------------------
> 
> (Updated Oct. 31, 2013, 1:32 p.m.)
> 
> 
> Review request for Digikam.
> 
> 
> Repository: digikam
> 
> 
> Description
> -------
> 
> It is my first review. I have some questions about direction of my work.
> 
> The core of the patch in moving Queue processing internals out of overburdened QueueMgrWindow to simple QueueMgr.
> QueueMgr responsible for procession only one queue from begining to the end. To implement "group-file-passing-to-extrenal-tool" QueueMgr intercept all signals from underlying taksk and and composing "result url list" which will be sended to external tool in the end.
> 
> Configuring of External Tools impemented in new tab in BQM QueueSettings and selecting tool for current processing int "Target" tab in BQM QueueSettings.
> There is no interaction within "External Tools" and "Target Album" in Target tab yet.
> 
> Any comments?
> 
> 
> Diffs
> -----
> 
>   utilities/queuemanager/CMakeLists.txt 910752c 
>   utilities/queuemanager/main/etrunner.h PRE-CREATION 
>   utilities/queuemanager/main/etrunner.cpp PRE-CREATION 
>   utilities/queuemanager/main/etwidget.h PRE-CREATION 
>   utilities/queuemanager/main/etwidget.cpp PRE-CREATION 
>   utilities/queuemanager/main/etwidget.ui PRE-CREATION 
>   utilities/queuemanager/main/queuemgr.h PRE-CREATION 
>   utilities/queuemanager/main/queuemgr.cpp PRE-CREATION 
>   utilities/queuemanager/main/queuemgrwindow.cpp 8cd65bd 
>   utilities/queuemanager/main/queuemgrwindow_p.h 7bf44da 
>   utilities/queuemanager/manager/queuesettings.h 522c46f 
>   utilities/queuemanager/manager/task.cpp d825380 
>   utilities/queuemanager/views/queuesettingsview.cpp d9b89b3 
> 
> Diff: http://git.reviewboard.kde.org/r/113519/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Yuri Samoilenko
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-devel/attachments/20131105/310b0088/attachment.html>


More information about the Digikam-devel mailing list