Re: middle click panning and related



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




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]