fix click handling

[GitMensch]

Quoting from the temporal TODO;

In ncurses and VT, a double-click or triple-click result in getting a double or triple-click event.

perfectly fine, with handling the click resolution by mouseinterval() - as this is explicit what is documented.
I assume wincon does the same.

In WinGUI, a double click gets you first a "normal" click, then a double-click event; a triple-click gets you those plus the triple-click event.c.

That's a real bad bug for me without any exception - no one should handle this in the application code - that's what mouseinterval() should handling and I can't think of a reason that the wingui port cannot handle this.

SDLx and X11 don't even handle double-clicks; you just get two 'click' events.

That's slightly better, but still bad, if mouseinterval() is ignored (which is not what the documentation in mouse.c says) then please create a bug report upstream.

[Bill-Gray]

mouseinterval() is not ignored on any platform; it's always used to determine if a press and release are close enough together to be consolidated into a click. But it's not necessarily used for double/triple clicks. Nothing in mouse.c mentions either double- or triple-clicks.
(Quick check) WinCon responds to a double-click with a single-click message, then a double-click. Same as WinGUI, but with no handling of triple-clicks. (Note that to determine this, I had to use a version of testcurs that shows scrolling results in the input test. The current version shows only the most recent result, and it's fast enough that the line telling you about the single-click is immediately overwritten by the double-click.)
This oddity is actually standard for the Windows API. As I recall, the general suggestion when handling mouse input in Windows was that double-clicks should only do something "in addition" to what a single-click would do.
It may be the "standard" for Windows, but (as with much involving MS Windows) it makes no real sense to me. I'm very much on board with the idea of all platforms going through common logic to provide results resembling those from ncurses and VT.
However, I'd rather not fix this until after giving @wmcbrine a shot at pulling code upstream. Should he do so, any fix could then be applied to a (hopefully more) unified code base.
Incidentally, DOS and OS/2 lack double-clicks, like SDLx and X11.

[GitMensch]

mouseinterval() is not ignored on any platform; it's always used to determine if a press and release are close enough together to be consolidated into a click. But it's not necessarily used for double/triple clicks.

I see, in this case we should discuss upstream (and maybe @wmcbrine is also willing to take on this task) about your "stack" mouse events suggestion (which seem to leaves the combination with the keyboard out - those events would need to be gathered separately and added to the final result; like [ALT]+[SHIFT]+[double click] along with [ALT]+[SHIFT]+[press]); and I'd highly suggest to use mouseinterval() for the stack-time, too, not only for the click (which would then still be handled identical to now).

It may be the "standard" for Windows, but (as with much involving MS Windows) it makes no real sense to me.

The good thing is that PDCurses is not about windows but about curses. Therefore the goal for all ports (including wincon/wingui) should be to be identical.

[Bill-Gray]

OK, couldn't resist a little tinkering. WinGUI now has the logic in it for "proper" mouse click handling abstracted. At some point, it can be pulled out and used for other platforms; right now, I figure I've provided William enough to think about for upstream merging.
It does mean, though, that WinGUI no longer follows the Windows convention of a double-click resulting in "click, double-click", nor a triple-click causing "click, double-click, triple-click". It follows the (to me and you) saner convention that a double-click gets a double-click event, and a triple-click gets a triple-click.
Combinations with the keyboard actually fell out almost automatically. The logic did turn out to be somewhat less logical (and more complicated) than I'd envisioned. On the bright side, it's simpler than the mare's nest of code I originally had in WinGUI (and means we get "sane convention" events in the bargain.)

[GitMensch]

Sounds good. As mentioned before the most important thing is not a Windows convention but a convention that is concise between the ports and following curses convention. Can you please create an issue upstream about which things you've changed (referencing the commits for easier merge) and which open points (general abstraction I think) are there? Just to ensure this doesn't get lost...

[GitMensch]

The release notes say:

enable double and triple clicks on all ports, not just VT and WinGUI.

Sounds good

[GitMensch]

@Bill-Gray What is the current state of the click handling between the ports now?

[Bill-Gray]

Not very good, I'm afraid.

Only VT and WinGUI have triple clicks... and I just gave it a try with testcurs, and on those platforms, a triple click gets you a "released" event. The logic on those platforms is more logical than it was, but still isn't as logical as one might like. I've not even tried to apply that logic to the other platforms, and don't think I will until 4.2.1 is released. I consider that to be almost entirely a bug-fix release. So I want the existing VT/WinGUI logic to work correctly for triple clicks, but don't plan on extending it to the other platforms yet. I want to be thoroughly happy about the VT/WinGUI version, then extend it everywhere.

(Thus far, 4.2.1 will add the PDC_set_default_colors() function for use in Plan9 and perhaps elsewhere (commit b642c91); GitHub CI use (commit 3cb1b5f and several subsequent commits); some fixes to makefiles, and small modifications to make nuisance compiler warnings go away; and some PDC_beep fixes... really, regressions, where we've decided that piling up beeps could be more annoying than helpful. You can copy/paste on Windows with Ctrl-C/Ctrl-V (commit 9f487d4); Windows users didn't really expect to be using Ctrl-Shift. For debug builds, a whole slew of functions check for NULL pointers instead of just silently ignoring the error (commit 96f4984). The version string now reflects the date constants from curses.h, instead of the date of compilation (commit 1024ee4). Nothing particularly earth-shaking, but this is a "change" version, not even a "minor" version.)

[GitMensch]

Friendly ping on the status.

[Lyle-Tafoya]

I'm not sure if this is the correct place to post about the issues I am having with detecting clicks on the GL build. I am seeing that no matter what mouseinterval I set, I always get a mouse press event followed by a mouse release event, but never a mouse click event (let alone double or triple click). It would appear that I need to set mouseinterval(0) and detect clicks on my own if I want consistent behavior between the wincon and gl builds of my application. Let me know if this should be a separate bug report. I see this discussion is more about handling of double and triple clicks, so the issue I am seeing is closely related, but not necessarily the same issue.

[Bill-Gray]

Yup, it's a separate issue. (One I'm not seeing, which may be yet another SDL 2.x.x variation; there seem to be a lot of them. Your fix looks good, though.)