Hi Branden, all,
On 6/29/25 02:36, G. Branden Robinson wrote:> 1. ungetmouse() seems to
work only once. Once I've retrieved the two
event I push onto the mouse event stack by typing 'z', my loop stops
behaving as I expect. Typing 'z' 3 times, I get:
16777216 524288 X X X X X X
Same here (with ncurses 6.2.2020212; note elderly version!). Also,
I only get the two events returned if no other mouse activity has
taken place. Click a mouse button and _then_ hit 'z', and nothing happens.
I think there may be a synchronization problem here, though. If I
change 'while( getmouse(&evt)...' to 'if( getmouse(&evt)...', I get
what I'd sort of have expected :
16777216 X 524288 X 16777216 X 524288 X 16777216 X 524288 X
The idea being that if you get a KEY_MOUSE, you get one (and only
one) event out of it; the next event comes with the next KEY_MOUSE.
2. Multiple-clicking with a long mouse interval (set here to 1 second)
does not work as I expect. Here is what I see if I:
Left-triple-click then left-single-click within the interval, then
Left-triple-click then left-double-click within the interval, then
Left-triple-click then left-triple-click within the interval.
For that scenario, I'd expected to get the events in order (a
triple-click '16' followed by a 4, then an 8, then a 16). That is to
say, the events would be queued. However, I get what you got (same
caveat that I'm using an old version). I'd at least have expected to
get the triple-click _first_ rather than second.
Ideally, after the third click, a triple-click would be returned
right away. There's no point in waiting for a fourth click; the
interface doesn't support quadruple-click events.
Changing 'while' to 'if' resulted in all of the above events (and
any number of clicks N > 3) returning a single click. If I hammered the
button like a Morse code key, the program waited patiently, and then
returned a single click a second after I finished.
Mouse handling in PDCursesMod has long been quite ugly. I recently
did a lot of fixing of it, which caused me to check how ncurses does
it. I'm surprised that I missed this bit (though I did test N-clicking
quite thoroughly for PDCursesMod).
It turns out that this business of taking a stream of 'raw' mouse
press/release events and 'cooking' them into clicks and double- and
triple-clicks is harder than it initially seems, as described in
comments here :
https://github.com/Bill-Gray/PDCursesMod/blob/master/common/mouse.c
It helps to stop when you've got an event and know that further
presses or releases are irrelevant. For example, if mousemask() was
set to only look for single- and double-clicks on a button, and you get
a double-click, you can add it to the queue and stop; you don't wait
around for a third click. (An extension of the above remark that once
you get a triple click, you're done.)
I owe you a small note of thanks here. Coincidentally, I'm working
on adding a functional ungetmouse() to PDCursesMod (it currently only
queues one event). This is a good way to test it out.
(On an irrelevant side note, something I was curious about when
looking at your example code : I notice that you're casting a _lot_ of
curses functions to (void), such as
(void)refresh();
but not all, and I don't see a pattern. What's the intention there?)
-- Bill
4 16 X 4 16 X 4 16 X
I expected either:
(a) the click count to "saturate" within the interval, and return
only BUTTON1_TRIPLE_CLICKED (16); or
(b) to receive one event of each kind, which only met my
expectations in the first case. So in that scenario I expected:
4 16 X 8 16 X 16 X
Can someone elucidate the model I should have in my head? It sounds
like I have the wrong one.
If it matters, I'm using stock ncurses v6_5_20250628 and XTerm(395) with
TERM=xterm-256color.
Regards,
Branden
