<div class="h5"><br>
</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">If I have understood correctly there two types of shortcuts needed.<br>
1. Global shortcuts to change tools<br>
2. Local shortcuts to change a tools state<br>
<br>
What I think is that the global shortcuts should be handled by the<br>
toolmanager, as that is exactly the kind of things the toolmanager is doing.<br>
For local shortcuts I am not sure why it is not possible to fold the common<br>
shortcut/gesture handling into the KoInteractionTool base class? I think we<br>
should keep the number of involved classes at a minimum, otherwise no one can<br>
understand what is actually happening in our tool system.<br>
Also from reading your requirement list, I hope that you also looked at tools<br>
that are not krita tools.<br></blockquote><div><br>Well, I think I need to clarify it a bit.<br><br>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.<br>
<br>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.<br>
<br>Why I want to make a separate KoModifiersManager?<br>Because there are several layers where we can define a shortcut. There is no such separation as Local/Global. <br>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.<br>
2nd level. All the paint tools in Krita should support Color Picking. So we add a manager to KisToolPaint.<br>3rd level. KisToolFreehand tool should support Shift+Drag "gesture". So we add a manager here as well. <br>
<br>There might be many other actions and shortcuts we will add later.<br><br><br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Requirement 1:<br>
<br>
For instance shift drag is used to override the snapping. And there are<br>
probably other places where dragging with a modifier is used. So you will have<br>
a hard time reserving those for common stuff.<br></blockquote><div><br>Well, the snapping doesn't work in Krita correctly now, as far as I remember =) So we use this "gesture" for about a year.<br>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.<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Requirement 2:<br>
<br>
Single global key shortcuts are dangerous. The Ctrl modifier is use a lot, and<br>
the space key is also used at least in the text tools.<br></blockquote><div><br>Ctrl is defined in KisToolFreehand's scope. Space -- it is more difficult. Maybe, some priorities?<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Requirement 3:<br>
I do not understand that. Can you elaborate, preferably with an example.<br></blockquote><div><br>It was discussed in Krita list. Sorry for telling it too briefly.<br>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.<br>
<br>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.<br>
<br>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.<br> <br>This is more like idea, it is not to be implemented first.<br><br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Requirement 4:<br>
A Krita specific requirement, is there a more general example? What is canvas<br>
rotation actually, a tool?<br></blockquote><div><br>Canvas rotation is a mode of a pan tool. It rotates the view of the canvas. It should be as accessible as panning.<br> </div><div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Requirement 5:<br>
<br>
I am not sure i understand what you mean by that. Can you be more specific<br>
please? I.e. how should a tool be canceled when Esc is bound to another<br>
action?<br></blockquote><div><br>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.<br><br>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). =)<br><br>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. <br>
</div></div><br clear="all"><br>-- <br>Dmitry Kazakov<br>