Re: middle click panning and related

[Krzysztof Foltman <kfoltman portal onet pl>]

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

>>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 
or META).

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

Krzysztof