<br><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;"><div><div class="h5"><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;">
</blockquote></div></div></div>This would be a major change and basically turns the whole tool system upside down. I would prefer the changes to be much less invasive and I think that is possible.<br></blockquote><div><br>
Well, there are not much changes in flake. I just added new classes there. And new tools can be written with them. Old ones can work as usual. All the "invasive" changes will happen in KisTool and lower. Take into account that these classes will be rewritten anyway while encapsulating their actions for the scheduler. So these shortcut changes will be a kind of side-work =)<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;">I think the two level with the tool at global level and strategies at local level should stay.</blockquote>
<div><br>Yep, that is already done in flake. But noone uses it. We have 8 interactional tools only (5 in flake itself, 1 in each of karbon, tables, treeshape).<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Tools need to have control about the strategy that is activate e.g. look at the default tool, the next strategy depends on the content and state of the tool. </blockquote><div><br>The state machine of the switching is a good point actually. I need to think it over. It should be generalized as well.<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;">That's why it's not possible to move that to a higher level as that manager can only decide based on shortcuts and gestures.<br>
</blockquote><div><br>For most of the tools we can assume that we can do panning and rotation when the user does not hold any mouse button pressed. This is the idea of KoToolBaseStrategyWrapper. <br>For all the interactional tools there is no such problem, because you can know what it is doing by checking currentStrategy() pointer. And that is the idea of KoInteractionToolStrategyWrapper.<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
One global manager should be enough for that. Additionally tools could block global switches while working.<br></blockquote></div><br>How are you going to communicate between this global manager and all the tools? And how will it process semi-global shortcuts, like the ones those should be activated for KisToolPaint only? There should be more than two layers of shortcuts.<br clear="all">
<br>-- <br>Dmitry Kazakov<br>