Call for ideas: requirements for Krita tool actions system
dimula73 at gmail.com
Sun Jun 5 15:07:01 CEST 2011
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
> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the kimageshop