Lars Clausen wrote:
> Putting it into the Tool structure would be fine. In case we get to have
> more than one transient tool, the user might want to have several levels of
> transience (say, doing Rotate then needing to do Scroll during that).
Several levels of transience ? Sounds like a usability engineer's
nightmare... And what if I'm using Rotate, then nested Scroll, then
nested Rotate ? :) (global transience stack would work in this
situation, although I'm really not convinced about usefullness of nested
transience at all).
BTW: Imagine yourself (or, better, a non-programmer) using nested
transience (and situations where it's beneficial). Or try explaining it
to some PHB you know.
Transience of switchable tool (replacing one transient tool with
another, but without nesting) is probably easier to understand, and
almost equally practical.
> Having the old tool stored in the new tool makes it easy to understand
> what's going on.
Except above situation (same tool used twice in transience stack). We'd
have to detect and avoid such situations, which makes it no longer easy
to understand. As I wrote before, transient tool selection (nested or
not) is something that belongs to the tool selection mechanism, not to
>>tightly-tied to modifier keys). Then, a mapping function may be added
>>for mapping a modifier set to flag set (with right choice of flag
>>values, it might be a simple &).
> Well, these were all central _UI_ calls.
Then, shouldn't we have a set of non-UI (scripting/plugin API) calls too ?
> It's still a lot better than having half a dozen different extra parameters
> percolating through the call chain for various things.
How deep is that call chain ? Not very deep it seems. I see no
practically significant problem (except that modifier key parsing can be
done in separate function to allow modifier key configurability - users
could choose if they wanted stickyness to be selected by SHIFT, CONTROL
> The fact that the modifier keys are used in a different place than they are received
> doesn't mean the parsing should be sent out there.
What do you mean ? (the structure of this sentence confuses me a bit) I
think parsing _should_ be sent out the, but it should be a function call
and not copied code as it is now.