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 __________________________ ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
