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