Proposal for new modifiers/shortcuts system

[Dmitry Kazakov]

> If I have understood correctly there two types of shortcuts needed.
> 1. Global shortcuts to change tools
> 2. Local shortcuts to change a tools state
>
> What I think is that the global shortcuts should be handled by the
> toolmanager, as that is exactly the kind of things the toolmanager is
> doing.
> For local shortcuts I am not sure why it is not possible to fold the common
> shortcut/gesture handling into the KoInteractionTool base class? I think we
> should keep the number of involved classes at a minimum, otherwise no one
> can
> understand what is actually happening in our tool system.
> Also from reading your requirement list, I hope that you also looked at
> tools
> that are not krita tools.
>

Well, I think I need to clarify it a bit.

These shortcuts should not switch tools (in technical meaning), ideally.
These shortcuts are used for e.g. Color Picking during painting with the
freehand tool (with Ctrl key), panning (with Space), zooming (with
Ctrl+Alt+Space). So ideally, these shortcuts should just temporarily
activate some strategy, change canvas/settings and return the control to the
main tool. There should be no change in UI happen.

Shift+Drag. We haven't created a good name for this action yet. Currently it
is called "gesture", but that is not good due to a conflict with Qt's
definition of a gesture. So we use such "gesture" for configuring the size
of the brush. The user presses the Shift key and starts a drag on a canvas.
The size of the brush changes respectfully.

Why I want to make a separate KoModifiersManager?
Because there are several layers where we can define a shortcut. There is no
such separation as Local/Global.
1st level. We want all the tools (including calligra tools) to support
canvas rotation, zooming, panning. So we add a modifiers manager to
KoToolProxy (maybe, that is not the best place?) to catch all the events.
2nd level. All the paint tools in Krita should support Color Picking. So we
add a manager to KisToolPaint.
3rd level. KisToolFreehand tool should support Shift+Drag "gesture". So we
add a manager here as well.

There might be many other actions and shortcuts we will add later.




>
> Requirement 1:
>
> For instance shift drag is used to override the snapping. And there are
> probably other places where dragging with a modifier is used. So you will
> have
> a hard time reserving those for common stuff.
>

Well, the snapping doesn't work in Krita correctly now, as far as I remember
=) So we use this "gesture" for about a year.
That is really bad, that we don't have any common place where all these
modifiers are defined. They are done in ad-hoc manner in every tool or
manager.


>
> Requirement 2:
>
> Single global key shortcuts are dangerous. The Ctrl modifier is use a lot,
> and
> the space key is also used at least in the text tools.
>

Ctrl is defined in KisToolFreehand's scope. Space -- it is more difficult.
Maybe, some priorities?


> Requirement 3:
> I do not understand that. Can you elaborate, preferably with an example.
>

It was discussed in Krita list. Sorry for telling it too briefly.
There was an idea: when you press the key, the tool switches to some other
tool. If you release the key instantly, then the tool will be switched
permanently. If you keep holding the key pressed, the tool will be switched
back when you release the key.

Long selection process: you are painting something, press 's' for selection,
tool switches, you paint with selection tool to make a selection, then you
press 'f' for the freehand tool and continue painting.

Fast selection process: you are painting something, press 's' for selection
and keep it pressed, tool switches temporarily, you paint with selection
tool to make a selection, then you just release the 's' key to continue
painting.

This is more like idea, it is not to be implemented first.


Requirement 4:
> A Krita specific requirement, is there a more general example? What is
> canvas
> rotation actually, a tool?
>

Canvas rotation is a mode of a pan tool. It rotates the view of the canvas.
It should be as accessible as panning.



> Requirement 5:
>
> I am not sure i understand what you mean by that. Can you be more specific
> please? I.e. how should a tool be canceled when Esc is bound to another
> action?
>

E.g. you started a stroke (or dragging a shape), then you decided you don't
want to do this, you don't release mouse button, but just press Esc key to
interrupt and undo the action.

I think Ecs shouldn't be bound to any actions, because this is a common way
to interrupt the action in all the applications (except of emacs, of
course). =)

Well, maybe your question means how the manager solves the conflicts. It
doesn't solve them. And it doesn't do any assignment of shortcuts. They are
hardcoded currently. I think there should be a separate system that assigns
them and allows the user to configure them. These classes just implement
processing of these shortcuts.


-- 
Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/calligra-devel/attachments/20110614/d0259783/attachment.htm>