Proposal for new modifiers/shortcuts system

[JL VT]

On Mon, Jun 13, 2011 at 8:46 AM, Boudewijn Rempt <boud at valdyas.org> wrote:

> On Sunday 12 June 2011 Jun, Dmitry Kazakov wrote:
> > Hi!
> >
> > As we discussed at the last Krita sprint, Krita needs some common system
> to
> > manage keyboard shortcuts and modifiers. The problem is, different
> keyboard
> > keys should switch tools temporarily and restore the tool when the key is
> > released. E.g. we need canvas panning, rotation, color picking, brush
> > adjustments.
> >
> > I was thinking about the design of this system. And i think it is better
> to
> > do it Calligra-wide. That's why I've published its design proposal to
> > Calligra wiki:
> >
> > http://community.kde.org/Calligra/Libs/Interactional_Tools
> >
> > Theoretically, all the other tools may be ported to it in the future, but
> > this is not mandatory as there are wrappers for old tools left.
> >
> > So i would really like to hear your opinion about this system.
> Especially,
> > about naming of the classes =)
> >
>
> It looks thorough, and it's a part of calligra that has long needed a bit
> of streamlining. I'm not sure about the details -- one thing that's
> important is that I'm not sure that we actually want to stack tools, like
> paint tool temporarily activates pan tool.
>
> This is the way it's already implemented currently, and it has a couple of
> disadvantages, most importantly that the tool option widget switches. It's
> also only used for zoom/pan.
>
> I'd say it's better to have these canvas tools implemented as interaction
> strategies every tool can use, and not as separate tools.
>
>
A) List of situation where from the user's point of view the tool needs to
change temporarily:
-- To pickup colors from the canvas.
-- To pan.
-- To zoom.
-- To spin the canvas.

B) List of situations where it could be useful that other tools could be
invoked temporarily:
-- Any tool.

In case (A) it makes sense to implement pan, zoom, spin, and pickup color as
interaction strategies that every tool can use. But in case (B), only
switching tools could achieve the effect (otherwise, one strategy for every
tool would have to be created, and it would be basically the same than
having many different interchangeable tools).

I don't know how every person in the world will use Krita, but I know that
users always find a way to use a feature differently to how we anticipate
it; the more versatility, the more power we give them.
I think the problem of the Widgets for tools switching when a tool is
invoked temporarily should be configurable by the user, for example with a
checkbox labelled:
[x] Do not switch the tool options widget when a tool is invoked
temporarily.

Then they can decide for the behavior they find more comfortable.


And finally, to DmitryK: the names of the classes are good, the design is
clear, and the best of all is that since this is a design document, when you
implement it your design proposal will become its own documentation.

I fully support this change, it is thorough and versatile.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20110614/c1dc0f45/attachment.htm