Review Request 113519: Very draft implemetation of External Tools feature for BQM

Updated Oct. 31, 2013, 1:32 p.m.

It is my first review. I have some questions about direction of my work.
Description updated
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?
Ship It!
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?
Ship It!
>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

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?
Ship It!
>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

>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...)?

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?
Ship It!
>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

>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...)?

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?
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?
Ship It!
>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

>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...)?

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?
>>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
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?
Ship It!
>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

>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...)?

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?
>>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.

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?
Storing/restoring settings through WorkflowMngr implemented.

Tested:
1. renaming, batch processing without ExtenalTools
 - one queue
 - two queues
 - using multiple cores

2. renaming, batch processing with ExtenalTools
 - one queue
 - two queues with diffrent external tool
 - using multiple cores

BUG: "Target Album" in Target tab is not working in master branch(without ET) when two or more queue present - all processed pictures puts in last selected album.
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?
Patch doesn't apply.
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?

Review Request 113519: Very draft implemetation of External Tools feature for BQM

Review Request 113519: Very draft implemetation of External Tools feature for BQM

Description

Diffs

Re: Review Request 113519: Very draft implemetation of External Tools feature for BQM

Changes

Description (updated)

Diffs

Re: Review Request 113519: Very draft implemetation of External Tools feature for BQM

Description

Diffs

Re: Review Request 113519: Very draft implemetation of External Tools feature for BQM

Description

Diffs

Re: Review Request 113519: Very draft implemetation of External Tools feature for BQM

Description

Diffs

Re: Review Request 113519: Very draft implemetation of External Tools feature for BQM

Description

Diffs

Re: Review Request 113519: Very draft implemetation of External Tools feature for BQM

Description

Diffs

Re: Review Request 113519: Very draft implemetation of External Tools feature for BQM

Description

Diffs

Re: Review Request 113519: Very draft implemetation of External Tools feature for BQM

Changes

Description

Diffs (updated)

Re: Review Request 113519: Very draft implemetation of External Tools feature for BQM

Description

Diffs