bug-ncurses
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Mouse button handling


From: Anders Juel Jensen
Subject: Re: Mouse button handling
Date: Tue, 13 Sep 2011 00:19:15 +0200

On Sat, Sep 10, 2001 at 18:39:01 -0400, Thomas Dickey wrote:
>On Thu, Sep 08, 2011 at 12:56:23AM +0200, Damien Guibouret wrote:
>> Hello,
>>
>> Here is the updated diff that adds the mouse event queue compaction
>> to what I already sent. In addition to that, getmouse checks if event
>> is in requested mask or not as there could be cases where KEY_MOUSE
>> is returned without the _nc_mouse_parse function being called (if
>> _nc_mouse_inline returns FALSE). If it is not in the mask it checks
>> previous event until getting a requested one or an invalid event (in
>> this last case it returns ERR).
>> I modified also the test/ncurses.c also to dump the whole queue when
>> a mouse key is detected.
>
>hmm - some of it is interesting.  But after applying the change, it's
>still not working properly for me.  So my patch tonight reverts the
>(relatively small) change from early 2010 which is the basic issue, and
>we can pick apart this patch.
>
>Generally what I saw: the display in test/ncurses in response to
>mouse-4
>(wheel-mouse-up) is clearing parts of the lines.  The "*" expected to
>show in response to mouse movement for TERM=xterm-1003 is not showing
>(most of the response lines are blank).  Reading through the changes,
>it seems that you might still be assuming that detail about 64 vs 96 is
>incorrect.  But I'm testing with xterm in the modes that the wheel
>mouse and any-event logic are designed for...
>
>However, the queue-draining aspect is related to the change I'm
>temporarily reverting.  So that's an area to explore.
>
>I think that if I can guide you toward setting up the same testcases,
>then the integration process will go smoother.  It would also help if
>the patch were refactored into several phases, each of which would make
>some specific improvement that could be tested.

I am very interested in this development, as my project is completely
shot down by the lack of accurate mouse events (especially movement).

Damien: 
if you need help testing your patches before you submit them,
just ship them my way and i will give them a go. Beware of line wrapping
when you inline patches, as the previous one you sent doesn't apply for
me, despite the best of my efforts to un-break it. Are you sure this is
against 5.9-patch0?

Thomas: 
To be sure I don't make a fool of myself when testing around
with this I need a bit of clarification, as the curs_mouse(3X) is a
little bit vague on exactly how REPORT_MOUSE_POSITION is supposed to
work.
Should it a) generate KEY_MOUSE under any/every circumstance when the
mouse has moved to another character cell, or b) only generate
KEY_MOUSE for movements while a button is pressed?
My own tests says a), but whenever i have had the luxury of actually
getting anything to report back it has been more of a fluke than
something reproducible.

Yours Sincerely
Anders Jensen



reply via email to

[Prev in Thread] Current Thread [Next in Thread]