Re: [patch] middle click panning and related

[Lars Clausen <lrclause cs uiuc edu>]

On 12 Aug 2003, Krzysztof Foltman wrote:
> Lars Clausen wrote:
>
> > I was about to apply this, but some of the details in it are still too
> > messy.  For the panning, I still don't like having a new global variable
> > for the previous tool.  It should instead be passed to
> > create_scroll_tool and stored in the ScrollTool structure.
>
> I disagree. The ability to use a tool in a transient way is (IMHO) a
> property of selection mechanism and not a tool, and shouldn't be
> implemented in each tool separately. "Select tool as transient" vs
> "Scroll tool is transient" (it's not, it's only used that way).
>
> If you (say) add a Rotate or Autoconnect or Reparent tool and want to
> use it as a transient tool, you'll have to copy the transient
> selection code from ScrollTool. Not good I think. What more, imagine
> how restoring previous tool would work. Either the selection code
> would have to peek into ScrollTool (breaks encapsulation => ugly), or
> a "deactivate" tool function in ScrollTool would have to select the
> previous tool (I wanted to avoid that too, for the same reason).
>
> The previous tool might be stored in the Tool structure as well, but
> is that property really separate for each tool ?

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).
Having the old tool stored in the new tool makes it easy to understand
what's going on.

> > For the tool stickiness reversing -- which UI-wise is nice -- adding an
> > extra parameter to a bunch of central calls just for that is ugly --
> > better to pass in at least the full set of modifiers so they could be
> > used for other purposes.
>
> Set of modifiers... ok, but what if the central call is not used from
> UI, but (say) a scripting language or external API ? I think central
> calls should not depend too much on the UI itself. Of course, it could
> make sense to make the new parameter a set of flags (but not
> 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.

> Imagine we have an API call that takes a modifier key set and then
> someone decides that Dia 1.50 will have different modifier keys. Or
> that someone adds an API-only flag (not used as a modifier key bit in
> Gtk+), then a new version of Gtk+ is released, where this flag is set
> on every second mouse click. Instant disaster.

It's still a lot better than having half a dozen different extra parameters
percolating through the call chain for various things.  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.

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