Hrvoje Niksic <hniksic(a)srce.hr> writes:
wmperry(a)aventail.com (William M. Perry) writes:
> Why not make button1 do what you want there?
Context-sensitive menus have always been activated by button3, not
button1 or button2. Widgets like `State' look like a context-sensitive
menu to me.
This isn't really context-sensitive though. That is _all_ the state
button is meant to do. The context-sensitive menus should be offering
_additional_ functionality than the widget's main purpose.
To me, if I right-clicked on a standard widget, I would expect to see a
menu with ways to take actions like widget-browse-at, 'activate' widget,
etc. Or if it was in a 'repeat' widget, the add/insert/delete stuff would
be a good candidate to be on a menu like this.
> You wouldn't be able to get the standard context sensitive
menus in
> a GNUS article buffer if you just happened to have a
> buttonized/widgetized chunk of text under your mouse.
Gnus article buffers don't have context-sensitive menus. If you are over
a button/widget, button3 should present you a widget-specific menu.
_mode_ sensitive menus, they do. And the mode you are in, to me, is part
of the context. So they are context sensitive. :) Otherwise we'd allways
just see the standard undo/cut/copy/paste/clear/select/split/unsplit popup
menu on button3.
-Bill P.