Re: [Gramps-devel] BatchTool interface change alert to 3rd-party tool developers

[Vassilii K. <vas...@ta...>]

On 04.09.2013 20:42, Doug Blank wrote:
> On Wed, Sep 4, 2013 at 1:21 PM, Nick Hall <nic...@ho...> wrote:
>> On 04/09/13 15:21, Vassilii Khachaturov wrote:
>>> On 31.08.2013 20:06, Vassilii Khachaturov wrote:
>>>> On 30.08.2013 00:53, Nick Hall wrote:
>>>>> 1. Tools that can be run from either CLI or GUI.
>>>>>
>>>>> These require little user interaction, and should be passed a User
>>>>> instance rather than a DipslayState (uistate).  Any tool that can be
>>>>> run from the command line should also be available in the GUI.
>>>>>
>>>>> 2. Tools that require user interaction.
>>>>>
>>>>> These use a ManagedWindow to present an interface to the user. The
>>>>> ManagedWindow will need a uistate.
>>>>>
>>>>> There are actually a couple of classes in gui/plug/_windows.py for
>>>>> such tools:  ToolManagedWindow and ToolManagedWindowBatch. Only one
>>>>> tool actually makes use of them though.
>>>>>
>>>>> Perhaps we should re-think how we use the tool modes?  There are two
>>>>> modes:  TOOL_MODE_GUI and TOOL_MODE_CLI.  We could change the
>>>>> definition so that a tool can have only one mode.
>>>>>
>>>>> A CLI tool could be passed a User instance.  A GUI tool would be
>>>>> passed a uistate, requiring no change.
>>>> Maybe we should let uistate be a property of the gui User class, like
>>>> discussed earlier in this thread. Then we can unify the signature for
>>>> both kind of tools, and have the GUI tools extract uistate from it. Or
>>>> maybe we should have gui User inherit from DisplayState, in this case
>>>> there is an easier way to treat the legacy code.
>>>>
>>>> BTW, I propose to move to keyword-only syntax of calling plugins, so
>>>> that future upgrades to the core/3rd-party interface can be more
>>>> seamless.
>>>>
>>>> V.
>>>>
>>> Does anybody have any objections against trying the above approach on
>>> trunk?
>>> I have already committed supprot for the gui User to store a displaystate
>>> inside.
>>>
>>> To actually enable this, I am going to add user to the session manager
>>> (stored as CLIManager.user),
>>> which would be sometimes passed as gui User with DisplayState inside from
>>> the gui ViewManager.
>>>
>>> Then, as the next step, I will change the tools' classes signature to
>>> accept user instead of uistate.
>>>
>>> V
>>>
>>>
>> About two-thirds of the tools are GUI-only, and inherit from ManagedWindow.
>> I don't see any point in changing these - they can continue to be passed the
>> DisplayState (uistate).
At the first stage of the refactoring, those tools will begin with
     uistate = user.uistate
so nobody should be upset about it much.

> I haven't thought about this much, but perhaps one reason to change
> them is that they could then be tested using the new testing system.
That was, of course, part of my secret future plans :-) I thought we 
could be attacking the tools one-by-one and gently nudge them to better 
testability and CLI-friendliness.
> Another reason might be that with a different User class, perhaps it
> could be used via the web.
That is a very cool idea I haven't thought of!
>
> I guess it is the case that these tools can't be used via the command
> line interface (CLI)? It might be handy if they could, even if it just
> worked with the defaults. Does the CLI options allow one to set the
> options for a tool? If so, then they would be totally functional via
> the CLI (and thus the web).
>
> -Doug
>
Hear, hear!

V.