From: phil r. <phi...@ya...> - 2012-08-31 11:35:57
|
When you talk about zooming, are you referring to zooming in on a page - simply scaling everything up and showing only a portion of it or are you talking about changing the axes of a plot based on mouse clicks and keyboard input? I'd be interested in helping with the wxWidgets driver. Phil Message: 3 Date: Thu, 30 Aug 2012 09:28:49 -0700 (PDT) From: "Alan W. Irwin" <ir...@be...> Subject: [Plplot-devel] Interactive capabilities of PLplot To: Jerry <lan...@qw...>, PLplot development list <Plp...@li...> Message-ID: <alpine.DEB.2.00.1208300918420.2263@ybpnyubfg.ybpnyqbznva> Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII On 2012-08-30 02:26-0700 Jerry wrote: > Does the Tk interactive method allow the user to use a mouse to interactively select a rectangular portion of the plot for zooming? This would certainly be useful and then I would have an actual personal interest in this work. Do any of the interactive devices allow this? X, Aquaterm and Qt do not--those are the only ones that I have tried. This question introduces a new topic, so I am using a different subject for it. The xwin, tk, xcairo, and qtwidget devices all allow mouse and keyboard interaction. Try example 1 in C with the --locate option to demonstrate this for yourself. With each mouse button or keyboard character hit, the position and which mouse button/key was hit is returned (with the exception of qtwidget where the key/mouse identification is still missing.) The mouse button/key identification and position is all that is required from our devices to allow higher-level interactive capability such as zooming. Note that high-level interactive use has to be programmed at the application level. For example, I used an interactive plotting system in the early 80's built off of plotting device drivers for plotting software available at that time which had the fundamental interactive capability we have in at least 3 of our interactive devices above. That system had a help mode (initiated by hitting the "?" key) that gave a list of some 20 different interactive modes you could start by hitting a particular key). This system was designed to help analyze astronomical absorption spectra (flux as a function of position in the direction of dispersion in the spectrograph) so there were modes to help find line positions, modes to help determine the continuum between lines, take equivalent widths of lines, calibrate the dispersion relation (wavelength as a function of position), zoom in x position (or wavelength), zoom in y position (flux), zoom in both coordinates, etc. At some point, I plan to write an application that reimplements this useful interactive system based on the currently existing fundamental PLplotinteractive device capabilities. Note, some higher-level interactive capability (zooming) has already been implemented for our tk device, but that would potentially interfere with implementation of higher level interactivity in applications like I have just described. So I definitely don't want to see, e.g., zooming capability implemented for all our interactive devices. On the other hand, I do want to see the fundamental interactive capability available for all our interactive devices so we do need a volunteer to add mouse button/key identification for -dev qtwidtet. I think we should also promote the fundamental interactive capabilities of our interactive devices a lot more since few (or none?) of our users seem to be aware of those. So I suggest a volunteer who has time/interest here modify example 1 to do just that. For example, it should be possible to implement zooming for that particular example by e.g., looking for the z key being hit (to initiate zooming), and then look at the position of the next two key strokes after that to identify the zooming box, then plot that zoomed area. And keep in zoom mode thereafter, until, say, the e key is hit to exit zooming mode. Making sure that capability worked for all our languages would probably be challenging (since we have never tried that before), but I think it would be well worth doing since we cannot anticipate what language someone will want to use to implement an interactive plotting application. That new capability for example 1 along with a DocBook section and some release notes advertising that new capability would be a good way to promote the current fundamental interactive capabilities of our interactive devices so that users would start using those in interactive applications they have developed for themselves. 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2012-08-31 15:14:12
|
Hi Phil: On 2012-08-31 04:35-0700 phil rosenberg wrote: > When you talk about zooming, are you referring to zooming in on a page - simply scaling everything up and showing only a portion of it Yes. > or are you talking about changing the axes of a plot based on mouse clicks and keyboard input? That could be done as well. > > I'd be interested in helping with the wxWidgets driver. > That would be much appreciated. In fact, when I tried (after running "make x01c" and "make wxwidgets") examples/c/x01c -dev wxwidgets -locate -drvopt backend=0 examples/c/x01c -dev wxwidgets -locate -drvopt backend=1 examples/c/x01c -dev wxwidgets -locate -drvopt backend=2 that device it turns out that the fundamental interactivity features are available (although the agg backend does not identify the key strokes for some reason, and the other backends that identify the keystrokes fail to identify which mouse button was pushed). Of course, this result is on Linux with X serving as the fundamental graphical software library supporting wxwidgets, and I am not sure whether you will get the same result on the Windows version of wxwidgets. If you can get it to mostly work like I described, it would be a help if you refined it so all three backends produced good identification results including mouse button identification and distinguishing between press and release (see below). If you ever install GTK+, then using the xcairo device on the above example produces (at least on Linux) the ideal result; _every_ keystroke and mouse button is identified both on press and release. That latter feature is important since it allows the CLI to identify drag and release events with any key where the user holds down the key and only releases it when the cursor has been moved to a new position. Other interactive devices on Linux are not that good with no release identification (all of them other than xcairo), missing identifications altogether (qtwidget), missing mouse button identifications (xwin), etc. So there is some work to do to bring them all up to the level of xcairo, and your help with the part of that work needed for wxwidgets would be much appreciated if Windows already gives you access to the partial interactivity that shows up on Linux for the 3 different versions of that device. 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 __________________________ |
From: phil r. <phi...@ya...> - 2012-08-31 15:55:55
|
I find similar results to you on windows, however there seems to be something that is making things unstable and after a few clicks or button presses the cursor lines disapear and then the program quits. Not really sure what's going on. Phil ________________________________ From: Alan W. Irwin <ir...@be...> To: phil rosenberg <phi...@ya...> Cc: "plp...@li..." <plp...@li...> Sent: Friday, 31 August 2012, 16:14 Subject: Re: [Plplot-devel] Plplot-devel Digest, Vol 75, Issue 15 Hi Phil: On 2012-08-31 04:35-0700 phil rosenberg wrote: > When you talk about zooming, are you referring to zooming in on a page - simply scaling everything up and showing only a portion of it Yes. > or are you talking about changing the axes of a plot based on mouse clicks and keyboard input? That could be done as well. > > I'd be interested in helping with the wxWidgets driver. > That would be much appreciated. In fact, when I tried (after running "make x01c" and "make wxwidgets") examples/c/x01c -dev wxwidgets -locate -drvopt backend=0 examples/c/x01c -dev wxwidgets -locate -drvopt backend=1 examples/c/x01c -dev wxwidgets -locate -drvopt backend=2 that device it turns out that the fundamental interactivity features are available (although the agg backend does not identify the key strokes for some reason, and the other backends that identify the keystrokes fail to identify which mouse button was pushed). Of course, this result is on Linux with X serving as the fundamental graphical software library supporting wxwidgets, and I am not sure whether you will get the same result on the Windows version of wxwidgets. If you can get it to mostly work like I described, it would be a help if you refined it so all three backends produced good identification results including mouse button identification and distinguishing between press and release (see below). If you ever install GTK+, then using the xcairo device on the above example produces (at least on Linux) the ideal result; _every_ keystroke and mouse button is identified both on press and release. That latter feature is important since it allows the CLI to identify drag and release events with any key where the user holds down the key and only releases it when the cursor has been moved to a new position. Other interactive devices on Linux are not that good with no release identification (all of them other than xcairo), missing identifications altogether (qtwidget), missing mouse button identifications (xwin), etc. So there is some work to do to bring them all up to the level of xcairo, and your help with the part of that work needed for wxwidgets would be much appreciated if Windows already gives you access to the partial interactivity that shows up on Linux for the 3 different versions of that device. 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2012-08-31 17:47:17
|
Hi Phil: On 2012-08-31 08:55-0700 phil rosenberg wrote: > I find similar (x01c with -locate option) results to you on windows. That's a good start. > However there seems to be something that is making things unstable and after a few clicks or button presses the cursor lines disapear and then the program quits. Not really sure what's going on. I have forgotten the implementation details which you will have to dig through the code to find, but the Linux result is that you permanently exit crosshairs mode in example 1 by clicking on a region away from the 4 plot viewports on that page. Is that what was happening for you by accident? Of course, after you exit crosshairs mode by such a click, then you can also exit the plot in a number of different ways which are device dependent. I find, for example, that on Linux you can exit the -dev wxwidgets plot by a single right mouse click. Could you be doing that by accident? 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 __________________________ |
From: phil r. <phi...@ya...> - 2012-08-31 20:18:13
|
I think, yes that might have been what was happening. I've just tried it again with random key pressing and even heading your warnings it isn't entirely stable, however I do get key presses recognised on all three backends. Anyway there is plenty of potential to add zoom type features to the wxWidgets backend. Phil ________________________________ From: Alan W. Irwin <ir...@be...> To: phil rosenberg <phi...@ya...> Cc: "plp...@li..." <plp...@li...> Sent: Friday, 31 August 2012, 18:47 Subject: Re: [Plplot-devel] Plplot-devel Digest, Vol 75, Issue 15 Hi Phil: On 2012-08-31 08:55-0700 phil rosenberg wrote: > I find similar (x01c with -locate option) results to you on windows. That's a good start. > However there seems to be something that is making things unstable and after a few clicks or button presses the cursor lines disapear and then the program quits. Not really sure what's going on. I have forgotten the implementation details which you will have to dig through the code to find, but the Linux result is that you permanently exit crosshairs mode in example 1 by clicking on a region away from the 4 plot viewports on that page. Is that what was happening for you by accident? Of course, after you exit crosshairs mode by such a click, then you can also exit the plot in a number of different ways which are device dependent. I find, for example, that on Linux you can exit the -dev wxwidgets plot by a single right mouse click. Could you be doing that by accident? 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 __________________________ |
From: Jerry <lan...@qw...> - 2012-08-31 23:13:49
|
On Aug 31, 2012, at 8:55 AM, phil rosenberg wrote: > I find similar results to you on windows, however there seems to be something that is making things unstable and after a few clicks or button presses the cursor lines disapear and then the program quits. Not really sure what's going on. > > Phil [Sorry--just read Alan's post about clicking outside the plot areas. Jerry] [Sorry for the double post, Alan. Maybe I need a CLI mailer. 8^)] I found on OS X that on xwin, qtwidget, and xcairo (all that I can currently test), playing with example 1, (x01c) that if I click outside the plotting area of the plots, for example, in the area between the four plots, that the cursor disappears and interactivity stops. I have seen at least xwin also quit at that point but not always. It might depend on exactly where I click. qtwidget and xcairo report their textual results twice--two identical lines of text. qtwidget also behaves differently depending on the presence of -locate. If no -locate, the widget app launches and draws its contents immediately while also making itself the front (or active) application. This I believe is desirable because one normally expects to see a plot once the controlling program makes it. However, with -locate, the Qt widget runs and presents a blank (black) window which is not the front application. Upon clicking on this window, it comes to the front and the plots are drawn. Jerry > > From: Alan W. Irwin <ir...@be...> > To: phil rosenberg <phi...@ya...> > Cc: "plp...@li..." <plp...@li...> > Sent: Friday, 31 August 2012, 16:14 > Subject: Re: [Plplot-devel] Plplot-devel Digest, Vol 75, Issue 15 > > Hi Phil: > > On 2012-08-31 04:35-0700 phil rosenberg wrote: > >> When you talk about zooming, are you referring to zooming in on a page - simply scaling everything up and showing only a portion of it > > Yes. > >> or are you talking about changing the axes of a plot based on mouse clicks and keyboard input? > > That could be done as well. > >> >> I'd be interested in helping with the wxWidgets driver. >> > > That would be much appreciated. > > In fact, > when I tried (after running "make x01c" and "make wxwidgets") > > examples/c/x01c -dev wxwidgets -locate -drvopt backend=0 > examples/c/x01c -dev wxwidgets -locate -drvopt backend=1 > examples/c/x01c -dev wxwidgets -locate -drvopt backend=2 > > that device it turns out that the fundamental interactivity features > are available (although the agg backend does not identify the key > strokes for some reason, and the other backends that identify the > keystrokes fail to identify which mouse button was pushed). Of course, > this result is on Linux with X serving as the fundamental graphical > software library supporting wxwidgets, and I am not sure whether you > will get the same result on the Windows version of wxwidgets. If you > can get it to mostly work like I described, it would be a help if you > refined it so all three backends produced good identification results > including mouse button identification and distinguishing between press > and release (see below). > > If you ever install GTK+, then using the xcairo device on the above > example produces (at least on Linux) the ideal result; _every_ > keystroke and mouse button is identified both on press and release. > That latter feature is important since it allows the CLI to identify > drag and release events with any key where the user holds down the key > and only releases it when the cursor has been moved to a new position. > > Other interactive devices on Linux are not that good with no release > identification (all of them other than xcairo), missing > identifications altogether (qtwidget), missing mouse button > identifications (xwin), etc. So there is some work to do to bring them > all up to the level of xcairo, and your help with the part of that > work needed for wxwidgets would be much appreciated if Windows already > gives you access to the partial interactivity that shows up on Linux > for the 3 different versions of that device. > > 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 > __________________________ > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Jerry <lan...@qw...> - 2012-08-31 23:07:13
|
On Aug 31, 2012, at 8:14 AM, Alan W. Irwin wrote: > Hi Phil: > > On 2012-08-31 04:35-0700 phil rosenberg wrote: > >> When you talk about zooming, are you referring to zooming in on a page - simply scaling everything up and showing only a portion of it > > Yes. > >> or are you talking about changing the axes of a plot based on mouse clicks and keyboard input? > > That could be done as well. > I would reverse the sort of implied preference that Alan states here, if I understand correctly. I would say the primary zoom style would be to redraw the plot with new (zoomed) axes. If the zooming only enlarges everything in the window, it will normally cause the axes to disappear off-screen--not good. Also, an Undo stack should be kept so that one can back up one zoom operation at a time (without loosing numerical precision in the event that an extreme zoom has been reached). And a "home" feature to return to the originally (un)scaled view. This is probably stating the obvious but I have seen a surprising number of plotters where one is simply left to get "home" by manually entering the inverse of accumulated zoom factors or manually entering the axis limits. Jerry |
From: Maurice L. <mj...@br...> - 2012-09-01 02:41:10
|
On Friday, August 31, 2012 at 16:07:06 (-0700) Jerry writes: > I would reverse the sort of implied preference that Alan states here, if I > understand correctly. I would say the primary zoom style would be to redraw > the plot with new (zoomed) axes. If the zooming only enlarges everything in > the window, it will normally cause the axes to disappear off-screen--not > good. Yes, ideally for applications where axes are important, they would be redrawn and overlaid on the new section of space after the zoom. This critique was raised by Geoffrey from the other side of my office even before the existing zoom feature was functional back in 1993. ;) The existing zoom uses the plot buffer to redraw so acts as a simple magnifier. It works reasonably well down to scales where the 2^16 device coordinate resolution becomes an issue. Stuff that you want to be redrawn rather than simply magnified as one zooms could be done as overlays that get triggered after the initial redraw. So axes, rulers, ...? Such support does not exist in plplot today. Would be cool but a fair amount of work. Maybe good to focus on getting simple zoom working for multiple interactive drivers first. > Also, an Undo stack should be kept so that one can back up one zoom > operation at a time (without loosing numerical precision in the event that > an extreme zoom has been reached). And a "home" feature to return to the > originally (un)scaled view. This is probably stating the obvious but I have > seen a surprising number of plotters where one is simply left to get "home" > by manually entering the inverse of accumulated zoom factors or manually > entering the axis limits. See bindings/tk/help_keys.tcl for keystroke zoom support in plframe. Note, I haven't tried any of this lately. :( ... When a plframe widget has the input focus, keyboard input is relayed to its remote TK driver. The default actions of the keyboard handler are as follows: "Q" | <Ctrl-x> Terminate program <Return> or <Page Down> Advance to the next page "m" Toogle top menus "z" enter zoom (Cliking once zooms x 2) "b" back zoom "f" forward zoom "r" reset zoom "P" print "s" save again "5" scroll magnification factor ?? "1" scroll speed ?? <left><right><up><down> scroll after zoom <Alt><key> increase scroll speed -- Maurice LeBrun |