Call for ideas: requirements for Krita tool actions system

[Dmitry Kazakov]

On Sun, Jun 5, 2011 at 4:27 PM, Thorsten Wilms <t_w_ at freenet.de> wrote:

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

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.


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

I should think it over.



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

Interesting idea, btw.

-- 
Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20110605/d5f7aad4/attachment-0001.htm