Proposal for new modifiers/shortcuts system

[jaham at gmx.net]

On Tuesday 14 June 2011 12:12:34 Dmitry Kazakov wrote:
> > 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.

Ok i see. Not one KoModifiersManager for all, but one for each case.

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

Well if you want canvas rotation, zooming and panning applicable to all tools, 
using single key shortcuts would be near impossible to use.
Other than that I really think we need those actions in all applications with 
consistent handling.

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

Ok I understand that better now.

> 
> 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 it could be done in stages (no pun intended). First press of Esc 
kesy will undo/cancel the current stroke/movement, second press will cancel 
the tool.

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