Call for ideas: requirements for Krita tool actions system
dimula73 at gmail.com
Sun Jun 5 15:01:40 CEST 2011
> > > On that note: how about the other flake tools? I guess those don't need
> > > 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
> > 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
> > 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
> > > > 11) All the tools should support common gestures those change their
> > > > parameters. E.g. Shift+Drag. We can add different types of drags,
> > > > Shift+Vertical Drag and Shift+Horizontal Drag, the type of drag may
> > > > 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).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the kimageshop