tool activate()

[Sven Langkamp]

On Sunday 20 March 2005 23:25, Boudewijn Rempt wrote:
> On Sun, 20 Mar 2005, Casper Boemann wrote:
> > Hi
> >
> > I was trying to make activate and deactivate functions of KisTool, but
> > then I realised that the concrete subclasses KisToolPaint and
> > KisToolNonPaint both has an activate() slot. Don't know if it does what I
> > need, which is to provide me a place to do some toolspecific
> > initialisation each time the tool is started. More specifically in my
> > transform code I need to draw handles on screen as soon as the tool is
> > activated. And the handles need to go away (and the transform committed)
> > when the tool deactives (ie another tool is selected)
> >
> > Can someone enlighten me as what I should do to provide a deactivate, and
> > should it also be a slot, and why aren't activate directly made in
> > KisTool
>
> Okay... The reason there is no deactivate is that until now tools were
> supposed to finish their job on mouse-up. This already broke down somewhat
> with the primitive crop tool I implemented some time ago, but with your
> work, this model breaks down completely.
>
> What we need, therefore, is to add a deactive() that is called whenever
> another tool is activated for a certain pointer. Keep in mind that we
> can easily have any number of tools active at the same moment: one for
> the mouse, one for the stylus, one for the eraser, one for another Wacom
> stylus, etc. You cannot simply assume that there is only one tool active
> at a given time.
>
> (I know that we don't have finished the gui to represent this complication
> to the user, though -- but we cannot go back on this. There will always
> be a set of active tools, each associated with a certain pointing device.)
>
> A temporary solution would be to follow the crop tool lead: have
> two buttons, one to activate the handles, and another to commit the
> changes. Not ideal, but a possibility. If you want to go all the way
> and implement a pointer-specific activation and deactivation routine,
> by all means, go ahead. It'll be better in the long run, even if it's more
> work right now. The place to call the current-tool::deactivate is just
> before the new-tool::activate in KisView, I guess.
You could call them in KisView::setCurrentTool, I think.

By the way: Is there a reason why the optionwidget of the tools is unpluged 
twice( once in KisView::setInputDevice and once in KisView::setCurrentTool)?