Call for ideas: requirements for Krita tool actions system

[Boudewijn Rempt]

On Sunday 05 June 2011 Jun, Dmitry Kazakov wrote:
> > Do you intend to rewrite the tools to no longer be KoToolBase tools working
> > on KoCanvasBase-based canvases? There's some job facilities in
> > calligra/libs/main/KoAction, but it's not very pretty code.
> >
> 
> Of course no! =)
> I just don't want the tools to have direct access to mouse events. Atm I'm
> investigating flake/tools/ code and it looks like
> KoInteractionTool/KoInteractionStrategy is exactly what we need. I think
> I'll just rebase KisTool onto KoInteractionTool. Or kind of it.

Ah right. I think you cannot do that, but you could implement a similar strategy for krita. The interaction strategy is only for the interaction tool -- but nothing stops us from either making that design generic, or having something similar for Krita.

> > On that note: how about the other flake tools? I guess those don't need to
> > be queued that much, but flake layers still cause canvas updates.
> >
> 
> Well, I'm afraid we'll have to override them with our own tools (through the
> inheritance), because we'll have to add the stuff like
> rotation/gestures/panning to them.

Hm... That suggests we might want to put everything in strategies and just add those to the existing flake tools. Overriding them is going to be tricky, since many of those tools are in plugins.

> > > 1) The scheduler should serialize stroke and merge actions. The order of
> > > actions accessing the same pixels should be total.
> >
> > I didn't really understand this sentence.
> >
> 
> Ok, total order of execution means that two actions do not overlap in time.

Ok.

> 
> 
> 
> > There are also tools that only affect the canvas display, like panning.
> >
> 
> Yes. And this is quite good question whether we should enqueue such tools
> into the same queue or not? How do you think? That would be quite good to be
> able to pan the canvas during the canvas update.

I agree -- so not in the same queue?

> >  > 11) All the tools should support common gestures those change their
> > > parameters. E.g. Shift+Drag. We can add different types of drags, like
> > > Shift+Vertical Drag and Shift+Horizontal Drag, the type of drag may be
> > > recognized automatically.
> >
> > I think we need to find a better name for this than gestures, because
> > people are bound to be confused by the Qt gesture framework.
> >
> 
> Agree. Any suggestions?

interaction strategies might work?

> >  > 12) On some modifiers, like Ctrl and Space, the current tool shoud be
> > > switched to another one temporarily, like to Color Picker Tool and Pan
> > Tool.
> >
> > We did that before, but the users didn't like it because the option widget
> > changed. I think that we should have two kinds of tools: normal, and
> > temporary, where the temporary tool only changes the cursor but not the
> > option widget.
> >
> > When should we move back to the first tool? On release of shortcut, or on
> > pressing another key? We had the p->pan, b->back to freehand shortcuts, but
> > users didn't like those.
> >
> 
> We can just switch the strategy of the interaction tool. The icon and
> behavior change, but the tool doesn't. The main tool should be activated
> back on releasing the modifier. And shortcuts like 'p', 'b' should switch
> the tool completely, I guess.

Right, that sounds good.

> >  > 13) Canvas rotation should be accessible from all the tools.
> > > 14) The tool's stroke and decorations should be cancelled on pressing
> > Esc.
> > > 15) Mouse Wheel should do Pan/Zoom in all the tools.
> >
> > Maybe we can implement that in the canvas, instead of in the tools?
> >
> 
> It may cause problems if tools decide to override this behavior. And I'm not
> sure this behavior will correlate with different modes of the tools well.

Ok.



-- 
Boudewijn Rempt | http://www.valdyas.org, http://www.krita.org