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

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

[Stefan Monnier]

I'm trying to add tool-bar buttons for "fast forward" and "rewind" in my
MPC.el package, and the way I expected it would work is that down-mouse-1 on
those buttons would start the ffwd/rewind and the up event would stop it.

But looking at the tool-bar bindings (I wasn't familiar with the tool-bar
until recently), I see that I can not distinguish a "down" event from
any other.  Basically, I can only bind a command to a "click".

Am I missing something?  If not, should we add a note anout it in the
TODO file?  I'd expect each button to not have just a command associated
with it, but a complete keymap instead (I wouldn't necessarily try to
support non-mouse bindings in those keymaps, tho) so I could have different
bindings for clicks, double clicks, mouse-1, mouse-2, ...


        Stefan

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

[Richard Stallman]

    I'm trying to add tool-bar buttons for "fast forward" and "rewind" in my
    MPC.el package, and the way I expected it would work is that down-mouse-1 on
    those buttons would start the ffwd/rewind and the up event would stop it.

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

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

[Mathias Dahl]

>    I'm trying to add tool-bar buttons for "fast forward" and "rewind" in my
>    MPC.el package, and the way I expected it would work is that
>    down-mouse-1 on
>    those buttons would start the ffwd/rewind and the up event would stop it.
>
> Is such behavior normal in tool bars in other user interfaces?
> If not, I think we should not do it.

I have never seen such a functionality in a *tool-bar*. But buttons
like these are common in "media players" of all kinds, where the
buttons are often part of some "cool" or "groovy" GUI. I would not
expect a tool-bar button to do that, but that's just me.

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

[Stefan Monnier]

>> I'm trying to add tool-bar buttons for "fast forward" and "rewind" in my
>> MPC.el package, and the way I expected it would work is that down-mouse-1
>> on those buttons would start the ffwd/rewind and the up event would
>> stop it.
>> 
>> Is such behavior normal in tool bars in other user interfaces?
>> If not, I think we should not do it.

I use Emacs's tool-bar as a "control bar", so its behavior doesn't need to
be related to what people are usually accumstomed for tool-bars.
See http://www.iro.umontreal.ca/~monnier/elisp/mpc.png for a snapshot.

> I have never seen such a functionality in a *tool-bar*. But buttons
> like these are common in "media players" of all kinds, where the
> buttons are often part of some "cool" or "groovy" GUI. I would not
> expect a tool-bar button to do that, but that's just me.

I don't think my media player is being partiocularly "cool" or "groovy", but
I think it makes sense to provide stop/play/ffwd/rewind buttons on
the toolbar.  Right now my ffwd and rewind buttons are toggles that
start/stop the action.  This toggle behavior is not bad (and sometimes
useful) but I'd like to be able to also offer the press-and-hold behavior
which may be more convenient in other situations.

The other alternative is to not use the toolbar and create one by hand out of
a normal Emacs window displaying a buffer with no header-line and no
mode-line and whose content will be just a bunch of images (icons), ...
But that's a lot of work and is likely to never work nearly as well.

I think my request for down-events on the tool-bar is related to some other
people's requests to be able to bind different actions for mouse-1, mouse-2,
mouse-3.


        Stefan

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

[Drew Adams]

    >> 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? Users of common UIs won't
think to try press-and-hold or mouse-3 on a tool-bar icon, and they won't be
shocked by the possibility.

    I use Emacs's tool-bar as a "control bar", so its behavior
    doesn't need to
    be related to what people are usually accumstomed for tool-bars.
    See http://www.iro.umontreal.ca/~monnier/elisp/mpc.png for a snapshot.

Looks good to me.
BTW - The pause symbol usually has vertical, not horizontal bars.

    I'd like to be able to also offer the
    press-and-hold behavior
    which may be more convenient in other situations.

Yes, why not?

    I think my request for down-events on the tool-bar is related
    to some other people's requests to be able to bind different
    actions for mouse-1, mouse-2, mouse-3.

Yes, why not? (I was one of the "other people", for the same reason: why
not?)

Why limit Emacs, even if it is not common for GUIs to use other mouse keys
or press-and-hold on tool-bar icons? Tool bars are not all that useful
anyway - why not see if Emacs developers and users can improve on this
not-so-useful cliche? At one time even menus and mice were crazy
experiments.

