Call for ideas: requirements for Krita tool actions system

[Dmitry Kazakov]

> 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.



> 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.



> > 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.



> 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.


>  > 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?



>  > 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.



>  > 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.

-- 
Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20110605/ac43c49a/attachment-0001.htm