guigtk: make double click handling consistent with Windows and macOS - #1633

@phkahler @ruevs friendly ping

This is a simple fix for a behaviour that has been bugging me for far too long on Linux. Can you please take a look?

My RaspberryPi (the only Linux machine I currently have) is tied up in something else, so I can't test this. That's why I kept quiet.

@iscgar I hate to say it but I don't even know what double clicking does in solvespace, so I can't really comment on how Windows and Linux differ in response to it. Is there some use for double clicks?

@iscgar I hate to say it but I don't even know what double clicking does in solvespace, so I can't really comment on how Windows and Linux differ in response to it. Is there some use for double clicks?

I don't think there's any part of the code that handles double clicks in any special way. Rather, the existing code treats the double click event as a regular click AFAICT. The problem with the GTK double click handling is that when a double click occurs, it behaves as if there was a triple click (because the events received are: click, click, double-click; whereas on Windows and macOS the events are: click, double-click). This is especially annoying in my named parameters branch, when I want to quickly create multiple parameters and double-click the "add" button, but it results in three parameters being added.

This is especially annoying in my named parameters branch, when I want to quickly create multiple parameters and double-click the "add" button, but it results in three parameters being added.

This situation is really ugly. My first reaction was "there go the GTK devs again being stupid", but after some thinking and reading they are giving the application developer all options for how to handle it. Some solutions:

1. what you're doing with the timer to eliminate the second click event.
2. We could just ignore double click events entirely - simpler?
3. We could ignore button down events (in the text window) and only respond to release events.

If your intent is for fast clicking to perform the same operation rapidly, I'd go with option 2 for simplicity since we don't use double click anyway. Or would that create inconsistent behavior between GTK and Windows/mac?

Editing a constraint that has a value (length, angle, ratio, difference) is a double-click.

[snip] Some solutions:

1. what you're doing with the timer to eliminate the second click event.

2. We could just ignore double click events entirely - simpler?

3. We could ignore button down events (in the text window) and only respond to release events.

If your intent is for fast clicking to perform the same operation rapidly, I'd go with option 2 for simplicity since we don't use double click anyway. Or would that create inconsistent behavior between GTK and Windows/mac?

I looked at the code more carefully, and apparently while the text window doesn't handle a double click in any special way, the graphic window does use it for constraint editing. So ignoring the double click event in general is not really possible.

We could theoretically just ignore the double click event in the text window, but because on Windows and macOS the second click is only delivered as a double click event, that would lead to double clicks being interpreted as a single click on those platforms, which is still inconsistent.

So this leaves 1 and 3, and of those I think 1 is the simplest fix, as it simply aligns the behaviour with the other platforms for consistency.

Editing a constraint that has a value (length, angle, ratio, difference) is a double-click.

Missed your message. Sorry for repeating.