On 2010-03-22 10:58-0400 Hazen Babcock wrote: > On my linux box the xcairo device does not respond to mouse clicks, only > key presses. > > I thought I would look up how the devices are supposed to respond, but > it looks like plGetCursor() is undocumented. I'd be happy to fill in the > documentation and implement for the Qt devices, but, any thoughts on > what the "correct" behavior should be? I think we have the following > possibilities for when this function should return: > > (1) After any key press or mouse event including movement. > (2) Key press and mouse button events (release events only?). > (3) Mouse button event only. > (4) Key press only. > (5) Other permutations of the above.
This is an important topic which I am glad you have brought up again. As far as getting proper documentation started, there is a whole lot of commentary in the xwin.c code concerning cursor(s), crosshairs, etc., which should give a good start to that effort. With regard to your question, I would like (2) for release events only with identification of the actual key or mouse button that has been pressed. There was extremely useful astronomical interactive plotting software I used in the early 80's that did roughly 30 different things depending on the key/mousebutton that was pressed, and I am sure that tradition of using all the keys/mouse buttons continues for interactive plotting packages not only in astronomy but lots of other sciences as well. If I press the 'l' key for -dev xwin in -locate mode for example 1, here is the response I get: subwin = 0, wx = 2.936888, wy = 14.595193, dx = 0.262060, dy = 0.718261, c = 'l' Pressing various keypad and F buttons produce hexadecimal results rather than an ascii letter. So clearly at least with -dev xwin we already have the API available to make the identification of the key that was pressed available to any application that is linked to the PLplot library. (The above output has been implemented in x01c.c,) However, there are some current limitations of our locate mode key/mousebutton identification for -dev xwin which should be addressed (in the xwin driver and every other interactive driver). * Our locate mode simply delivers ' ' for the key identification when any mouse button is pressed. This issue needs addressing since it is obviously important to distinguish the mouse buttons from each other and from the space bar. Following xev, I suggest the strings that should be returned are 'button 1', 'button 2', 'button 3' (and so forth for multibutton mice). * Some keys return hexadecimal identifiers. For example 'F1' and 'Enter' return '0xffbe' and '0x0d' under locate mode. Those hexadecimal identifiers should be replaced by symbolic identifiers following exactly the keysym symbolic (not hexadecimal) identifiers returned by xev. For example, those xev symbolic identifiers are'F1' and 'Return' for the F1 and Enter keys. This idea follows what I suggested for the mouse button identification above. I don't know what X lookups xev uses to get that symbolic identification information, but whatever that code does, we should just copy it (which is permissible under the xev MIT copyright license). * Our locate mode currently ignores the ctrl and alt modifier keys. That issue is worth addressing since some interactive plotting app of future will undoubtedly need those and there may well be an interactive plotting app that needs them now. To summarize all these key/mouse button identification issues, we probably want to deliver the exact same keysym symbolic (i.e., not hexadecimal) identification information as xev currently does for its key release events. That should be straightforward to implement since the xev source code is available under the permissive MIT license. 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); PLplot scientific plotting software package (plplot.org); 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 __________________________ ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Plplot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/plplot-devel
