Re: [Plplot-devel] Correct implementation of key and button events in the interactive drivers

[Alan W. I. <ir...@be...>]

On 2016-01-12 08:18-0000 Phil Rosenberg wrote:

> Hi Alan and all
> To answer Alan's specific question near the end, on Windows (I don't
> have a Cygwin build handy) with wxWidgets a right click is button3,
> not button 2 as I may have said in my first reply.
>
> Alan, more generally:
> It seems very clear that you have a well defined idea about exactly
> what should happen with the locate mode and what should be filled in
> where.

Actually I am no expert at this, but I have used an empirical approach
with -locate mode for example 01 and cut and pasted what xwin delivers
versus the rest in my report.  So you will want to review those xwin
results to see what the other devices should aspire to.  I emphasize
xwin here because that is the only device that seems to have proper
interactivity.  Probably what that really means is the interactive
parts of example 01 and 20 were implemented a long time ago to work
with exactly what xwin (and I assume -dev tk since that uses xwin
capabilities quite a bit, although I did not bother to check) could
deliver.  Because xwin and tk were the only interactive devices that
existed at that time.  But what they delivered was quite a rich
interactive capability.  (Note I am considering some of the really
nice-looking interactive results that are delivered by the xwin device
for octave as well as the interactive parts of example 01 and 20 when
I am claiming that xwin has a rich interactive capability.) So our
initial goal should be to make sure our other interactive devices
deliver the same events (and not a whole bunch more as in the xcairo
case) with the same fields filled in as in the xwin case and also
implement xor mode properly to gain that rich interactive capability
for themselves.

Also, it is important that you look at the interactive code in
those two examples to see what is going on.  For example,
in example 20 there is some specific logic in get_clip
that depends on exact details delivered via plGetCursor( &gin );
by the device.  I am referring to the code fragments

gin.state & 0x100

gin.button == 3

etc.  (By the way, that 0x100 numerical constant should obviously be
replaced by PL_MASK_BUTTON1 in that example.  Do you want to do the
honors there?)

The important point here is that if your device driver is not filling
in those parts of PLGraphicsIn gin the way xwin does, then you are
hosed.  Also notice that from reading that logic you are hosed if
there is no xor mode implemented for your device (qtwidgets) or it is
not thoroughly debugged (apparently the case for xcairo and wxwidgets
from the lack of any sort of response to the -xor mode of example 1).

> I think it would be very good to condense this into a single
> description, either in the documentation or just in an email to this
> list so that all the device developers know what they should be
> working to.

The above is just a minimal start that is the current extent of my
knowledge.  I do agree a lot more expertise is needed as people look
carefully at what xwin delivers and how that is used in the
interactive parts of examples 1 and 20 that do not yet work for any
other device.

Also, I think it is important to avoid considering large interactive
design questions at the moment.  Instead, we have a working and quite
rich interactive model with xwin, and we should think of ourselves as
in emergency fixup mode to get our "interactive" devices to deliver
what xwin does. After that goal is reached, then we can think of
larger design questions about enhancing that already rich interactive
experience for all interactive devices.

Also note that with time and interest someone should be able to follow
the xwin code to see how it produces the cut and pasted results that I
posted.  That device waits for events and interprets them with X calls
which are straightforward to figure out by consulting man pages on a
Linux system and also available over the net.  I am not advocating
that you personally do that analysis yourself (although it is a "would
be nice"), but that possibility for deeper analysis exists if we
really need to understand why xwin is deliverying specific data for a
certain well-chosen subset of events and ignoring the rest.

A similar analysis is definitely required for each of our other
interactive devices by their maintainers but obviously in each case
you need to interpret "interactive" calls for just the relevant
library (e.g., the wxwidgets library for the wxwidgets device case) to
figure out how to mask certain events (the same ones ignored by xwin)
and how to determine the same data for the needed events that is
determined by xwin. So a fairly good knowledge of the library involved
(such as you already have for the wxwidgets library) should be a big
help to quickly figure out how to get an interactive device to act the
same way (i.e., fill in all the PLGraphicsIn struct fields dumped out
in example 1 for -locate mode and implement xor mode) as
the xwin device.

> Some things that aren't entirely clear to me from your reply, or even
> if they are there it would be good to summarise them in one place:
>
> 1) Should we report mouse movements (i.e. hovers), I think probably
> that would be good?
> 2) How do we distinguish a key press and a key release?
> 3) How do we distinguish mouse drags from mouse movements with no
> buttons pressed?
> 4)Should we report keyboard key release
> 5) Do we need to (or can we) do anything about repeat keyboard keys
> when keys are pressed and held?
> 6) We need a really good definition of what string, state and button
> should contain for each event, especially for "special" keys (shift,
> ctrl, etc) and special keys combined with each other, regular
> characters or mouse clicks.
> 7) I only have access to a UK keyboard on a UK English windows
> install. What (if anything) should we do about international
> keyboards?
> 8) What about clashes with page advance keyboard shortcuts?

In the spirit of my preliminary remarks above, here are my quick
answers to the questions above.

1 to 4.  This is empirical again, but if you ever run the xev
application under X you will realize it reports many more events (such
as mouse movement with no button pressed) then are reported by xwin.
So I am virtually positive that xwin sets a mask to ignore certain
kinds of events such as moving mouse without key or button pressed
(hovers).  I agree we should document what it ignores, but the start
of that is what I cut and pasted before for the xwin device (for those
who could not run it themselves) and that empirical result may be all
we need.  However, if that is not sufficient diving into the xwin code
to figure out the X-related event loop there in detail so as to copy
that same overall event loop model for a higher level library such as
wxwidgets is always an option.

5. No.

6. Play with -locate mode of example 01 to find that out.  xwin masks
out lots of this stuff which xcairo does not (yet).  wxwidgets
currently masks out too much; for example, it currently ignores key
events completely.

7. Internationalization of keyboards is too big to consider now.
Instead, I think we should focus on the case of a keyboard with
(possibly modified) ascii characters.

8. We should mask out anything we don't like to respond to such as
special keys.  After all, the only reason we want to handle key events
is to provide a simple mechanism (e.g. q for quit, m for menu, etc.,)
for the user to communicate with an interactive application that is
waiting for certain letters to be struck to take certain actions.  So
we likely just want to do something for regular ordinary letters but
probably with shift, ctrl, and alt imposed on top of them as modifying
keys. But again, we should probably look first at how xwin has masked
off keys it wants to ignore.  My preliminary experience is xwin
probably does not mask off sufficient keys (for example, it reacts in
a peculiar way with -locate mode for example 01 if you hit the enter
key).  But we can start with what xwin masks off now and then take it
from there.

Of course, your overall point is an excellent one that we should
concisely document what a PLplot interactive device should deliver. So
once someone gains better knowledge of that with making the changes to
just one additional device so that it delivers the same rich
interactive experience as xwin, they should follow up by putting
together such documentation to make life much easier for other
interactive device developers who will need to update their
device the same way.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________