IOW, it wouldn't hurt to open up the feature set here, and allow for some
invention. There is nothing sacrosanct about the dominant UIs. If using
press-and-hold with a tool bar turns out to be not very useful, that will
soon become apparent and that potential feature will remain unused. If it
turns out to be useful in some contexts, then we will have gained by
allowing the possibility.

Think of the Emacs mouse functionality (e.g. mouse-3 to extend selection,
mouse-2 to paste). If we respected the "norm" then we would have the same
brain-dead mouse as most apps.  Emacs can always do better, precisely
because it is open to experimentation by users. Let a hundred flowers bloom.

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Thu, 30 Mar 2006 15:03:42 -0800
> 
>     >> Is such behavior normal in tool bars in other user interfaces?
>     >> If not, I think we should not do it.
> 
> Why not?

Because I believe we still want to release Emacs 22.1 some time this
millenium.

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

[Jason Rumney]

Stefan Monnier wrote:
> I think my request for down-events on the tool-bar is related to some other
> people's requests to be able to bind different actions for mouse-1, mouse-2,
> mouse-3.
>   
Another interface I have seen that having a down-event would enable is 
to execute a common action on normal clicking of the button, but if the 
mouse button is held down for around 1 - 2 seconds, then a menu appears 
with less common related actions.

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

[David Kastrup]

Jason Rumney <jasonr@gnu.org> writes:

> Stefan Monnier wrote:
>> I think my request for down-events on the tool-bar is related to some other
>> people's requests to be able to bind different actions for mouse-1, mouse-2,
>> mouse-3.
>>   
> Another interface I have seen that having a down-event would enable is
> to execute a common action on normal clicking of the button, but if
> the mouse button is held down for around 1 - 2 seconds, then a menu
> appears with less common related actions.

Context menus on mouse-3 are rather common.  I think that we should
aim for Emacs 22 to just provide the "customary" Emacs keymap model on
toolbar buttons: it is sort of an "element of least surprise"
expectation.  Even though we should not start any user interface
experiments actually _using_ that possibility right now ourselves.
But I think it should be available for the taking.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Stefan Monnier]

>> I think my request for down-events on the tool-bar is related to some other
>> people's requests to be able to bind different actions for mouse-1, mouse-2,
>> mouse-3.
> Another interface I have seen that having a down-event would enable is to
> execute a common action on normal clicking of the button, but if the mouse
> button is held down for around 1 - 2 seconds, then a menu appears with less
> common related actions.

Actually, I've only seen such behavior on Mac OS X where they have to deal
with 1-button mouses (and where this context menu is also available (without
delay) on mouse-3, if you have a 3-button mouse, or IIRC also with
C-mouse-1).

This said, a more pressing issue is the fact that clicked are dropped on the
floor if they happen just during redisplay.  This is *very* annoying if your
display includes a seconds-precise timer or worse.  It make it difficult in
MPC.el to stop the fast-forward (or rewind) since they cause constant
redisplay (since the seconds-precise counter counts then even faster
than 1s/s).


        Stefan

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

[Richard Stallman]

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

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

[Richard Stallman]

    I have never seen such a functionality in a *tool-bar*. But buttons
    like these are common in "media players" of all kinds, where the
    buttons are often part of some "cool" or "groovy" GUI. I would not
    expect a tool-bar button to do that, but that's just me.

When Emacs has a media-player mode, we want it to have such buttons.

So, is it better for these buttons to appear in the buffer itself,
or in the tool bar?  Better from a UI standpoint, that is.

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

[Drew Adams]

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

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

[Richard Stallman]

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

    Because I believe we still want to release Emacs 22.1 some time this
    millenium.

We certainly won't do this now; the question is whether we want to
do it after the release.

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

[Kevin Rodgers]

Richard Stallman wrote:
>     I have never seen such a functionality in a *tool-bar*. But buttons
>     like these are common in "media players" of all kinds, where the
>     buttons are often part of some "cool" or "groovy" GUI. I would not
>     expect a tool-bar button to do that, but that's just me.
> 
> When Emacs has a media-player mode, we want it to have such buttons.
> 
> So, is it better for these buttons to appear in the buffer itself,
> or in the tool bar?  Better from a UI standpoint, that is.

If they were in the buffer itself, then they wouldn't depend on which
buffer was selected -- they would always be displayed, so the user could
always click on them, even while working in another buffer.  The tool
bar changes according to which buffer is selected, just like the menu
bar changes, because they are defined as keymaps.

