Call for ideas: requirements for Krita tool actions system

[Dmitry Kazakov]

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

What flake tools do we have, except DefaultTool and ZoomTool?


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

I guess canvas actions can be performed directly, though it should be
checked.


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

"Strategies" is too general, because it includes keyboard modifiers and
different mouse buttons. We need to call it somehow (and it'll be reflected
in user manual as well).


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