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. _______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
