Call for ideas: requirements for Krita tool actions system

[Thorsten Wilms]

On 06/05/2011 01:40 PM, Boudewijn Rempt wrote:
> On Sunday 05 June 2011 Jun, Dmitry Kazakov wrote:

>> 1) The scheduler should serialize stroke and merge actions. The order of
>> actions accessing the same pixels should be total.

What do you mean with "total" here?

As I'm jumping in here, I might be on the wrong train, but we'll see :)

While many operations may be applicable independently, out of order, 
there surely will be dependencies? Can't draw on a layer that doesn't 
exist yet/anymore, not much sense in drawing outside of the canvas, 
because it hasn't been resized as expected.

Reminds me of the Darcs's Theory of Patches, where patches do no have a 
sequence in general, but may rely on other patches.


>> Tool types:
>>
>> 7) "Single Click". Action starts after a click is done. E.g. Color Picker
>> Tool, Fill Tool
>> 8) "Single Drag". Action starts after a drag is done. E.g. Gradient Tool,
>> Ruler Tool
>> 9) "Incremental Drag". Action starts when the mouse button is pressed and
>> the drag is started, the internal jobs are added incrementally. E.g.
>> Freehand Tool, Move Tool
>> 10) "Other types" I didn't managed to formalize them.

Is or should there be some "mode" framework in place?

Where a mode would be any (sub-)state that changes the interpretation of 
further input. (Maybe even generalized beyond user action.)

So (user input) events trigger actions, often with a 1:1 mapping, but 
potentially n:m. Some of these actions are for entering and leaving modes.

Each mode would have a scope, described by the set of events that will 
be interpreted differently. Since several modes can be active at once, 
they need to have an order and work like filters on the event stream.


>> 12) On some modifiers, like Ctrl and Space, the current tool shoud be
>> switched to another one temporarily, like to Color Picker Tool and Pan Tool.
>

> 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.
>
> 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.

The 3D application Softimage has some single key commands, where 
pressing the key will switch tools until the next tool-change, but 
holding down the key will work as quasi-mode, that is the switch happens 
on key-down and will be undone on key-up.

This may sound complicated at first, but at least for me it didn't take 
long to make use of it.


-- 
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/