RE: Binding a command to the down-event of a toolbar button

["Drew Adams" <drew.adams@oracle.com>]

    	>> Is such behavior normal in tool bars in other user interfaces?
    	>> If not, I think we should not do it.

        Why not? It's often good to stick to "normal", "standard",
        or common UI features so that users know what to expect.
        But what's the harm in providing functionality where the
        common UIs have none?

    You're missing the point.  You're proposing we implement the capacity
    to provide a certain kind of GUI feature.  Before we do that, I want
    to know whether users expect or want that kind of feature in GUIs.  If
    they don't, let's save the trouble of writing and maintaining code to
    implement it.

You're missing the point. I'm not proposing that we implement anything. I
said "What's the harm?", arguing only against the proposition that we should
stick to what other UIs do.

Your reason for proposing that we *not* implement this feature is based only
on what other user interfaces do and what users are asking for today. You
focused only on benefit, not cost, and you weighed the possible benefit in a
narrow way.

So I responded to the question of benefit: whether such a feature might be
useful. You proposed judging use value based only on what users might
already expect or request. I argued that that's too conservative, that Emacs
shouldn't necessarily limit its features to what other UIs provide or what
users are already asking for.

My guess is that many (most?) of the most important Emacs features were not
developed because users asked for them or because other UIs already had
them. They were invented or discovered by Emacs user-developers (many by
you!). Such stuff is being created everyday, with varying degrees of
usefulness ;-).

In sum, without considering cost, I see no reason "why not". Now you raise
the question of cost. Good initiative. No sense guessing at benefits if we
have no idea what this costs. Obviously, if the cost to develop a new
feature is great, and the expected benefit is small, then it should not be
undertaken. We do not know that that's the case here.

The cost/benefit questions are:
 a) What might be the benefit?
 b) What would be the cost (implementation and maintenance)?

Wrt benefit, let's not worry about what user's might expect from other UIs,
since this feature would neither satisfy those expectations nor interfere
with them - that consideration is irrelevant. That's the point I made
previously.

If the cost is minor then we don't need to assess a large benefit. So what's
the cost? We can guess that maintenance cost is roughly proportional to
implementation complexity. Anyone have an idea how hard this would be to
implement? Some people have already expressed interest in the feature here,
so presumably the benefit would not be zero. IMO, Stefan's press-and-hold
media-player app is argument enough in terms of benefit, if the cost is
small enough. Likewise, the arguments for mouse clicks other than mouse-1.