Allow user to assign alt-x cmds to mouseclicks

[HansBKK]

Wishlist request for those users that like to use the mouse.

Rather than leaving it up to plugins to "hijack" the definition of mouse-click behaviour, put it under the user's control with a mechanism similar to defining keybindings. All plugin actions should be "published" as alt-x command strings, so those that prefer keeping their fingers on the keyboard

Ideally a "priority list" for each trigger (say Ctrl-Click) based on node type.

More details here:
https://groups.google.com/d/msg/leo-editor/mjfQK-MM_wI/EU7UfQUD-7EJ

also previously discussed here:
https://groups.google.com/d/msg/leo-editor/kcPuYBa_qHU/Aq_zAJ-j7bQJ

Most recently triggered by:
https://groups.google.com/forum/#!topic/leo-editor/mjfQK-MM_wI/discussion
and:
https://groups.google.com/forum/#!topic/leo-editor/AoIyZeXI6yk/discussion

[tbnorth (terry-n-brown)]

On Sat, 17 Mar 2012 17:57:18 -0000
"Edward K. Ream" <email address hidden> wrote:

> ** Changed in: leo-editor
> Importance: Undecided => Wishlist

I'm not sure how the double click discussion played out, but to me this
item is probably the critical thing to avoid breaking bookmarks.py,
which I use a lot.

Also, I'm not sure how a plugin can define act_on_node in a way which
can be used by the key-binding system, e.g.

bookmarks-open-node ! tree = double-click

makes sense as a binding, but how would you refer to the version of
act_on_node defined by bookmarks.py in this context?

Probably no need to resolve that now, allowing command bindings to
mouse clicks would solve the problem for most people I think.

[tbnorth (terry-n-brown)]

Observation: Leo can't currently distinguish between single and double clicks,
or at least a double click always results in the single-click action
being executed *as well*. When single-click is select node and
double-click is edit node, that doesn't matter. More complicated
setups currently work and it would be a shame to break them. For
example, my setup:

single-click: select node if unselected, edit node if already selected

double-click: if a @bookmarks descendant, open bookmark (often opening
              a new outline)

For this to work, double-clicking and / or the command it invokes has
to make sure single clicking hasn't left the outline in a weird state.
For example in the above I think opening another outline explicitly
calls end_editing on the current outline to cancel any editing in
progress.

All this is working at the moment, just wanted to point it out so it
doesn't get tripped over in this new work.

Avoiding the single click event firing for double clicks would require
either a timer in the event handling code, or breaking the Arrow of
Time, with the latter being Edward's preference :-)

[Edward K. Ream (edreamleo)]

On Mon, Mar 19, 2012 at 6:10 PM, tbnorth <email address hidden> wrote:

> Observation:  Leo can't currently distinguish between single and double clicks,or at least a double click always results in the single-click action being executed *as well*.

Right. This is a good reason not to rely much on double clicks, imo.
That is, we want all double-click actions to be *compatible* with
single click actions.

I know of no reasonable strategy that would allow either Qt or Leo to
"look ahead" to see whether a double click was coming. Setting a
timer, as you did previously, is not good engineering, imo.

Selecting nodes is the heart of Leo's event logic. The code is
incredibly complex. It's surprisingly easy to break the code, and
surprisingly hard to get it right. I do not want to mess with that
code, and for sure I do not want to make the code dependent on race
conditions.

You are free to view this as a fundamental limitation. I have no
interest whatever in removing it.

Edward

[tbnorth (terry-n-brown)]

On Thu, 22 Mar 2012 13:20:29 -0000
"Edward K. Ream" <email address hidden> wrote:

> Selecting nodes is the heart of Leo's event logic. The code is
> incredibly complex. It's surprisingly easy to break the code, and
> surprisingly hard to get it right. I do not want to mess with that
> code, and for sure I do not want to make the code dependent on race
> conditions.

Fair enough - I don't think the timer approach actually breaks anything
or creates a race condition, but given that all desired use cases are
working without out (i.e. are working with the single-click and
double-click actions firing), there's nothing to gain at this point.

Aside, googling around, it seems the timer approach is used quite a bit
to deal with users double clicking things they're supposed to single
click (which 'general public' users do constantly). If you click
something that pops-up a menu, then click it again, the menu goes away
(Start button in windows for exampled). So a timer's used to ignore
the second click if it comes within the double click interval.

[Edward K. Ream (edreamleo)]

On Thu, Mar 22, 2012 at 11:33 AM, tbnorth <email address hidden> wrote:

> Aside, googling around, it seems the timer approach is used quite a bit.

You've made a strong case that using a timer is feasible. Still, I
would rather stick with the simplest thing that could possibly work.

Edward