|
From: James R. V. Z. <jr...@co...> - 2009-07-18 03:10:21
|
I've just checked in code to do "pan and zoom" with the mouse wheel.
These commands work like Acroread or Gimp:
- control-wheel-up zooms in toward the center of the plot
- control-wheel-down reverses the above
- wheel-up move the viewpoint up (increases both ymin and ymax by ten
percent of the plot range)
- wheel-down moves the viewpoint down
- shift-wheel-up moves the viewpoint left (decreases both xmin and xmax
by ten percent of the plot range)
- shift-wheel-down moves the viewpoint right
I implemented these just for completeness:
- shift-control-wheel-up zooms in only the X axis
- shift-control-wheel-down zooms out only the X axis
These work for linear or log axes.
A simple plot for testing, with or without log axes:
set parametric; plot sin(t)+1.02,cos(t)+1.02
(If zero is not currently on an axis, you can use "L" to toggle
logscale along that axis.)
I'll be glad to add documentation, but first I'll see what changes
people want. E.g.:
- Are the pan and zoom steps reasonable? Should they be user-tunable?
- Do you have a better idea for shift-control-wheel?
- Each of these commands is added to the zoom stack, so they can be
undone individually. That was easy to implement, but do we want that?
Does "u" recover all that memory? Should we suggest that the user
type "u" occasionally?
- Jim Van Zandt
|
|
From: Ethan M. <merritt@u.washington.edu> - 2009-07-18 04:40:46
|
On Friday 17 July 2009, James R. Van Zandt wrote: > > I've just checked in code to do "pan and zoom" with the mouse wheel. First thoughts: It works nicely here in x11, but doesn't do anything at all in wxt or in the new canvas or qt terminals. I understand that extra javascript would be needed for the canvas, but what is needed in order to support this for other interactive terminal types? Wouldn't it be logical to apply this in 3D also? It does not immediately strike me as useful to save the settings on the zoom stack. Unlike a click-and-drag zoom operation, the inverse is easy to achieve by reversing the direction of the mouse wheel. > These commands work like Acroread or Gimp: > > - control-wheel-up zooms in toward the center of the plot > - control-wheel-down reverses the above > > - wheel-up move the viewpoint up (increases both ymin and ymax by ten > percent of the plot range) > > - wheel-down moves the viewpoint down > > - shift-wheel-up moves the viewpoint left (decreases both xmin and xmax > by ten percent of the plot range) > > - shift-wheel-down moves the viewpoint right > > > I implemented these just for completeness: > > - shift-control-wheel-up zooms in only the X axis > - shift-control-wheel-down zooms out only the X axis > > > These work for linear or log axes. > > A simple plot for testing, with or without log axes: > > set parametric; plot sin(t)+1.02,cos(t)+1.02 > > (If zero is not currently on an axis, you can use "L" to toggle > logscale along that axis.) > > > I'll be glad to add documentation, but first I'll see what changes > people want. E.g.: > > - Are the pan and zoom steps reasonable? Should they be user-tunable? > - Do you have a better idea for shift-control-wheel? > - Each of these commands is added to the zoom stack, so they can be > undone individually. That was easy to implement, but do we want that? > Does "u" recover all that memory? Should we suggest that the user > type "u" occasionally? > > - Jim Van Zandt > > ------------------------------------------------------------------------------ > Enter the BlackBerry Developer Challenge > This is your chance to win up to $100,000 in prizes! For a limited time, > vendors submitting new applications to BlackBerry App World(TM) will have > the opportunity to enter the BlackBerry Developer Challenge. See full prize > details at: http://p.sf.net/sfu/Challenge > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > |
|
From: Ethan M. <merritt@u.washington.edu> - 2009-07-18 22:45:53
|
On Friday 17 July 2009, Ethan Merritt wrote: > On Friday 17 July 2009, James R. Van Zandt wrote: > > > > I've just checked in code to do "pan and zoom" with the mouse wheel. > > First thoughts: > > It works nicely here in x11, but doesn't do anything at all in wxt or > in the new canvas or qt terminals. I understand that extra javascript > would be needed for the canvas, but what is needed in order to support > this for other interactive terminal types? OK. I figured out how to add a wxt handler for mouse wheel events. I'll punt on qt and hope that Jérôme Lodewyck will take care of it. What about the windows terminal - can someone confirm whether that is recognizing pan and zoom using the same conventions as x11? Ethan > > Wouldn't it be logical to apply this in 3D also? > > It does not immediately strike me as useful to save the settings on the > zoom stack. Unlike a click-and-drag zoom operation, the inverse is easy > to achieve by reversing the direction of the mouse wheel. > > > > These commands work like Acroread or Gimp: > > > > - control-wheel-up zooms in toward the center of the plot > > - control-wheel-down reverses the above > > > > - wheel-up move the viewpoint up (increases both ymin and ymax by ten > > percent of the plot range) > > > > - wheel-down moves the viewpoint down > > > > - shift-wheel-up moves the viewpoint left (decreases both xmin and xmax > > by ten percent of the plot range) > > > > - shift-wheel-down moves the viewpoint right > > > > > > I implemented these just for completeness: > > > > - shift-control-wheel-up zooms in only the X axis > > - shift-control-wheel-down zooms out only the X axis > > > > > > These work for linear or log axes. > > > > A simple plot for testing, with or without log axes: > > > > set parametric; plot sin(t)+1.02,cos(t)+1.02 > > > > (If zero is not currently on an axis, you can use "L" to toggle > > logscale along that axis.) > > > > > > I'll be glad to add documentation, but first I'll see what changes > > people want. E.g.: > > > > - Are the pan and zoom steps reasonable? Should they be user-tunable? > > - Do you have a better idea for shift-control-wheel? > > - Each of these commands is added to the zoom stack, so they can be > > undone individually. That was easy to implement, but do we want that? > > Does "u" recover all that memory? Should we suggest that the user > > type "u" occasionally? > > > > - Jim Van Zandt > > > > ------------------------------------------------------------------------------ > > Enter the BlackBerry Developer Challenge > > This is your chance to win up to $100,000 in prizes! For a limited time, > > vendors submitting new applications to BlackBerry App World(TM) will have > > the opportunity to enter the BlackBerry Developer Challenge. See full prize > > details at: http://p.sf.net/sfu/Challenge > > _______________________________________________ > > gnuplot-beta mailing list > > gnu...@li... > > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > > > > |
|
From: Tatsuro M. <tma...@ya...> - 2009-07-19 22:50:08
|
Hello I have built wgnuplot with wxt on the cvs trees 2009-07-18 Ethan A Merritt <merritt@u.washington.edu> * src/wxterminal/wxt_gui.cpp src/wxterminal/wxt_gui.h: Pass through mouse wheel events from the wxt terminal, so that the new pan and zoom works for wxt as well as x11. I have confirmed that pan and zoom using work on wxt but does not work on windows terminal. Regards Tatsuro --- Ethan Merritt wrote: > On Friday 17 July 2009, Ethan Merritt wrote: > > On Friday 17 July 2009, James R. Van Zandt wrote: > > > > > > I've just checked in code to do "pan and zoom" with the mouse wheel. > > > > First thoughts: > > > > It works nicely here in x11, but doesn't do anything at all in wxt or > > in the new canvas or qt terminals. I understand that extra javascript > > would be needed for the canvas, but what is needed in order to support > > this for other interactive terminal types? > > OK. I figured out how to add a wxt handler for mouse wheel events. > > I'll punt on qt and hope that J将アr将ヤme Lodewyck will take care of it. > > What about the windows terminal - can someone confirm whether that > is recognizing pan and zoom using the same conventions as x11? > > Ethan > > > > > > > Wouldn't it be logical to apply this in 3D also? > > > > It does not immediately strike me as useful to save the settings on the > > zoom stack. Unlike a click-and-drag zoom operation, the inverse is easy > > to achieve by reversing the direction of the mouse wheel. > > > > > > > These commands work like Acroread or Gimp: > > > > > > - control-wheel-up zooms in toward the center of the plot > > > - control-wheel-down reverses the above > > > > > > - wheel-up move the viewpoint up (increases both ymin and ymax by ten > > > percent of the plot range) > > > > > > - wheel-down moves the viewpoint down > > > > > > - shift-wheel-up moves the viewpoint left (decreases both xmin and xmax > > > by ten percent of the plot range) > > > > > > - shift-wheel-down moves the viewpoint right > > > > > > > > > I implemented these just for completeness: > > > > > > - shift-control-wheel-up zooms in only the X axis > > > - shift-control-wheel-down zooms out only the X axis > > > > > > > > > These work for linear or log axes. > > > > > > A simple plot for testing, with or without log axes: > > > > > > set parametric; plot sin(t)+1.02,cos(t)+1.02 > > > > > > (If zero is not currently on an axis, you can use "L" to toggle > > > logscale along that axis.) > > > > > > > > > I'll be glad to add documentation, but first I'll see what changes > > > people want. E.g.: > > > > > > - Are the pan and zoom steps reasonable? Should they be user-tunable? > > > - Do you have a better idea for shift-control-wheel? > > > - Each of these commands is added to the zoom stack, so they can be > > > undone individually. That was easy to implement, but do we want that? > > > Does "u" recover all that memory? Should we suggest that the user > > > type "u" occasionally? > > > > > > - Jim Van Zandt > > > > > > ------------------------------------------------------------------------------ > > > Enter the BlackBerry Developer Challenge > > > This is your chance to win up to $100,000 in prizes! For a limited time, > > > vendors submitting new applications to BlackBerry App World(TM) will have > > > the opportunity to enter the BlackBerry Developer Challenge. See full prize > > > details at: http://p.sf.net/sfu/Challenge > > > _______________________________________________ > > > gnuplot-beta mailing list > > > gnu...@li... > > > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > > > > > > > > > > ------------------------------------------------------------------------------ > Enter the BlackBerry Developer Challenge > This is your chance to win up to $100,000 in prizes! For a limited time, > vendors submitting new applications to BlackBerry App World(TM) will have > the opportunity to enter the BlackBerry Developer Challenge. See full prize > details at: http://p.sf.net/sfu/Challenge > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > -------------------------------------- Power up the Internet with Yahoo! Toolbar. http://pr.mail.yahoo.co.jp/toolbar/ |
|
From: James R. V. Z. <jr...@co...> - 2009-07-21 10:29:04
|
> Tatsuro MATSUOKA <tma...@ya...> writes:
>
>> I have built wgnuplot with wxt on the cvs trees
>> 2009-07-18 Ethan A Merritt <merritt@u.washington.edu>
>>
>> * src/wxterminal/wxt_gui.cpp src/wxterminal/wxt_gui.h:
>> Pass through mouse wheel events from the wxt terminal, so that the new
>> pan and zoom works for wxt as well as x11.
>
> I have confirmed that pan and zoom using work on wxt but does not work on windows terminal.
Thanks for checking this out.
In the mean time I've found a simpler approach:
if (modifier_mask & Mod_Shift) {
/* scroll left */
xmin = AXIS_DE_LOG_VALUE(FIRST_X_AXIS,1.1*axis_array[FIRST_X_AXIS].min
-.1*axis_array[FIRST_X_AXIS].max);
ymin = AXIS_DE_LOG_VALUE(FIRST_Y_AXIS,axis_array[FIRST_Y_AXIS].min);
x2min = AXIS_DE_LOG_VALUE(SECOND_X_AXIS,1.1*axis_array[SECOND_X_AXIS].min
-.1*axis_array[SECOND_X_AXIS].max);
y2min = AXIS_DE_LOG_VALUE(SECOND_Y_AXIS,axis_array[SECOND_Y_AXIS].min);
xmax = AXIS_DE_LOG_VALUE(FIRST_X_AXIS,.1*axis_array[FIRST_X_AXIS].min
+.9*axis_array[FIRST_X_AXIS].max);
ymax = AXIS_DE_LOG_VALUE(FIRST_Y_AXIS,axis_array[FIRST_Y_AXIS].max);
x2max = AXIS_DE_LOG_VALUE(SECOND_X_AXIS,.1*axis_array[SECOND_X_AXIS].min
+.9*axis_array[SECOND_X_AXIS].max);
y2max = AXIS_DE_LOG_VALUE(SECOND_Y_AXIS,axis_array[SECOND_Y_AXIS].max);
do_zoom(xmin, ymin, x2min, y2min, xmax, ymax, x2max, y2max);
if (display_ipc_commands()) {
fprintf(stderr, "scroll left.\n");
}
}
Since this doesn't involve MousePosToGraphPosReal(), it works even for
splot. I don't know whether this change would affect the other terminals.
I haven't checked in this change because I found a bug: If I plot a
function defined only for certain values of Y, and set logscale Y, and
scroll past the defined region, then it breaks. E.g.
set logscale y;set xrange [0:5];set yrange [.01:10];
splot sqrt(1.02-(1- x)**2 - (1-y)**2)
I haven't diagnosed that problem yet.
- Jim Van Zandt
|
|
From: James R. V. Z. <jr...@co...> - 2009-07-24 02:13:11
|
On Tuesday I wrote:
>In the mean time I've found a simpler approach:
>
> if (modifier_mask & Mod_Shift) {
> /* scroll left */
> xmin = AXIS_DE_LOG_VALUE(FIRST_X_AXIS,1.1*axis_array[FIRST_X_AXIS].min
> -.1*axis_array[FIRST_X_AXIS].max);
> ymin = AXIS_DE_LOG_VALUE(FIRST_Y_AXIS,axis_array[FIRST_Y_AXIS].min);
> x2min = AXIS_DE_LOG_VALUE(SECOND_X_AXIS,1.1*axis_array[SECOND_X_AXIS].min
> -.1*axis_array[SECOND_X_AXIS].max);
> y2min = AXIS_DE_LOG_VALUE(SECOND_Y_AXIS,axis_array[SECOND_Y_AXIS].min);
>
> xmax = AXIS_DE_LOG_VALUE(FIRST_X_AXIS,.1*axis_array[FIRST_X_AXIS].min
> +.9*axis_array[FIRST_X_AXIS].max);
> ymax = AXIS_DE_LOG_VALUE(FIRST_Y_AXIS,axis_array[FIRST_Y_AXIS].max);
> x2max = AXIS_DE_LOG_VALUE(SECOND_X_AXIS,.1*axis_array[SECOND_X_AXIS].min
> +.9*axis_array[SECOND_X_AXIS].max);
> y2max = AXIS_DE_LOG_VALUE(SECOND_Y_AXIS,axis_array[SECOND_Y_AXIS].max);
> do_zoom(xmin, ymin, x2min, y2min, xmax, ymax, x2max, y2max);
> if (display_ipc_commands()) {
> fprintf(stderr, "scroll left.\n");
> }
> }
>
>Since this doesn't involve MousePosToGraphPosReal(), it works even for
>splot. I don't know whether this change would affect the other terminals.
>
>I haven't checked in this change because I found a bug: If I plot a
>function defined only for certain values of Y, and set logscale Y, and
>scroll past the defined region, then it breaks. E.g.
>
> set logscale y;set xrange [0:5];set yrange [.01:10];
> splot sqrt(1.02-(1- x)**2 - (1-y)**2)
>
>I haven't diagnosed that problem yet.
I have zoom and pan with the mouse wheel working for 3D as well as 2D plots.
I found the problem mentioned above in this section of plot3d.c:
axis_checked_extend_empty_range(FIRST_X_AXIS, "All points x value undefined");
axis_checked_extend_empty_range(FIRST_Y_AXIS, "All points y value undefined");
if (splot_map)
axis_checked_extend_empty_range(FIRST_Z_AXIS, NULL); /* Suppress warning message */
else
axis_checked_extend_empty_range(FIRST_Z_AXIS, "All points z value undefined");
axis_revert_and_unlog_range(FIRST_X_AXIS);
axis_revert_and_unlog_range(FIRST_Y_AXIS);
axis_revert_and_unlog_range(FIRST_Z_AXIS);
The test function in the splot command above is defined only for -.01
< y < 2.01. With logscale y, if I scroll up far enough that all the
defined points are outside the plot range, then I get the "All points
z value undefined" message and it abandons the plot. The problem was
that axis_array[FIRST_Y_AXIS].min and .max almost always hold
transformed values (logs of the minimum and maximum values to be
plotted). The exception is that when mouse commands adjust the scale,
the untransformed values are stored there. They are supposed to be
converted back to logs by the call to axis_revert_and_unlog_range()
shown above. If the conversion never happens, then scaling is messed
up - e.g. instead of yrange [.01:20] you would get [10**.01 : 10**20],
and just turning the mouse wheel the other direction cannot fix it.
I revised plot3d.c to fix the X and Y limits before checking for valid
Z values:
axis_checked_extend_empty_range(FIRST_X_AXIS, "All points x value undefined");
axis_revert_and_unlog_range(FIRST_X_AXIS);
axis_checked_extend_empty_range(FIRST_Y_AXIS, "All points y value undefined");
axis_revert_and_unlog_range(FIRST_Y_AXIS);
if (splot_map)
axis_checked_extend_empty_range(FIRST_Z_AXIS, NULL); /* Suppress warning message */
else
axis_checked_extend_empty_range(FIRST_Z_AXIS, "All points z value undefined");
axis_revert_and_unlog_range(FIRST_Z_AXIS);
It works here. However, I'd appreciate someone with a better
understanding of the code checking for side effects.
- Jim Van Zandt
|
|
From: Ethan M. <merritt@u.washington.edu> - 2009-07-24 18:59:50
|
On Thursday 23 July 2009 19:12:56 James R. Van Zandt wrote: > > I revised plot3d.c to fix the X and Y limits before checking for valid > Z values: > > axis_checked_extend_empty_range(FIRST_X_AXIS, "All points x value undefined"); > axis_revert_and_unlog_range(FIRST_X_AXIS); > axis_checked_extend_empty_range(FIRST_Y_AXIS, "All points y value undefined"); > axis_revert_and_unlog_range(FIRST_Y_AXIS); > if (splot_map) > axis_checked_extend_empty_range(FIRST_Z_AXIS, NULL); /* Suppress warning message */ > else > axis_checked_extend_empty_range(FIRST_Z_AXIS, "All points z value undefined"); > > axis_revert_and_unlog_range(FIRST_Z_AXIS); > > It works here. However, I'd appreciate someone with a better > understanding of the code checking for side effects. > > - Jim Van Zandt I don't know if it counts as a side-effect, but after setting set view equal xyz the 3D zoom behavior (control + mouse wheel) is unexpected. I would have expected the whole plot to get bigger or smaller; instead the x/y area remains fixed, the x and y scales change, and the z axis grows correspondingly longer or shorter. Note: since 'set view equal xyz' doesn't work in the x11 terminal anyhow, you would need to use the wxt or maybe qt terminal to see what I'm describing. Ethan Merritt |
|
From: James R. V. Z. <jr...@co...> - 2009-07-26 02:28:40
|
Ethan Merritt wrote:
>On Thursday 23 July 2009 19:12:56 James R. Van Zandt wrote:
>
>> I revised plot3d.c to fix the X and Y limits before checking for valid
>> Z values:
...
>>
>> It works here. However, I'd appreciate someone with a better
>> understanding of the code checking for side effects.
>
>I don't know if it counts as a side-effect, but after setting
>
> set view equal xyz
>
>the 3D zoom behavior (control + mouse wheel) is unexpected.
>I would have expected the whole plot to get bigger or smaller;
>instead the x/y area remains fixed, the x and y scales change,
>and the z axis grows correspondingly longer or shorter.
>
>Note: since 'set view equal xyz' doesn't work in the x11 terminal anyhow,
>you would need to use the wxt or maybe qt terminal to see what I'm describing.
I'm not familiar with "set view equal xyz", but it seems to do
*something* here, in the x11 terminal. E.g., provided I start with a
square window, these commands:
set parametric
set view equal xyz
set view 58,228
set hidden3d
set isosamples 30,30
set vrange [-pi:pi]
set urange [-2:2]
set xrange [-2:2]
set yrange [-1.5:1.5]
set ticslevel .2
splot cos(u)+.5*cos(u)*cos(v),.5*sin(v),sin(u)+.5*sin(u)*cos(v)
will plot with equal screen distance per axis distance for all three
axes. (With a rectangular window, the vertical scaling is off. Is
that the bug you're referring to? If so, then maybe it should be
mentioned in the docs?)
Assuming that's what it's supposed to do, then I believe the
control-wheel is handling the X and Y axes correctly. Perhaps it
should scale the Z the same way (i.e. the figure grows, but parts
outside the plot range don't get drawn). However, I wasn't able to
implement Z scaling. I did include some code that used alt-wheel to
scroll up in Z. However, it's commented out* because do_zoom() and
apply_zoom() don't implement anything for Z, and I didn't understand
the logic well enough to modify them. (Feel free to delete that part
if you think it clutters the code.)
At least, control-wheel does maintain the relative scaling.
- Jim Van Zandt
* actually it's conditional on DO_ZOOM_AND_APPLY_ZOOM_FIXED_TO_HANDLE_Z_AXIS.
|
|
From: James R. V. Z. <jr...@co...> - 2009-07-19 02:57:47
|
Ethan Merritt <merritt@u.washington.edu> writes:
>On Friday 17 July 2009, James R. Van Zandt wrote:
>>
>> I've just checked in code to do "pan and zoom" with the mouse wheel.
>
>It works nicely here in x11, but doesn't do anything at all in wxt or
>in the new canvas or qt terminals. I understand that extra javascript
>would be needed for the canvas, but what is needed in order to support
>this for other interactive terminal types?
I only tested the x11 terminal, but I'm actually disappointed that
changes to the core code don't affect all the mouse-capable terminals.
It suggests there's something wrong with the way the code is factored.
However, I have no idea how the other terminals handle the mouse.
Does it work with the Windows terminal?
>Wouldn't it be logical to apply this in 3D also?
Good idea.
>It does not immediately strike me as useful to save the settings on the
>zoom stack. Unlike a click-and-drag zoom operation, the inverse is easy
>to achieve by reversing the direction of the mouse wheel.
True. As I wrote, it was easiest to implement it that way.
Separating the zooming and stacking functions looked messy (I wasn't
sure I followed all the logic) and I didn't convince myself that it
was worth the trouble.
- Jim
|
|
From: Ethan M. <merritt@u.washington.edu> - 2009-07-19 04:45:14
|
On Saturday 18 July 2009, James R. Van Zandt wrote: > Ethan Merritt <merritt@u.washington.edu> writes: > >It works nicely here in x11, but doesn't do anything at all in wxt or > >in the new canvas or qt terminals. I understand that extra javascript > >would be needed for the canvas, but what is needed in order to support > >this for other interactive terminal types? > > I only tested the x11 terminal, but I'm actually disappointed that > changes to the core code don't affect all the mouse-capable terminals. The core code works fine, but it is only called if there is an event handler registered for the mouse wheel events inside the plot window used by the current terminal. X11 has one. I can see in the code that there is one also for windows, though I can't confirm that it works. I have just added one for wxt. |