<br><br><div class="gmail_quote">On Sun, Jun 5, 2011 at 4:27 PM, Thorsten Wilms <span dir="ltr"><<a href="mailto:t_w_@freenet.de">t_w_@freenet.de</a>></span> wrote:<br><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">On 06/05/2011 01:40 PM, Boudewijn Rempt wrote:<br>
</div><div class="im">> On Sunday 05 June 2011 Jun, Dmitry Kazakov wrote:<br>
<br>
</div><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>What do you mean with "total" here?<br>
<br>
As I'm jumping in here, I might be on the wrong train, but we'll see :)<br>
<br>
While many operations may be applicable independently, out of order,<br>
there surely will be dependencies? Can't draw on a layer that doesn't<br>
exist yet/anymore, not much sense in drawing outside of the canvas,<br>
because it hasn't been resized as expected.<br>
<br>
Reminds me of the Darcs's Theory of Patches, where patches do no have a<br>
sequence in general, but may rely on other patches.<br></blockquote><div><br>The aim of the scheduler is to put all this operations in a single queue and execute them one by one without overlapping in time. The overlapping is possible for special types of actions only.<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">>> 10) "Other types" I didn't managed to formalize them.<br>
<br>
</div>Is or should there be some "mode" framework in place?<br>
<br>
Where a mode would be any (sub-)state that changes the interpretation of<br>
further input. (Maybe even generalized beyond user action.)<br>
<br>
So (user input) events trigger actions, often with a 1:1 mapping, but<br>
potentially n:m. Some of these actions are for entering and leaving modes.<br>
<br>
Each mode would have a scope, described by the set of events that will<br>
be interpreted differently. Since several modes can be active at once,<br>
they need to have an order and work like filters on the event stream.<br></blockquote><div><br>I should think it over.<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>
<br>
> We did that before, but the users didn't like it because the option<br>
> widget changed. I think that we should have two kinds of tools: normal,<br>
> and temporary, where the temporary tool only changes the cursor but not<br>
> the option widget.<br>
><br>
> When should we move back to the first tool? On release of shortcut,<br>
> or on pressing another key? We had the p->pan, b->back to freehand<br>
> shortcuts, but users didn't like those.<br>
<br>
</div>The 3D application Softimage has some single key commands, where<br>
pressing the key will switch tools until the next tool-change, but<br>
holding down the key will work as quasi-mode, that is the switch happens<br>
on key-down and will be undone on key-up.<br>
<br>
This may sound complicated at first, but at least for me it didn't take<br>
long to make use of it.<br></blockquote><div><br>Interesting idea, btw. <br></div></div><br>-- <br>Dmitry Kazakov<br>