[Digikam-devel] Batch Queue Manager

[Gilles Caulier]

Yuri,

I tested your code in your dedicated branch, and some point need to be changed :

1/ In "Target" settings view, you have inserted the option "Use
external tools". It's not the right place. This option must go in
"External Tools" settings view, on the top. Activating this option
must enable all settings in this view, else these settings must be
disabled.

2/ "External Tools" settings view is not the right name. Action
performed by this view will be processed at end of queue. So for me
the term is not enough explicit for end users. I'm sure that nobody
will understand as well the purpose of this view. This is why it must
be renamed, and some tips must be written in a label in this view to
explain what's end users can do with it.

3/ "External View" will be used to call a program when all items for
the queue are completed. The program, can be a binary or a script. In
this view you force to use a script, by default as bash. And what's
about Windows where Batch shell script are used. In other words, you
need to write a GUI more universal where these information must be
show :

- the path to the Program
- the name of the Program
- the description of the Program
- the arguments to pass to the Program.

Here we don't care about the type of shell used, in case of a script.
We don't care about the script content. Where you can show a script
content, you cannot do it for a binary. Instead, propose to end users
to be able to edit script with default editor set in KDE. This is not
the goal to digiKam to host script source code. Because, if i'm not to
wrong, scripts will be hosted as external file in home directory.
Right ?

4/ In your GUI, i recommend to propose a list of Programs available
and ready to use. User will assign one Program to the queue, and that
all. The list can be stored in workflow XML file. Look how i do with
workflow list view (workflow name + description are displayed)...

Let's me hear if all my explanations are enough clear for you

Best

Gilles Caulier


2013/11/10 Gilles Caulier <caulier.gilles at gmail.com>:
> 2013/11/10 Yuri Samoilenko <kinnalru at gmail.com>:
>> Good evening
>>
>>> Yes, i see it. I'm registered to commit filter :
>>> http://commitfilter.kde.org/
>>> Like this i see all commit done by all contributors through email.
>>
>>
>>  Nice stuff thx.
>>
>>
>>> > What about branch manipulating strategy?
>>> > 1. Is rebasing to master allowed in development branches?
>>>
>>> You can sync (you must) this branch with master changes to have your
>>> branch updated in time.
>>
>>
>>  I mean that if I will use git rebase(not merge) to master then other
>> developers who want to track my branch(I mean any development branch)  can't
>> fast-forward changes. They will forced to use 'force update', but rebased
>> branch will have more plain(simple) commit history. In other word can I
>> consider development branches as 'private'(allow rebase and breaking
>> fast-forward) or it must be considered as 'public'(no rebase allowed only
>> git merge).
>
> Public, because i will review your code and commit fixes...
>
>>
>>
>>>
>>> No need if code changes are not too intrusive and quickly testable. In
>>> general, making patch attached to relevant bugzilla entry is enough. I
>>> don't like reviewboard. This require to manage too tools, where only
>>> one is enough to control bug fixes : bugzilla.
>>>
>>> No need reviewboard (forget this tool)
>>
>>
>>  ok
>>
>>
>>> For this week end, i'm with my familly. I go back at home monday
>>> evening. I will review all your new branch and code tuesday evening.
>>> Don't forget that i'm in stop disease for few month due to my car
>>> crash and i will have a lots of free time to play with code (:=)))
>>
>>
>> ok - I'm in no hurry. The first of november(9 days ago) my daughter was born
>> and now I can always find how to spend time :)
>
> Congratulations (:-)))...
>
> Gilles Caulier