Re: Temporary tools

[Valentin Ungureanu]

Bernhard Herzog wrote:
>
> Valentin Ungureanu writes:
>
> > A tool (which is derived from ToolInstance) is temporary if:
> >
> >     1. has the temporary attribute set to True. This informs the
> >        editor to instantiate it without ending the previous tool.
> >
> >     2. one of its ButtonClick or ButtonRelease methods calls
> >        application.SetTool with the previous toolname and the
> >        use_old set to True
> >        [snip]
>
> I think it shouldn't be the responsibility of the tool to restore the
> previous tool.  At most it should indicate that it's done, but it
> shouldn't have to know which tool to restore and how to do that.
> [snip]

Now that you said it, it sounds quite obvious :)
The 'use_old' argument that needed to be carried around was a bit
ugly as well.

> I can think of two approaches to make it better:
>
>  1. When the temporary tool is finished, it calls a new editor method
>     called e.g. TemporaryToolFinished (not sure about the name), which
>     doesn't take any parameters and restores the previous tool.
> 
>  2. Limit temporary tools to a single "mouse-press-drag-release" cycle.
>     [snip]
>
> [...] approach 1. is probably the better one because it uses the
> strengths of object orientation better.

I also preffer 1. And I think TemporaryToolFinished must be called not
only from ButtonRelease/ButtonClick but also from Cancel.

Maybe have a TemporaryToolInstance class? It would have an additional
method, let's say Finished() that would make the call into the editor
and would override Cancel so that it doesn't have to be done in each
derived class.

> [snip various issues with global tool]
>
> I wonder whether we should get rid of the global tool and simply
> manage the current tool at the editor level only.

I think getting rid of the global tool would be the most simple and
clear solution; having context.tool saying one thing and editor.tool
another already confused me once.

The context would be used only to pass a SetTool call to the editor,
and it would be the task of the editor to send a TOOL message after it
sets the new tool.  To this message would be subscribed the canvas (to
set a new cursor), some menu items and the tool buttons.

> This might introduce some usability problems, though, especially
> with the current global toolbox window.  Of couse we should get rid
> of that, too, and give each document window a menu and toolbar.

We could subscribe the tool buttons to the context.  This way each
button can adjust its sensitivity and set itself as active or not when
the context changes.  So even if the toolbox doesn't go away it would
always reflect the tool of the current editor.