<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 class="im">
</div>Do you intend to rewrite the tools to no longer be KoToolBase tools working on KoCanvasBase-based canvases? There's some job facilities in calligra/libs/main/KoAction, but it's not very pretty code.<br></blockquote>
<div><br>Of course no! =)<br>I just don't want the tools to have direct access to mouse events. Atm I'm investigating flake/tools/ code and it looks like KoInteractionTool/KoInteractionStrategy is exactly what we need. I think I'll just rebase KisTool onto KoInteractionTool. Or kind of it.<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;">
On that note: how about the other flake tools? I guess those don't need to be queued that much, but flake layers still cause canvas updates.<br></blockquote><div><br>Well, I'm afraid we'll have to override them with our own tools (through the inheritance), because we'll have to add the stuff like rotation/gestures/panning to them.<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;"><div class="im">
> 1) The scheduler should serialize stroke and merge actions. The order of<br>
> actions accessing the same pixels should be total.<br>
<br>
</div>I didn't really understand this sentence.<br></blockquote><div><br>Ok, total order of execution means that two actions do not overlap in time.<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;">
There are also tools that only affect the canvas display, like panning.<br></blockquote><div><br>Yes. And this is quite good question whether we should enqueue such tools into the same queue or not? How do you think? That would be quite good to be able to pan the canvas during the canvas update.<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">
> 11) All the tools should support common gestures those change their<br>
> parameters. E.g. Shift+Drag. We can add different types of drags, like<br>
> Shift+Vertical Drag and Shift+Horizontal Drag, the type of drag may be<br>
> recognized automatically.<br>
<br>
</div>I think we need to find a better name for this than gestures, because people are bound to be confused by the Qt gesture framework.<br></blockquote><div><br>Agree. Any suggestions?<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;">
<div class="im">
> 12) On some modifiers, like Ctrl and Space, the current tool shoud be<br>
> switched to another one temporarily, like to Color Picker Tool and Pan Tool.<br>
<br>
</div>We did that before, but the users didn't like it because the option widget changed. I think that we should have two kinds of tools: normal, and temporary, where the temporary tool only changes the cursor but not the option widget.<br>
<br>
When should we move back to the first tool? On release of shortcut, or on pressing another key? We had the p->pan, b->back to freehand shortcuts, but users didn't like those.<br></blockquote><div><br>We can just switch the strategy of the interaction tool. The icon and behavior change, but the tool doesn't. The main tool should be activated back on releasing the modifier. And shortcuts like 'p', 'b' should switch the tool completely, I guess.<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;">
<div class="im">
> 13) Canvas rotation should be accessible from all the tools.<br>
> 14) The tool's stroke and decorations should be cancelled on pressing Esc.<br>
> 15) Mouse Wheel should do Pan/Zoom in all the tools.<br>
<br>
</div>Maybe we can implement that in the canvas, instead of in the tools?<br></blockquote><div><br>It may cause problems if tools decide to override this behavior. And I'm not sure this behavior will correlate with different modes of the tools well. <br clear="all">
</div></div><br>-- <br>Dmitry Kazakov<br>