[XForms] Xforms: incorrect reporting of mouse (XEvent) status to post-handler

[Ivan Powis]

I have an old application which uses the post-handler to add greater
interaction (rubber banded selections, zoom etc) to xy_plots. It
used to work (with an occasional hiccup) but the problem has now got so
bad as to make it unusable.

Apparent problem: Inconsistent data is passed to the post handler by forms.
In particular it seems to lose track of the "key" state. Immediately after a
mouse button is depressed (generating an FL_PUSH) an immediate release
(FL_RELEASE, key=0) is frequently getting reported back to the post handler,
even though the button is still physically down, and is reported as such by
fl_mouse_button(). Additionally examining the XEvent structure passed to the
post handler as "xev" by using fl_xevent_name_print()
reports the event as 12: Expose.

[OK I know that the manual implies that the void *xev might not always be a
valid XEvent pointer, but my experience in trying to debug this problem
suggests that everywhere else in the posthandler section its more often
right than not!]

Once this spurious button release has been reported the forms lib obviously
decides to remember the erroneous information that the mouse button is up!
So it will not then report a genuine release as FL_RELEASE, and if the mouse
is
dragged with a button physically still down, forms reports FL_MOTION rather
than FL_MOUSE to the posthandler - this rather breaks my rubber-banding
code. Again interrogating xev for the raw XEvent codes shows that
xev->xmotion.state correctly identifies the physically depressed mouse
button.

I may note that the problem appears the same in v.89 and v1 of the forms
library, and isn't confined to a particular version of Linux and/or gcc.
For example on Mandrake linux 8.2 (kernel 4.2, XFree 4.2.0, KDE 2.2.2) on
the console xserver the app becomes unusable. But connect to this same
system a remote pc running Exceed xserver and there is no problem using
either the full KDE session or a single X-window opened on the Windows
desktop.
Likewise on a Redhat (kernel 2.4.20, XFree 4.3.0 KDE 3.1) the app is
unusable at the console, but OK if viewed via a remote pc Xserver - in this
case just an occasional glitch crops up, but basic functinality is not
compromised).
I think we saw some similar minor glitches on older HP/UX systems.

Actually the degradation in performance at the linux consoles seems to
correlate with the use of a heavyweight window manager like KDE or GNOME,
but isn't confined to any particular WM.

It seems then as though the forms library, rather than tracking the mouse
button state via the XEvents it receives, tries to maintain its own internal
record, which more often than not gets out of sync with the physical state
and the reported status via xev. This then seems far far worse with a
heavyweight local WM. I don't quite understand the significance of this, nor
the inner workings of X. Anyone got any ideas, or suggestions where in the
source to browse and what to look for?

One possible work round here is to base decision making in the post handler
on an examination of the raw XEvent *xev structure rather than whatever
forms lib reports, but I'm concerned that the library doesn't seem to
guarantee passing xev valid.

Ivan
 --------------------------------------------------------------------
    ___  ___/   _  __ /   Ivan Powis   [Ivan.Powis at Nottingham.ac.uk]
        /         /   /   School of Chemistry
       /         /  _/    University of Nottingham
      /         ___/      Nottingham NG7 2RD, UK
     /         /     TEL: +44-115-951-3467
    /         /      FAX: +44-115-951-3562
_______/  ____/      http://www.chem.nott.ac.uk/IP.html
--------------------------------------------------------------------