Re: middle click panning and related

[Lars Clausen <lrclause cs uiuc edu>]

On 13 Aug 2003, Krzysztof Foltman wrote:
> 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).

There's no problem in having multiple instances of a tool in the chain, if
you really want that:)

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

It's not that you'd sit down and say "now, let's use three levels of nested
tools".  It's a question of the transient tools always being available in a
consistent manner.

> Transience of switchable tool (replacing one transient tool with
> another, but without nesting) is probably easier to understand, and
> almost equally practical.

I think that's bad.  Imagine, as before, that you're in the middle of
rotating, and then want to scroll a bit.  *poof* When done scrolling,
you're suddenly not rotating anymore.  That's confusing.

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

No, that's not a problem, there can be multiple instances on the stack.
And it's also very unlikely to be necessary.

> As I wrote before, transient tool
> selection (nested or not) is something that belongs to the tool
> selection mechanism, not to the tool.

Now that's a thing that makes sense.  So how about having, instead of a
variable active_tool, a stack active_tools, plus get_active_tool(),
push_tool(), pop_tool() to encapsulate it.  This is not in a time-critical
area, so encapsulating like that is fine, and removes access to a global
variable, which I would be happy to see.

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

For inverting stickiness of tool selection?  This is purely UI, the
scripting & plugin API has nothing to do with it.

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

Not very deep, but it'd still get messy.

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

a) Modifier key parsing can always be encapsulated.
b) Modifier key configurability sounds like a messy problem, especially for
people trying to help Dia users.  "Now hold down Shift while pressing Box
-- or whichever key you configured to invert stickiness."  I can see why
people used to other programs would want to configure to match theirs, but
it gets very confusing to talk about program behaviour then.

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

Yes, a function call would be good.  What I'm saying is there's no need to
parse it at earliest opportunity and then send in the results as a whole
bunch of parameters, it's plain messy.

-Lars

-- 
Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| HĂ„rdgrim of Numenor
"I do not agree with a word that you say, but I   |----------------------------
will defend to the death your right to say it."   | Where are we going, and
    --Evelyn Beatrice Hall paraphrasing Voltaire  | what's with the handbasket?