If the buffer happened to display a long playlist, the header line would
be a good place to put the control buttons.

-- 
Kevin Rodgers

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

[Robert J. Chassell]

    > So, is it better for these buttons to appear in the buffer
    > itself, or in the tool bar?  Better from a UI standpoint, that
    > is.

Some of us do not use or see toolbars.  It is better that buttons
appear in the buffer than not appear at all.

What about consoles -- or people who are situationally or permanently
blind?

--
    Robert J. Chassell
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

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

[M Jared Finder]

Richard Stallman wrote:
> 	>> 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.

Yes, click and drag and mouse-2, mouse-3 are used in UIs.  Firefox is a 
good example of different things that are done with this:
* mouse-3 brings up a context menu that is used for customization
* mouse-2 opens a page in a new tab
* click and drag is used to move toolbar items around when in "customize 
toolbar" mode.

In short, yes, it would be useful to distinguish between different 
button presses in toolbars (and in the menus as well).

   -- MJF

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

[Stefan Monnier]

> If they were in the buffer itself, then they wouldn't depend on which
> buffer was selected -- they would always be displayed, so the user could
> always click on them, even while working in another buffer.  The tool
> bar changes according to which buffer is selected, just like the menu
> bar changes, because they are defined as keymaps.

That's true, but if you check my snapshot (at
http://www.iro.umontreal.ca/~monnier/elisp/mpc.png), you'll see that my
MPC.el uses several buffers in several windows and the toolbar is a very
natural location to put those player buttons.  I could create
yet-another-buffer and recreate a sort of toolbar manually in it (playing
with display, face, mouse-face, and keymap properties).  It would allow me
to solve my problem with the down-event thingy, but it'd be a lot more work,
since I'd have to reinvent the wheel one more time.

> If the buffer happened to display a long playlist, the header line would
> be a good place to put the control buttons.

The header lines are already used for other things,


        Stefan

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

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: drew.adams@oracle.com, emacs-devel@gnu.org
> Date: Fri, 31 Mar 2006 15:20:14 -0500
> 
>     >     >> Is such behavior normal in tool bars in other user interfaces?
>     >     >> If not, I think we should not do it.
>     > 
>     > Why not?
> 
>     Because I believe we still want to release Emacs 22.1 some time this
>     millenium.
> 
> We certainly won't do this now

Judging by the volume of the discussions in this thread, I was
beginning to fear otherwise.

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Fri, 31 Mar 2006 10:35:55 -0800
> 
> 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 ;-).

Actually, as far as GUI features are concerned, AFAIR most of them
were added because other GUI programs had them and users expected
them.

Non-GUI features are another matter.

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

[Richard Stallman]

    Another interface I have seen that having a down-event would enable is 
    to execute a common action on normal clicking of the button, but if the 
    mouse button is held down for around 1 - 2 seconds, then a menu appears 
    with less common related actions.

Can you tell us more about the graphical contexts where you've seen this?
Was it on buttons?  Menus?  Icons?

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

[Richard Stallman]

    This said, a more pressing issue is the fact that clicked are dropped on the
    floor if they happen just during redisplay.  This is *very* annoying if your
    display includes a seconds-precise timer or worse.

That is a bug, but I am very surprised we have such a bug.
The events are handled and generated an interrupt level, so how
can it matter whether redisplay is happening.

Are you running your change to move that processing out of the signal
handler?  Maybe that change causes the problem.

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

[Richard Stallman]

    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.

We have a lot of other work to do, so if this is not important, I don't
want it to distract developers' attention from other things.

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

[Drew Adams]

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

    Actually, as far as GUI features are concerned, AFAIR most of them
    were added because other GUI programs had them and users expected
    them. Non-GUI features are another matter.

I said "feature", which includes but is not limited to "GUI feature".

