Btw, during these discussions I've found two probable problems in this design. <br><br>1) Modifiers of some tools depend on the current state of the tool. So the structure of the tool and its modifiers represents a state machine. An example of it is Default Tool. Solution: the entire KoModifiersManager can be switched on transitions between states. The only trouble here is to ensure that the previous manager doesn't have any stroke in progress.<br>
<br>2) KoInteractionToolStrategy interface is not the best choice for full encapsulation of a tool behavior, because it is created when the stroke is already started. This has several disadvantages: 1) we cannot request from the strategy, what shortcuts it needs; 2) we cannot ask it to change the cursor (!) when the modifier is pressed but the stroke is not started. E.g. when you press Ctrl in KisToolFreehand, the cursor should change to color picking tool cursor even before starting actual picking.<br>
<br>I see only three solutions for this:<br>1) (i guess the best one) Encapsulate all the pre-stroke behavior into KisInteractionStrategy::Factory subclass and ask about the cursor from it. Btw, this class do already exist in the design.<br>
2) Add static functions to KoInteractionStrategy (quite weird).<br>3) Do not use KoInteractionTool, but implement a new one with good strategies those are not created again on every stroke and have a long lifetime.<br clear="all">
<br>-- <br>Dmitry Kazakov<br>