<div class="gmail_quote">On Mon, Jun 13, 2011 at 8:46 AM, Boudewijn Rempt <span dir="ltr">&lt;<a href="mailto:boud@valdyas.org">boud@valdyas.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5">On Sunday 12 June 2011 Jun, Dmitry Kazakov wrote:<br>
&gt; Hi!<br>
&gt;<br>
&gt; As we discussed at the last Krita sprint, Krita needs some common system to<br>
&gt; manage keyboard shortcuts and modifiers. The problem is, different keyboard<br>
&gt; keys should switch tools temporarily and restore the tool when the key is<br>
&gt; released. E.g. we need canvas panning, rotation, color picking, brush<br>
&gt; adjustments.<br>
&gt;<br>
&gt; I was thinking about the design of this system. And i think it is better to<br>
&gt; do it Calligra-wide. That&#39;s why I&#39;ve published its design proposal to<br>
&gt; Calligra wiki:<br>
&gt;<br>
&gt; <a href="http://community.kde.org/Calligra/Libs/Interactional_Tools" target="_blank">http://community.kde.org/Calligra/Libs/Interactional_Tools</a><br>
&gt;<br>
&gt; Theoretically, all the other tools may be ported to it in the future, but<br>
&gt; this is not mandatory as there are wrappers for old tools left.<br>
&gt;<br>
&gt; So i would really like to hear your opinion about this system. Especially,<br>
&gt; about naming of the classes =)<br>
&gt;<br>
<br>
</div></div>It looks thorough, and it&#39;s a part of calligra that has long needed a bit of streamlining. I&#39;m not sure about the details -- one thing that&#39;s important is that I&#39;m not sure that we actually want to stack tools, like paint tool temporarily activates pan tool.<br>

<br>
This is the way it&#39;s already implemented currently, and it has a couple of disadvantages, most importantly that the tool option widget switches. It&#39;s also only used for zoom/pan.<br>
<br>
I&#39;d say it&#39;s better to have these canvas tools implemented as interaction strategies every tool can use, and not as separate tools.<br><font class="Apple-style-span" color="#888888"><br></font></blockquote><div> </div>
<div>A) List of situation where from the user&#39;s point of view the tool needs to change temporarily:</div><div>-- To pickup colors from the canvas.</div><div>-- To pan.</div><div>-- To zoom.</div><div>-- To spin the canvas.</div>
<div><br></div><div>B) List of situations where it could be useful that other tools could be invoked temporarily:</div><div>-- Any tool.</div><div><br></div><div>In case (A) it makes sense to implement pan, zoom, spin, and pickup color as interaction strategies that every tool can use. But in case (B), only switching tools could achieve the effect (otherwise, one strategy for every tool would have to be created, and it would be basically the same than having many different interchangeable tools).</div>
<div><br></div><div>I don&#39;t know how every person in the world will use Krita, but I know that users always find a way to use a feature differently to how we anticipate it; the more versatility, the more power we give them.</div>
<div>I think the problem of the Widgets for tools switching when a tool is invoked temporarily should be configurable by the user, for example with a checkbox labelled:</div><div>[x] Do not switch the tool options widget when a tool is invoked temporarily.</div>
<div><br></div><div>Then they can decide for the behavior they find more comfortable.</div><div><br></div><div><br></div><div>And finally, to DmitryK: the names of the classes are good, the design is clear, and the best of all is that since this is a design document, when you implement it your design proposal will become its own documentation.</div>
<div><br></div><div>I fully support this change, it is thorough and versatile.</div></div>