[Digikam-devel] Batch Queue Manager

[Gilles Caulier]

Yuri,

"Show in Context Menu" option is a problem.

I see that you have commited in your branch this feature for AlbumGUI
context menu.

I would to know how this feature work exactly...

Also, if "External Tool" will be a common feature for BQM and contex
menu, all settings cannot be hosted in BQM Queue settings. it's a non
sence. digiKam Setup dialog is the right place for that.

In this case a new section can be created in Setup, hosting all your
current settings view from BQM queue settings section. In BQM, just a
list of available "external tools" must be visible with the right one
asssigned to the queue.

Gilles Caulier

2013/11/16 Gilles Caulier <caulier.gilles at gmail.com>:
> Yuri,
>
> What's the purpose of "Show in Context Menu" option ? Which menu is
> patched by your implementation ?
>
> Gilles Caulier
>
> 2013/11/16 Gilles Caulier <caulier.gilles at gmail.com>:
>> 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