I mentioned the Emacs mouse behavior as one example (is it GUI or just UI? I
don't care). Another is incremental search (GUI or UI?). Emacs was
relatively late to the GUI game (at least what most people understand by
GUI), so it's probable that there were more user requests to "catch up" in
that area.

But that's irrelevant; Emacs's superiority was not achieved by playing
catch-up, fulfilling user requests to do what other apps do already. Someone
might have requested adding a mouse to Emacs, but I doubt if anyone asked
for the (superior) mouse behavior that we ended up with. Emacs has the
advantage of innovation that comes from many user-developers and, most
important, source code.

I'm the first to welcome borrowing ideas from other apps. I think there are
still some things that Dired could learn from Windows (not Internet)
Explorer, for instance. But we can always do better, and lack of user
requests for a feature or lack of the feature in other UIs is no argument
for not pursuing a feature in Emacs. Those can be arguments in favor of
developing a feature, but they are not good arguments against doing so.
Cost/benefit and lack of sufficient resources are good arguments.

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

[Stefan Monnier]

> That is a bug, but I am very surprised we have such a bug.  The events are
> handled and generated an interrupt level, so how can it matter whether
> redisplay is happening.

> Are you running your change to move that processing out of the signal
> handler?  Maybe that change causes the problem.

Hmm... that's a good point, I'll have to look deeper into it.


        Stefan

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

[Jason Rumney]

Richard Stallman <rms@gnu.org> writes:

> Can you tell us more about the graphical contexts where you've seen this?
> Was it on buttons?  Menus?  Icons?

Tool bar buttons. Many have a small arrow (triangle) to the lower
right to indicate that more actions are available. Methods of getting
to the advanced actions vary, I have seen applications where you the
hold down mouse-1, others where you press mouse-3, and others where
you click on the small arrow itself. All these methods result in a
drop down menu appearing.

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

[Richard Stallman]

    If they were in the buffer itself, then they wouldn't depend on which
    buffer was selected -- they would always be displayed, so the user could
    always click on them, even while working in another buffer.  The tool
    bar changes according to which buffer is selected, just like the menu
    bar changes, because they are defined as keymaps.

    If the buffer happened to display a long playlist, the header line would
    be a good place to put the control buttons.

That seems like a good argument.

And Emacs already supports the desired feature, for icons in the
buffer or in the header line.

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

[Richard Stallman]

    That's true, but if you check my snapshot (at
    http://www.iro.umontreal.ca/~monnier/elisp/mpc.png), you'll see that my
    MPC.el uses several buffers in several windows and the toolbar is a very
    natural location to put those player buttons.

Is it the only suitable location for them?

If it would also be natural to put them in a buffer, then by doing so,
we would avoid the need to implement such detection for the toolbar.

It is easy to put icons in a buffer and put keymaps on them.

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

[Richard Stallman]

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

    Yes, click and drag and mouse-2, mouse-3 are used in UIs.

That is not the question.

The question is whether other UIs make a distinction of down and up
clicks on tool bars.  And what UI design recommendations say about it.

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

[M Jared Finder]

Richard Stallman wrote:
>     > 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.
> 
>     Yes, click and drag and mouse-2, mouse-3 are used in UIs.
> 
> That is not the question.
> 
> The question is whether other UIs make a distinction of down and up
> clicks on tool bars.  And what UI design recommendations say about it.

Consider me completely confused then.

Are you saying you'd want to toolbars to support mouse-1 and 
drag-mouse-1 (as well as the same events for other mouse buttons), but 
*not* down-mouse-1?  Why?  By implementing drag, wouldn't you end up 
implementing down as well?

   -- MJF

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

[Richard Stallman]

	    Another interface I have seen that having a down-event would enable is 
	    to execute a common action on normal clicking of the button, but if the 
	    mouse button is held down for around 1 - 2 seconds, then a menu appears 
	    with less common related actions.

	Can you tell us more about the graphical contexts where you've seen this?
	Was it on buttons?  Menus?  Icons?

    Tool bar buttons. Many have a small arrow (triangle) to the lower
    right to indicate that more actions are available. Methods of getting
    to the advanced actions vary, I have seen applications where you the
    hold down mouse-1, others where you press mouse-3, and others where
    you click on the small arrow itself. All these methods result in a
    drop down menu appearing.

This sounds like a very special case.  The triangle is not a member
of the tool bar, it is a special part of the tool bar mechanism itself.

In the case where you get the menu by holding down mouse-1 on the
triangle, what happens when you just click mouse-1 there?

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

[Richard Stallman]

	Actually, as far as GUI features are concerned, AFAIR most of them
	were added because other GUI programs had them and users expected
	them. Non-GUI features are another matter.

    I said "feature", which includes but is not limited to "GUI feature".

Let's not spend time arguing about it.
Please, let this drop!

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

[Jason Rumney]

Richard Stallman <rms@gnu.org> writes:

>     Tool bar buttons. Many have a small arrow (triangle) to the lower
>     right to indicate that more actions are available. Methods of getting
>     to the advanced actions vary, I have seen applications where you the
>     hold down mouse-1, others where you press mouse-3, and others where
>     you click on the small arrow itself. All these methods result in a
>     drop down menu appearing.
>
> This sounds like a very special case.  The triangle is not a member
> of the tool bar, it is a special part of the tool bar mechanism itself.

The triangle is just a visual indicator to tell you that more than
just one action is available.

> In the case where you get the menu by holding down mouse-1 on the
> triangle, what happens when you just click mouse-1 there?

The "default action" for that toolbar button is executed.

As an example of how such a feature is used, the Print icon on the
Emacs tool bar currently runs print-buffer. In the above scenario, it
could drop down a menu when the mouse button was held down for more
than 1 second, offering access to print-region,
ps-print-buffer-with-faces and ps-print-region-with-faces as well.

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

[Richard Stallman]

    Are you saying you'd want to toolbars to support mouse-1 and 
    drag-mouse-1 (as well as the same events for other mouse buttons), but 
    *not* down-mouse-1?

I don't think I said anything about drag-mouse-1 on toolbars.  Now
that you raise the question, I don't see how drag events can make
sense on a tool bar icon.  You can't move these icons.

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

[Stefan Monnier]

>     That's true, but if you check my snapshot (at
>     http://www.iro.umontreal.ca/~monnier/elisp/mpc.png), you'll see that my
>     MPC.el uses several buffers in several windows and the toolbar is a very
>     natural location to put those player buttons.

> Is it the only suitable location for them?

I think so, yes.  But do look at the snapshot and tell me where else I could
conveniently put them.


        Stefan

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

[Richard Stallman]

    > In the case where you get the menu by holding down mouse-1 on the
    > triangle, what happens when you just click mouse-1 there?

    The "default action" for that toolbar button is executed.

Now I understand the scenario you are trying to describe.
I did not understand it before.  (I have never seen this.)

    As an example of how such a feature is used, the Print icon on the
    Emacs tool bar currently runs print-buffer. In the above scenario, it
    could drop down a menu when the mouse button was held down for more
    than 1 second, offering access to print-region,
    ps-print-buffer-with-faces and ps-print-region-with-faces as well.

That seems like a natural feature to provide, if someone wants to
implement it.  Not now, though.

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

[M Jared Finder]

Richard Stallman wrote:
>     Are you saying you'd want to toolbars to support mouse-1 and 
>     drag-mouse-1 (as well as the same events for other mouse buttons), but 
>     *not* down-mouse-1?
> 
> I don't think I said anything about drag-mouse-1 on toolbars.  Now
> that you raise the question, I don't see how drag events can make
> sense on a tool bar icon.  You can't move these icons.

And you are against doing the little amount of work to provide the hooks 
that would allow such functionality to get added?  Why?  You must have 
some reason you don't want this to ever get implemented.  Here's a few I 
can think of, along with my rebuttals:

It'd take too much time and be too complicated to implement.
   (I disagree; this should be no more than one day's worth of work.)

It'd be difficult to integrate into the existing framework.
   (I disagree; you'd just have to make the old tool-bar names be 
aliases for pressing keys *also* be prefix keys in specific functions; 
especially read-key-sequence.)

I don't like it; it's not a proven UI style.
   (I disagree; many widely used apps do exactly what I have described. 
  Both Firefox and OpenOffice do.  It is a good design from a UI design 
standpoint because it allows direct manipulation of the toolbar.)

We're trying to get to a release of Emacs 22.
   (Then implement it in Emacs 23.)

   -- MJF

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

[Richard Stallman]

    > Is it the only suitable location for them?

    I think so, yes.  But do look at the snapshot and tell me where else I could
    conveniently put them.

I will, but I'd also like to hear what others think.

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

[Richard Stallman]

    > I don't think I said anything about drag-mouse-1 on toolbars.  Now
    > that you raise the question, I don't see how drag events can make
    > sense on a tool bar icon.  You can't move these icons.

    And you are against doing the little amount of work to provide the hooks 
    that would allow such functionality to get added?

What is the user-level functionality that you are asking for?
I don't see what user-level functionality there would be
for drag events on tool bar icons.

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

[Richard Stallman]

I looked at your snapshot, and it looks nice with the tool bar,
but couldn't it be just as natural if you put those icons in a buffer?

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

[M Jared Finder]

Richard Stallman wrote:
>     > I don't think I said anything about drag-mouse-1 on toolbars.  Now
>     > that you raise the question, I don't see how drag events can make
>     > sense on a tool bar icon.  You can't move these icons.
> 
>     And you are against doing the little amount of work to provide the hooks 
>     that would allow such functionality to get added?
> 
> What is the user-level functionality that you are asking for?
> I don't see what user-level functionality there would be
> for drag events on tool bar icons.

All the previously stated features that other applications have, and any 
others that make sense; including, but not limited to:

* The ability to move the toolbar buttons around by clicking and 
dragging (perhaps when in a special mode, perhaps always).
* The ability to right click on a toolbar button and bring up a context 
menu.
* The ability to middle click on a toolbar button to perform a modified 
action (say, find-file-other-window instead of find-file).
* The ability to click-and-hold on a toolbar button to bring up an 
extended menu.

   -- MJF

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

[Richard Stallman]

    * The ability to move the toolbar buttons around by clicking and 
    dragging (perhaps when in a special mode, perhaps always).

I see no need for that.

    * The ability to right click on a toolbar button and bring up a context 
    menu.

That does not require support for drag events.

    * The ability to middle click on a toolbar button to perform a modified 
    action (say, find-file-other-window instead of find-file).

That does not require support for drag events.

    * The ability to click-and-hold on a toolbar button to bring up an 
    extended menu.

That requires support for down events, but not for drag events.

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

[M Jared Finder]

Richard Stallman wrote:
>     * The ability to move the toolbar buttons around by clicking and 
>     dragging (perhaps when in a special mode, perhaps always).
> 
> I see no need for that.
> 
>     * The ability to right click on a toolbar button and bring up a context 
>     menu.
> 
> That does not require support for drag events.
> 
>     * The ability to middle click on a toolbar button to perform a modified 
>     action (say, find-file-other-window instead of find-file).
> 
> That does not require support for drag events.
> 
>     * The ability to click-and-hold on a toolbar button to bring up an 
>     extended menu.
> 
> That requires support for down events, but not for drag events.

So then you're okay with adding a way to distinguish between mouse-1, 
mouse-2 and mouse-3 events, and down and up events?

   -- MJF

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

[Richard Stallman]

    So then you're okay with adding a way to distinguish between mouse-1, 
    mouse-2 and mouse-3 events, and down and up events?

I am talking about drag events.  Only about drag events.
Please do not confuse separate issues.

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

[M Jared Finder]

Richard Stallman wrote:
>     So then you're okay with adding a way to distinguish between mouse-1, 
>     mouse-2 and mouse-3 events, and down and up events?
> 
> I am talking about drag events.  Only about drag events.
> Please do not confuse separate issues.

I feel like you are evading my questions.  The original post I replied 
to was about down events, not drag events.  I brought up drag events as 
a similar extension that would be useful in addition.

Can you please give a direct answer to the following question.  If you 
have different reasons for different parts, state each reason:

Why are you against adding the necessary code to allow alternate mouse 
keys, distinguishing between down and up events, and drag events to be 
added?  I can think of multiple reasons why you *might* not want to add 
these events:

* It'd take too much time and be too complicated to implement.
* It'd be difficult to integrate into the existing code base.
* I don't like it; it's not a proven UI style.
* We're trying to get to a release of Emacs 22.

If you're not against adding such functionality, I'd rather just code up 
a patch and stop talking about its merits.  At worst, the extra 
functionality is just left unused.

   -- MJF

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

[Richard Stallman]

    I feel like you are evading my questions.  The original post I replied 
    to was about down events, not drag events.  I brought up drag events as 
    a similar extension that would be useful in addition.

We were discussing one subject and you brought up another.  I am
keeping these discussions separate, which is the only way I can deal
with them properly.  Please stop mixing them up.

    Why are you against adding the necessary code to allow alternate mouse 
    keys, distinguishing between down and up events, and drag events to be 
    added?  I can think of multiple reasons why you *might* not want to add 
    these events:

    * It'd take too much time and be too complicated to implement.
    * It'd be difficult to integrate into the existing code base.
    * I don't like it; it's not a proven UI style.

All of them.  I don't say it would be "too complicated to implement",
but it would be a little complicated.  I don't say it would be too
difficult to integrate, but it would make things more complex.
The first question is, "do we really need this"?

    * We're trying to get to a release of Emacs 22.

That's not a factor, because if we do this, it will certainly be after
the release.