Menu
▾
▴
gnuplot-beta
|
From: Ben A. <bpa...@ma...> - 2009-02-12 18:37:29
|
On Thursday, February 12, 2009, at 11:46AM, "Ethan A Merritt" <merritt@u.washington.edu> wrote: >On Thursday 12 February 2009, Ben Abbott wrote: > >> To properly interpret the "size" information I'll get from x11 using >> the GPVAL_TERM_WINDOWID, I'll need the value for GPVAL_TERM_VCHAR. >> Temporarily I can assume it is 13 pixels. However, as I'll be using >> the window size obtained from x11 to determine if the mouse was used >> to change its size, and subsequently update the figures' size property >> on the octave end, I'd like to make sure I get his correct. > >Use it for what? The window size reported by x11 includes the portion reporting the mouse coordinates, which is not part of the gnuplot canvas. So I'd like to have TERM_VCHAR so that I can subtract this from the window's height. >TERM_VCHAR is telling you about the font size, not the window size. >And in the case of the x11 terminal, it is only a rough approximation. > >The current code happens to use vchar and hchar also to estimate >the aspect ratio of the window, but this works very poorly. Because >of this, the aspect ratio code is still broken in x11 and I think >will not be fixable unless/until we totally revise how the x11 terminal >coordinates are handled. This will need a careful overhaul of the >terminalcode, but I don't see any intrinsic difficulties to overcome. >The idea is that the x11 terminal coordinate space should be defined >in terms of the actual dimensions of the display window; resizing the >window would change term->xmax and term->ymax but leave the x and y >scales unchanged. Currently the opposite is true; xmax and ymax >are held constant, while the x and y scale are changed so that the current >window area is spanned by a coordinate space running from [0:4095] on >both x and y. I don't know whether such a revision is relevant to your >current project or not. I'm not sure either. Would it interfere with the positioning of plots when using "set l/b/r/tmargin <margin>"? I'm using "set ?margin" to explicity set the position of the axes when in multiplot mode, so that the axes align themselve across columns and/or rows. However, I noticed horizontal spacing of the axes/plots on my computuer is slightly different than what Matlab produces (the figure windows are exaclty the same size). Ben |
|
From: Ben A. <bpa...@ma...> - 2009-02-12 22:27:08
|
On Thursday, February 12, 2009, at 02:17PM, "Ethan Merritt" <merritt@u.washington.edu> wrote: >On Thursday 12 February 2009 10:37:25 Ben Abbott wrote: >> On Thursday, February 12, 2009, at 11:46AM, "Ethan A Merritt" <merritt@u.washington.edu> wrote: >> >On Thursday 12 February 2009, Ben Abbott wrote: >> > >> >> To properly interpret the "size" information I'll get from x11 using >> >> the GPVAL_TERM_WINDOWID, I'll need the value for GPVAL_TERM_VCHAR. >> >> Temporarily I can assume it is 13 pixels. However, as I'll be using >> >> the window size obtained from x11 to determine if the mouse was used >> >> to change its size, and subsequently update the figures' size property >> >> on the octave end, I'd like to make sure I get his correct. >> > >> >Use it for what? >> >> The window size reported by x11 includes the portion reporting the mouse coordinates, >> which is not part of the gnuplot canvas. >> So I'd like to have TERM_VCHAR so that I can subtract this from the window's height. > >Would you prefer a mousing mode that wrote the mouse coordinates without >extending the size on y? That would be a trivial change, and could be >toggled by the same hot-key that currently toggles the mouse coords on and off. hmmmm. I was not aware the mouse coordinates could be toogled on and off. What are the default hot-keys? If the mouse coordinates did not extend the y-size, the hassle of accounting for it would be more convenient. If the mouse coordinates continue to extend the y-size, then I suppose I'd need to know when the mouse coordinates are active, and by how many pixels the window has been extended (which is presently equal to GPVAV_TERM_VCHAR). Personally, I'd prefer that the mouse coordinates did not change the y size, but any solution that allow me to determine when the window is extended and by how much is ok. Ben |
|
From: Ethan M. <merritt@u.washington.edu> - 2009-02-12 22:53:10
|
On Thursday 12 February 2009 13:46:04 Ben Abbott wrote:
>
> On Thursday, February 12, 2009, at 02:17PM, "Ethan Merritt" <merritt@u.washington.edu> wrote:
> >On Thursday 12 February 2009 10:37:25 Ben Abbott wrote:
> >> On Thursday, February 12, 2009, at 11:46AM, "Ethan A Merritt" <merritt@u.washington.edu> wrote:
> >> >On Thursday 12 February 2009, Ben Abbott wrote:
> >> >
> >> >> To properly interpret the "size" information I'll get from x11 using
> >> >> the GPVAL_TERM_WINDOWID, I'll need the value for GPVAL_TERM_VCHAR.
> >> >> Temporarily I can assume it is 13 pixels. However, as I'll be using
> >> >> the window size obtained from x11 to determine if the mouse was used
> >> >> to change its size, and subsequently update the figures' size property
> >> >> on the octave end, I'd like to make sure I get his correct.
> >> >
> >> >Use it for what?
> >>
> >> The window size reported by x11 includes the portion reporting the mouse coordinates,
> >> which is not part of the gnuplot canvas.
> >> So I'd like to have TERM_VCHAR so that I can subtract this from the window's height.
> >
> >Would you prefer a mousing mode that wrote the mouse coordinates without
> >extending the size on y? That would be a trivial change, and could be
> >toggled by the same hot-key that currently toggles the mouse coords on and off.
>
> hmmmm. I was not aware the mouse coordinates could be toogled on and off.
'm'
> What are the default hot-keys?
gnuplot> bind
2x<B1> print coordinates to clipboard using `clipboardformat`
(see keys '3', '4')
<B2> annotate the graph using `mouseformat` (see keys '1', '2')
or draw labels if `set mouse labels is on`
<Ctrl-B2> remove label close to pointer if `set mouse labels` is on
<B3> mark zoom region (only for 2d-plots and maps).
<B1-Motion> change view (rotation). Use <ctrl> to rotate the axes only.
<B2-Motion> change view (scaling). Use <ctrl> to scale the axes only.
<Shift-B2-Motion> vertical motion -- change xyplane
q * close this plot window
a `builtin-autoscale` (set autoscale keepfix; replot)
b `builtin-toggle-border`
e `builtin-replot`
g `builtin-toggle-grid`
h `builtin-help`
l `builtin-toggle-log` y logscale for plots, z and cb for splots
L `builtin-nearest-log` toggle logscale of axis nearest cursor
m `builtin-toggle-mouse`
r `builtin-toggle-ruler`
1 `builtin-decrement-mousemode`
2 `builtin-increment-mousemode`
3 `builtin-decrement-clipboardmode`
4 `builtin-increment-clipboardmode`
5 `builtin-toggle-polardistance`
6 `builtin-toggle-verbose`
7 `builtin-toggle-ratio`
n `builtin-zoom-next` go to next zoom in the zoom stack
p `builtin-zoom-previous` go to previous zoom in the zoom stack
u `builtin-unzoom`
Right `builtin-rotate-right` only for splots; <shift> increases amount
Up `builtin-rotate-up` only for splots; <shift> increases amount
Left `builtin-rotate-left` only for splots; <shift> increases amount
Down `builtin-rotate-down` only for splots; <shift> increases amount
Escape `builtin-cancel-zoom` cancel zoom region
* indicates this key is active from all plot windows
> If the mouse coordinates did not extend the y-size, the hassle of accounting for it would be more convenient.
>
> If the mouse coordinates continue to extend the y-size, then I suppose I'd need to know when the mouse coordinates are active, and by how many pixels the window has been extended (which is presently equal to GPVAV_TERM_VCHAR).
>
> Personally, I'd prefer that the mouse coordinates did not change the y size, but any solution that allow me to determine when the window is extended and by how much is ok.
>
> Ben
>
--
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742
|
|
From: Petr M. <mi...@ph...> - 2009-02-12 23:08:30
|
> hmmmm. I was not aware the mouse coordinates could be toogled on and off. > What are the default hot-keys? > > If the mouse coordinates did not extend the y-size, the hassle of > accounting for it would be more convenient. It is even worse ... the "wxt" terminal has icon bar which also extends the plot area. The "Qt" terminal may be even different. Therefore, set term wxt|x11 size nnn,nnn plot x !xwininfo show different numbers. You can find that set term x11|wxt size nnn,nnn means the size of the graph-canvas area, not the full x11 window. IMHO, Octave does not need to know the size of the window, does it? Is it really useful for any practical case? I don't think so. And if user changes set(gfc, 'position', [....]) and you pass these numbers to gnuplot, then it will set the size as expected. --- PM |
|
From: Ben A. <bpa...@ma...> - 2009-02-12 23:51:20
|
On Feb 12, 2009, at 6:08 PM, Petr Mikulik wrote: >> hmmmm. I was not aware the mouse coordinates could be toogled on >> and off. >> What are the default hot-keys? >> >> If the mouse coordinates did not extend the y-size, the hassle of >> accounting for it would be more convenient. > > It is even worse ... the "wxt" terminal has icon bar which also > extends the > plot area. The "Qt" terminal may be even different. Therefore, > set term wxt|x11 size nnn,nnn > plot x > !xwininfo > show different numbers. You can find that > set term x11|wxt size nnn,nnn > means the size of the graph-canvas area, not the full x11 window. > > IMHO, Octave does not need to know the size of the window, does it? > Is it really useful for any practical case? I don't think so. > And if user changes > set(gfc, 'position', [....]) > and you pass these numbers to gnuplot, then it will set the size as > expected. If the "icon bar" is a fixed size in pixels, then I can handle wxt, Qt, and x11 having their sizes reported differently by xwininfo (or the like). If the "icon bar" is not a fixed size, then that would be problematic. We'd likely only update Octave's figure position property when we can be confident that x11 properly reports the window's size and position. As the figure position property is intended to be bidirectional, I think there will be too much confusion if it is implemented in a one- directional manner. If we cannot update the property value when the window is moved by the mouse, then I suspect the preferred solution will be to allow the window to be positioned and sized when opened, but not there after. Thus the only opportunities to do that would be ... figure (1, "position", [440 314 560 420]) or set (0, "defaultfigurepositionproperty", [440 314 560 420]) figure (2) By the way, regarding Qt, I don't think we'll know if it is running on top of x11, Windows, or Quartz. So I'm skeptical we can obtain window size/position information ... or am I missing something? Ben |
|
From: Ethan M. <merritt@u.washington.edu> - 2009-02-13 00:28:13
|
On Thursday 12 February 2009 15:51:13 Ben Abbott wrote: > > On Feb 12, 2009, at 6:08 PM, Petr Mikulik wrote: > > >> hmmmm. I was not aware the mouse coordinates could be toogled on > >> and off. > >> What are the default hot-keys? > >> > >> If the mouse coordinates did not extend the y-size, the hassle of > >> accounting for it would be more convenient. > > > > It is even worse ... the "wxt" terminal has icon bar which also > > extends the > > plot area. The "Qt" terminal may be even different. Therefore, > > set term wxt|x11 size nnn,nnn > > plot x > > !xwininfo > > show different numbers. You can find that > > set term x11|wxt size nnn,nnn > > means the size of the graph-canvas area, not the full x11 window. > > > > IMHO, Octave does not need to know the size of the window, does it? > > Is it really useful for any practical case? I don't think so. > > And if user changes > > set(gfc, 'position', [....]) > > and you pass these numbers to gnuplot, then it will set the size as > > expected. > > If the "icon bar" is a fixed size in pixels, then I can handle wxt, > Qt, and x11 having their sizes reported differently by xwininfo (or > the like). If the "icon bar" is not a fixed size, then that would be > problematic. We'd likely only update Octave's figure position property > when we can be confident that x11 properly reports the window's size > and position. I repeat an earlier question: why do you assume that x11 is being used? On OSX + aqua, for example, no x-server may be present at all. I also return to my earlier opinion that Octave has no business resizing the user's windows, where "window" means the entire window rather than merely the plot area. If you want a 200x200 pixel plot, fine. But don't try to double-guess how many additional pixels may be added by gnuplot for mouse tracking, or by the window manager for widgets. These will vary from one person's desktop to the next, or even from one session to the next. In fact I'd love to extend the widget bars now in wxt and qt so that the user can configure/add/remove widgets from the bar, or undock it from the plot window. If Octave wants to read and store other window properties so that an earlier session can be restored, that seems fine. But it should be doable without having to understand exactly how each property came to have exactly the value it does. You really just want some way to tell the window manager "put this back the way it was". > As the figure position property is intended to be bidirectional, I > think there will be too much confusion if it is implemented in a one- > directional manner. If we cannot update the property value when the > window is moved by the mouse, then I suspect the preferred solution > will be to allow the window to be positioned and sized when opened, > but not there after. Right. No re-positioning or re-sizing of an existing window. > Thus the only opportunities to do that would be ... > > figure (1, "position", [440 314 560 420]) > > or > > set (0, "defaultfigurepositionproperty", [440 314 560 420]) > figure (2) > > By the way, regarding Qt, I don't think we'll know if it is running on > top of x11, Windows, or Quartz. So I'm skeptical we can obtain window > size/position information ... or am I missing something? Yeah, that's what I was pointing out up above. On the other hand, Qt must have its own mechanism for querying window properties. -- Ethan A Merritt |
|
From: Timothée L. <tim...@lp...> - 2009-02-13 07:53:35
|
Ben Abbott wrote: > On Feb 12, 2009, at 6:08 PM, Petr Mikulik wrote: > > >>> hmmmm. I was not aware the mouse coordinates could be toogled on >>> and off. >>> What are the default hot-keys? >>> >>> If the mouse coordinates did not extend the y-size, the hassle of >>> accounting for it would be more convenient. >>> >> It is even worse ... the "wxt" terminal has icon bar which also >> extends the >> plot area. The "Qt" terminal may be even different. Therefore, >> set term wxt|x11 size nnn,nnn >> plot x >> !xwininfo >> show different numbers. You can find that >> set term x11|wxt size nnn,nnn >> means the size of the graph-canvas area, not the full x11 window. >> >> IMHO, Octave does not need to know the size of the window, does it? >> Is it really useful for any practical case? I don't think so. >> And if user changes >> set(gfc, 'position', [....]) >> and you pass these numbers to gnuplot, then it will set the size as >> expected. >> > > If the "icon bar" is a fixed size in pixels, then I can handle wxt, > Qt, and x11 having their sizes reported differently by xwininfo (or > the like). If the "icon bar" is not a fixed size, then that would be > problematic. We'd likely only update Octave's figure position property > when we can be confident that x11 properly reports the window's size > and position. I fully agree with Ethan here : it seems more logical to fix a size for the plot area rather than for the plot window. It makes that property consistent when used with screen-based terminals and then exporting to a file terminal. For example, you ask for a 400x300 pixels figure, why would you want to get a 400x300 pixels PNG from the png terminal and only a 350x290 pixels plot area in x11/wxt/... ? I'm quite sure you want 400x300 plot area in both cases. Timothée |
|
From: Ben A. <bpa...@ma...> - 2009-02-12 23:30:11
|
On Feb 12, 2009, at 4:59 PM, Ethan Merritt wrote: > On Thursday 12 February 2009 13:46:04 Ben Abbott wrote: >> >> On Thursday, February 12, 2009, at 02:17PM, "Ethan Merritt" <merritt@u.washington.edu >> > wrote: >>> On Thursday 12 February 2009 10:37:25 Ben Abbott wrote: >>>> On Thursday, February 12, 2009, at 11:46AM, "Ethan A Merritt" <merritt@u.washington.edu >>>> > wrote: >>>>> On Thursday 12 February 2009, Ben Abbott wrote: >>>>> >>>>>> To properly interpret the "size" information I'll get from x11 >>>>>> using >>>>>> the GPVAL_TERM_WINDOWID, I'll need the value for >>>>>> GPVAL_TERM_VCHAR. >>>>>> Temporarily I can assume it is 13 pixels. However, as I'll be >>>>>> using >>>>>> the window size obtained from x11 to determine if the mouse was >>>>>> used >>>>>> to change its size, and subsequently update the figures' size >>>>>> property >>>>>> on the octave end, I'd like to make sure I get his correct. >>>>> >>>>> Use it for what? >>>> >>>> The window size reported by x11 includes the portion reporting >>>> the mouse coordinates, >>>> which is not part of the gnuplot canvas. >>>> So I'd like to have TERM_VCHAR so that I can subtract this from >>>> the window's height. >>> >>> Would you prefer a mousing mode that wrote the mouse coordinates >>> without >>> extending the size on y? That would be a trivial change, and >>> could be >>> toggled by the same hot-key that currently toggles the mouse >>> coords on and off. >> >> hmmmm. I was not aware the mouse coordinates could be toogled on >> and off. > > 'm' > >> If the mouse coordinates did not extend the y-size, the hassle of >> accounting for it would be more convenient. >> >> If the mouse coordinates continue to extend the y-size, then I >> suppose I'd need to know when the mouse coordinates are active, and >> by how many pixels the window has been extended (which is presently >> equal to GPVAV_TERM_VCHAR). >> >> Personally, I'd prefer that the mouse coordinates did not change >> the y size, but any solution that allow me to determine when the >> window is extended and by how much is ok. >> >> Ben >> ok, now that I can see that toggling the mouse coordinates on/off results in a change to the window height. As we cannot be sure that the window size returned by x11 includes the extension or not, I'm now strongly in favor of gnuplot *not* extending the window when displaying the coordinates ... or being able to tell gnuplot not to. Ben |
|
From: Ben A. <bpa...@ma...> - 2009-02-13 02:36:29
|
On Feb 12, 2009, at 7:28 PM, Ethan Merritt wrote: > On Thursday 12 February 2009 15:51:13 Ben Abbott wrote: >> >> On Feb 12, 2009, at 6:08 PM, Petr Mikulik wrote: >> >>>> hmmmm. I was not aware the mouse coordinates could be toogled on >>>> and off. >>>> What are the default hot-keys? >>>> >>>> If the mouse coordinates did not extend the y-size, the hassle of >>>> accounting for it would be more convenient. >>> >>> It is even worse ... the "wxt" terminal has icon bar which also >>> extends the >>> plot area. The "Qt" terminal may be even different. Therefore, >>> set term wxt|x11 size nnn,nnn >>> plot x >>> !xwininfo >>> show different numbers. You can find that >>> set term x11|wxt size nnn,nnn >>> means the size of the graph-canvas area, not the full x11 window. >>> >>> IMHO, Octave does not need to know the size of the window, does it? >>> Is it really useful for any practical case? I don't think so. >>> And if user changes >>> set(gfc, 'position', [....]) >>> and you pass these numbers to gnuplot, then it will set the size as >>> expected. >> >> If the "icon bar" is a fixed size in pixels, then I can handle wxt, >> Qt, and x11 having their sizes reported differently by xwininfo (or >> the like). If the "icon bar" is not a fixed size, then that would be >> problematic. We'd likely only update Octave's figure position >> property >> when we can be confident that x11 properly reports the window's size >> and position. > > I repeat an earlier question: why do you assume that x11 is being > used? > On OSX + aqua, for example, no x-server may be present at all. I'm not assuming x11 is being used. Since Octave tells gnuplot which terminal is being used. > I also return to my earlier opinion that Octave has no business > resizing > the user's windows, where "window" means the entire window rather than > merely the plot area. This is a decision that was historically made my Mathworks. > If you want a 200x200 pixel plot, fine. But don't > try to double-guess how many additional pixels may be added by gnuplot > for mouse tracking, or by the window manager for widgets. These will > vary from one person's desktop to the next, or even from one session > to > the next. In fact I'd love to extend the widget bars now in wxt and > qt > so that the user can configure/add/remove widgets from the bar, or > undock > it from the plot window. hmmm ... it may be that it is unwise for gnuplot to support the functionality that Octave's development requires for compatibility with Matlab. If that is the case, we should be sure to document the reason so that both development teams understand the problem and we don't rehash it in the future. > If Octave wants to read and store other window properties so that > an earlier session can be restored, that seems fine. Octave has no interest in restoring a prior state (If I understand you correctly). However, it does have an interest in allowing the user to specify a state, or change a state via the command line or scripting language (as is done in Matlab). > But it should be > doable without having to understand exactly how each property > came to have exactly the value it does. You really just want some > way to tell the window manager "put this back the way it was". > >> As the figure position property is intended to be bidirectional, I >> think there will be too much confusion if it is implemented in a one- >> directional manner. If we cannot update the property value when the >> window is moved by the mouse, then I suspect the preferred solution >> will be to allow the window to be positioned and sized when opened, >> but not there after. > > Right. No re-positioning or re-sizing of an existing window. Personally, I have no position on what is and is not proper with respect to the positioning of windows. However, I think it is important to clarify a point. Octave's intention is to allow the user to move/resize the figures via the mouse, the command line, or a script. This intent is primarily driven by the goal of compatibility with Matlab. That said, the current state of Octave's development sources when running gnuplot's development sources with the x11 terminal is not what we'd like it to be. Octave presently ignores any repositioning/ resizing via the mouse and repositions and resizes the figure to the location specified by the figure's position property. This only happens for the x11 terminal when running development versions of Octave and Gnuplot. This undesirable behavior will be resolved soon (I hope). Ben |
|
From: Ethan M. <merritt@u.washington.edu> - 2009-02-13 02:01:15
|
On Thursday 12 February 2009 17:31:14 Ben Abbott wrote: > > Ethan Merrit wrote: > > Right. No re-positioning or re-sizing of an existing window. > > > Personally, I have no position on what is and is not proper with > respect to the positioning of windows. However, I think it is > important to clarify a point. > > Octave's intention is to allow the user to move/resize the figures via > the mouse, the command line, or a script. This intent is primarily > driven by the goal of compatibility with Matlab. Shrug. It's your project, not mine. Do as you like. But IMHO it is a mistake to define your own goal as imitation of the behaviour of another project, particular a closed-source one. This is why (IMHO of course) OpenOffice is such a disaster. The people who care about how well you imitate the other program *are already using the other program*! Why would they switch to yours? Do it better. Don't imitate their mistakes, correct them. Add features. Let them scramble to imitate you, rather than vice versa :-) By all means, strive to accept Matlab scripts as input. And obviously one would hope that the plots themselves would come out the same. But none of that imposes any requirement for duplicating window decorations, or placement, or mouse interactions for that matter. Is there no functionality you'd like to add that Matlab lacks? > That said, the current state of Octave's development sources when > running gnuplot's development sources with the x11 terminal is not > what we'd like it to be. Octave presently ignores any repositioning/ > resizing via the mouse and repositions and resizes the figure to the > location specified by the figure's position property. This only > happens for the x11 terminal when running development versions of > Octave and Gnuplot. Please clarify. Do you mean that everything works as intended in the released versions of Octave + gnuplot, but this has become broken in the development versions? Did we actually make things worse by allowing you to set the terminal size externally? > This undesirable behavior will be resolved soon (I hope). -- Ethan A Merritt |
|
From: Petr M. <mi...@ph...> - 2009-02-13 08:59:26
|
> >Right. No re-positioning or re-sizing of an existing window. > > Personally, I have no position on what is and is not proper with respect to > the positioning of windows. However, I think it is important to clarify a > point. > > Octave's intention is to allow the user to move/resize the figures via the > mouse, the command line, or a script. This intent is primarily driven by the > goal of compatibility with Matlab. All these 3 move/resize work correctly. The only way which is not available is the feedback of "user moves/resizes by mouse" => "update this information in Octave". We have shown that it is a wrong way to use "xwininfo" for this because it returns the window size, not the plot size, and it would work on X11 only. Therefore, the only solution is to have new variables GPVAL_PLOT_SIZE GPVAL_PLOT_POSITION e.g. GPVAL_PLOT_SIZE=600 400 GPVAL_PLOT_POSITION=0 0 which would Octave check when it needs them. These values would be compatible with values in set term x1||wxt|... size nnn,nnn position mmm,mmm If they are not available (as nowadays), Octave should not use set term ... size position unless user explicitly changes these values via set(gcf, 'position', [new values]) I propose you add a static variable which remembers last 'position' values and does "set term ... size position" only in case of a change. I think this is a useful compromise. --- PM |
|
From: Ben A. <bpa...@ma...> - 2009-02-13 12:40:13
|
On Feb 12, 2009, at 9:01 PM, Ethan Merritt wrote: > On Thursday 12 February 2009 17:31:14 Ben Abbott wrote: >> >> Ethan Merrit wrote: >>> Right. No re-positioning or re-sizing of an existing window. >> >> >> Personally, I have no position on what is and is not proper with >> respect to the positioning of windows. However, I think it is >> important to clarify a point. >> >> Octave's intention is to allow the user to move/resize the figures >> via >> the mouse, the command line, or a script. This intent is primarily >> driven by the goal of compatibility with Matlab. > > Shrug. It's your project, not mine. Do as you like. > But IMHO it is a mistake to define your own goal as imitation of the > behaviour of another project, particular a closed-source one. > This is why (IMHO of course) OpenOffice is such a disaster. > The people who care about how well you imitate the other program > *are already using the other program*! Why would they switch to > yours? > Do it better. Don't imitate their mistakes, correct them. > Add features. Let them scramble to imitate you, rather than vice > versa :-) > > By all means, strive to accept Matlab scripts as input. And > obviously one would hope that the plots themselves would come out > the same. But none of that imposes any requirement for duplicating > window decorations, or placement, or mouse interactions for that > matter. > Is there no functionality you'd like to add that Matlab lacks? > >> That said, the current state of Octave's development sources when >> running gnuplot's development sources with the x11 terminal is not >> what we'd like it to be. Octave presently ignores any repositioning/ >> resizing via the mouse and repositions and resizes the figure to the >> location specified by the figure's position property. This only >> happens for the x11 terminal when running development versions of >> Octave and Gnuplot. > > Please clarify. Do you mean that everything works as intended in > the released versions of Octave + gnuplot, but this has become broken > in the development versions? hmmm, not really. There is nothing broken. We're just incrementally moving toward a compatible solution. In addition, the undesired feature that counters window placement by the mouse is easily disabled. You made some good points. You convinced me that my eagerness to move/ resize the window after it is already open needs further consideration. I think it best to disable that feature in Octave's sources, and to include the ability to update the figure property position in a reliable manner before reconsidering it. At this point, I'd like to respectfully ask if gnuplot is able to supply the support needed to allow octave to (1) specify the initial window position and size for x11 as well as other terminals (done for some already), and (2) determine the position and size after mouse movements (I think the next item of repositioning and resizing gnuplot windows should be tabled for now). Regarding x11 and (2), we would desire that the vertical extension present when displaying mouse coordinates go away. You had mentioned that might be possible. Can/should this be done? Regarding wxt, Qt (others?), do you know if it is possible to determine their canvas sizes as well? Ben |
|
From: Ethan M. <merritt@u.washington.edu> - 2009-02-13 18:24:18
|
On Friday 13 February 2009 04:40:00 Ben Abbott wrote: > At this point, I'd like to respectfully ask if gnuplot is able to > supply the support needed to allow octave to (1) specify the initial > window position and size for x11 as well as other terminals (done for > some already), and (2) determine the position and size after mouse > movements (I think the next item of repositioning and resizing gnuplot > windows should be tabled for now). I think the answer is no, it is not possible at present. We seem to be in the exploratory stages of determining whether it might be possible to do this in the future. > Regarding x11 and (2), we would desire that the vertical extension > present when displaying mouse coordinates go away. You had mentioned > that might be possible. Can/should this be done? That should be straightforward. I will add it to the TODO list. > Regarding wxt, Qt (others?), do you know if it is possible to > determine their canvas sizes as well? I expect that it is possible, but that doesn't mean I know how to do it. But it is definitely not possible for every terminal driver. Consider "set term xlib". This is mostly for debugging, but it does work to save x11 display commands for later execution. All the plotting commands flow through the normal x11 code in gnuplot, but there is no actual display window created and hence the canvas size is entirely undefined. If you play back the commands later on using gnuplot_x11 then you see a real plot canvas with a real size. But gnuplot itself is no longer in the picture at this point. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Ben A. <bpa...@ma...> - 2009-02-13 12:42:29
|
On Feb 13, 2009, at 2:53 AM, Timothée Lecomte wrote: > Ben Abbott wrote: >> On Feb 12, 2009, at 6:08 PM, Petr Mikulik wrote: >> >> >>>> hmmmm. I was not aware the mouse coordinates could be toogled on >>>> and off. >>>> What are the default hot-keys? >>>> >>>> If the mouse coordinates did not extend the y-size, the hassle of >>>> accounting for it would be more convenient. >>>> >>> It is even worse ... the "wxt" terminal has icon bar which also >>> extends the >>> plot area. The "Qt" terminal may be even different. Therefore, >>> set term wxt|x11 size nnn,nnn >>> plot x >>> !xwininfo >>> show different numbers. You can find that >>> set term x11|wxt size nnn,nnn >>> means the size of the graph-canvas area, not the full x11 window. >>> >>> IMHO, Octave does not need to know the size of the window, does it? >>> Is it really useful for any practical case? I don't think so. >>> And if user changes >>> set(gfc, 'position', [....]) >>> and you pass these numbers to gnuplot, then it will set the size as >>> expected. >>> >> >> If the "icon bar" is a fixed size in pixels, then I can handle >> wxt, Qt, and x11 having their sizes reported differently by >> xwininfo (or the like). If the "icon bar" is not a fixed size, >> then that would be problematic. We'd likely only update Octave's >> figure position property when we can be confident that x11 >> properly reports the window's size and position. > I fully agree with Ethan here : it seems more logical to fix a size > for the plot area rather than for the plot window. It makes that > property consistent when used with screen-based terminals and then > exporting to a file terminal. For example, you ask for a 400x300 > pixels figure, why would you want to get a 400x300 pixels PNG from > the png terminal and only a 350x290 pixels plot area in x11/ > wxt/... ? I'm quite sure you want 400x300 plot area in both cases. > > Timothée Agreed. What Octave desires is to know the size of the canvas. Ben |
|
From: Ben A. <bpa...@ma...> - 2009-02-13 12:52:12
|
On Feb 13, 2009, at 3:59 AM, Petr Mikulik wrote: >>> Right. No re-positioning or re-sizing of an existing window. >> >> Personally, I have no position on what is and is not proper with >> respect to >> the positioning of windows. However, I think it is important to >> clarify a >> point. >> >> Octave's intention is to allow the user to move/resize the figures >> via the >> mouse, the command line, or a script. This intent is primarily >> driven by the >> goal of compatibility with Matlab. > > All these 3 move/resize work correctly. The only way which is not > available > is the feedback of "user moves/resizes by mouse" => "update this > information > in Octave". We have shown that it is a wrong way to use "xwininfo" > for this > because it returns the window size, not the plot size, and it would > work on > X11 only. Therefore, the only solution is to have new variables > GPVAL_PLOT_SIZE > GPVAL_PLOT_POSITION > e.g. > GPVAL_PLOT_SIZE=600 400 > GPVAL_PLOT_POSITION=0 0 > which would Octave check when it needs them. > > These values would be compatible with values in > set term x1||wxt|... size nnn,nnn position mmm,mmm Having those new variables would be a great help. > If they are not available (as nowadays), Octave should not use > set term ... size position > unless user explicitly changes these values via > set(gcf, 'position', [new values]) > I propose you add a static variable which remembers last 'position' > values > and does "set term ... size position" only in case of a change. I > think this > is a useful compromise. Ethan has convinced me to proceed cautiously. I'd like to first keep the figure position property up to date with the mouse movements. In the event, that octave does support repositioning of a gnuplot window, your points will need to be respected. There are plans to put listeners in place to handle such events (the support for listeners is already in place). Ben |
|
From: Ethan A M. <merritt@u.washington.edu> - 2009-02-13 16:27:18
|
On Friday 13 February 2009, Petr Mikulik wrote: > > >Right. No re-positioning or re-sizing of an existing window. > > > > Personally, I have no position on what is and is not proper with respect to > > the positioning of windows. However, I think it is important to clarify a > > point. > > > > Octave's intention is to allow the user to move/resize the figures via the > > mouse, the command line, or a script. This intent is primarily driven by the > > goal of compatibility with Matlab. > > All these 3 move/resize work correctly. The only way which is not available > is the feedback of "user moves/resizes by mouse" => "update this information > in Octave". We have shown that it is a wrong way to use "xwininfo" for this > because it returns the window size, not the plot size, and it would work on > X11 only. Therefore, the only solution is to have new variables > GPVAL_PLOT_SIZE > GPVAL_PLOT_POSITION > e.g. > GPVAL_PLOT_SIZE=600 400 > GPVAL_PLOT_POSITION=0 0 > which would Octave check when it needs them. We already support this! (Well OK, not the position part. I am strictly opposed to that). This was, in fact, the original motivation for adding the GPVAL_* variables. The information variables were added exactly so that they could be used by higher level program to implement external mousing and the creation of image maps for, e.g., png images displayed on the web. The canvas size is held by GPVAL_TERM_XMIN, GPVAL_TERM_XMAX, etc... The plot boundaries are held by GPVAL_X_MIN, .... This mechanism is in real use in conjunction with several terminals, including the recently added canvas terminal. > These values would be compatible with values in > set term x1||wxt|... size nnn,nnn position mmm,mmm No. That cannot work. In order to be valid, the must represent the values used by the most recent plot, not the values that were originally set by the "set term" command. > If they are not available (as nowadays), Octave should not use > set term ... size position > unless user explicitly changes these values via > set(gcf, 'position', [new values]) > I propose you add a static variable which remembers last 'position' values > and does "set term ... size position" only in case of a change. I think this > is a useful compromise. I am strictly opposed to adding a "position" property to gnuplot's "set term" commands. If you require the ability to place multiple plots relative to each other, then use multiplot mode and a larger canvas. -- Ethan A Merritt |
|
From: Ethan M. <merritt@u.washington.edu> - 2009-02-13 18:13:10
|
On Friday 13 February 2009 08:27:08 Ethan A Merritt wrote: > The canvas size is held by GPVAL_TERM_XMIN, GPVAL_TERM_XMAX, etc... > The plot boundaries are held by GPVAL_X_MIN, .... Sorry, I got that wrong. There are indeed serious issues lurking here. The properties are reported as follows: Plot boundaries in "terminal coordinates" GPVAL_TERM_XMIN, GPVAL_TERM_XMAX, ... Plot boundaries in axis coordinates (i.e. xrange[], yrange[]) GPVAL_XMIN, GPVAL_XMAX, GPVAL_LOG, GPVAL_REVERSE, ... Exact canvas size Not as easily obtained as I remembered. The canvas driver writes the exact size to the output, for example, as does svg and various pixel drivers. But it is not exported as a pair of GPVAL_* values. The existing system does work for mousing, because the information is sufficient to decode coordinates within the plot boundaries. But I agree that there is room for improvement here, and I'm not sure how to make it fully generic. 1) What should we report as the canvas size for vector terminals? It is easy to export term->xmax and term->ymax, but for some terminals including x11 these have nothing to do with the size of the actual display. I discussed this is a previous post, suggesting that the coordinate handling in x11 could be changed to get rid of this discrepancy. 2) What about pixel terminals where the "terminal coordinates" do not map identicallly to pixel coordinates? E.g. wxt in over-sampling mode. Here I think we have two choices. We could export the terminal scale factor as well. So... GPVAL_TERM_XSCALE, GPVAL_TERM_YSCALE Or alternatively we could modify the current code so that GPVAL_TERM_XMIN and friends have already been divided by the appropriate scale factor. I know this affects wxt. I'm not sure who else. pngcairo? 3) What about the case currently under discussion. Can we even get reliable canvas size information for x11, wxt, aqua, qt? For that matter, what about windows? I suspect the answer is yes, but that doesn't mean I know how to do it. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Ben A. <bpa...@ma...> - 2009-02-13 16:42:51
|
On Friday, February 13, 2009, at 11:27AM, "Ethan A Merritt" <merritt@u.washington.edu> wrote: >On Friday 13 February 2009, Petr Mikulik wrote: >> > >Right. No re-positioning or re-sizing of an existing window. >> > >> > Personally, I have no position on what is and is not proper with respect to >> > the positioning of windows. However, I think it is important to clarify a >> > point. >> > >> > Octave's intention is to allow the user to move/resize the figures via the >> > mouse, the command line, or a script. This intent is primarily driven by the >> > goal of compatibility with Matlab. >> >> All these 3 move/resize work correctly. The only way which is not available >> is the feedback of "user moves/resizes by mouse" => "update this information >> in Octave". We have shown that it is a wrong way to use "xwininfo" for this >> because it returns the window size, not the plot size, and it would work on >> X11 only. Therefore, the only solution is to have new variables >> GPVAL_PLOT_SIZE >> GPVAL_PLOT_POSITION >> e.g. >> GPVAL_PLOT_SIZE=600 400 >> GPVAL_PLOT_POSITION=0 0 >> which would Octave check when it needs them. > > >We already support this! (Well OK, not the position part. I am strictly >opposed to that). This was, in fact, the original motivation for >adding the GPVAL_* variables. The information variables were added >exactly so that they could be used by higher level program to implement >external mousing and the creation of image maps for, e.g., png images >displayed on the web. > >The canvas size is held by GPVAL_TERM_XMIN, GPVAL_TERM_XMAX, etc... >The plot boundaries are held by GPVAL_X_MIN, .... > >This mechanism is in real use in conjunction with several terminals, >including the recently added canvas terminal. > >> These values would be compatible with values in >> set term x1||wxt|... size nnn,nnn position mmm,mmm > >No. That cannot work. In order to be valid, the must represent the >values used by the most recent plot, not the values that were originally >set by the "set term" command. > >> If they are not available (as nowadays), Octave should not use >> set term ... size position >> unless user explicitly changes these values via >> set(gcf, 'position', [new values]) >> I propose you add a static variable which remembers last 'position' values >> and does "set term ... size position" only in case of a change. I think this >> is a useful compromise. > > >I am strictly opposed to adding a "position" property to gnuplot's "set term" >commands. If you require the ability to place multiple plots relative to >each other, then use multiplot mode and a larger canvas. > Ethan you convinced me that gnuplot's windows should not be moved by the "set term" command. Is there reason to not allow the windows to be opened at specific positions? Ben |
|
From: Ralf J. <jue...@cs...> - 2009-02-13 18:24:07
|
On Fri, 13 Feb 2009, Ben Abbott wrote: >> I am strictly opposed to adding a "position" property to gnuplot's "set term" >> commands. If you require the ability to place multiple plots relative to >> each other, then use multiplot mode and a larger canvas. >> > > Ethan you convinced me that gnuplot's windows should not be moved by the "set term" command. > > Is there reason to not allow the windows to be opened at specific positions? I can't resist but to add my two cents. Ben was asking that gnuplot supports capabilities which are already offered by a system's window manager. I think it is very useful to be able to control, per script, the size and position of windows opened by that script. But I agree with Ethan and others who essentially said that gnuplot is the wrong place to add a solution for this. The burden is on the Octave project to come up with a cross-platform interface to the different window managers to implement that capability. What is need from gnuplot is a way to query the window ID or window handle of a terminal window. On a second thought, in Matlab you can program GUIs for your application. And one may embedd plots in a GUI. That means, you would need the capability to render a plot in a user-provided canvas widget. The x11 terminal currently supports this, have you looked at the gpdemos.tcl in gnuplot's demo directory? It seems to me, this is what you really want to do, at the end of the day. Ralf > > Ben > > > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > |
|
From: Petr M. <mi...@ph...> - 2009-02-13 23:12:36
|
> >> unless user explicitly changes these values via > >> set(gcf, 'position', [new values]) > >> I propose you add a static variable which remembers last 'position' values > >> and does "set term ... size position" only in case of a change. I think this > >> is a useful compromise. I propose the following solution to this case: gnuplot: - I will commit the patch to define GPVAL_TERM_WINDOWID. Octave: - It will use "set term ..." without "size and position" by default. - It will have a flag to see whether user has changed (gcf, 'position') explicitly; only in this case, it will use "set term .. size position". - If user wants get(gcf), then Octave will find the current values by: 1a. launch new gnuplot instance with set term x11 position 100,100 size 100,100 1b. by means of GPVAL_TERM_WINDOWID and xwininfo, get the current value of position => these are the correction factors with respect to the above 100,100 1c. close this dummy gnuplot session 2. get xwininfo from the gcf's session and correct it by the above factors Note that 1. can be done once only. Note this will work on X11 only. More portable way is that terminals report some GPVAL_ variables about their position on the desktop, but it would just increase the piping traffic and I doubt it's worth the effort. --- PM |
|
From: Ben A. <bpa...@ma...> - 2009-02-13 21:03:18
|
On Friday, February 13, 2009, at 01:04PM, "Ralf Juengling" <jue...@cs...> wrote: > > >On Fri, 13 Feb 2009, Ben Abbott wrote: > >>> I am strictly opposed to adding a "position" property to gnuplot's "set term" >>> commands. If you require the ability to place multiple plots relative to >>> each other, then use multiplot mode and a larger canvas. >>> >> >> Ethan you convinced me that gnuplot's windows should not be moved by the "set term" command. >> >> Is there reason to not allow the windows to be opened at specific positions? > >I can't resist but to add my two cents. > >Ben was asking that gnuplot supports capabilities which are already >offered by a system's window manager. I think it is very useful to >be able to control, per script, the size and position of windows >opened by that script. But I agree with Ethan and others who >essentially said that gnuplot is the wrong place to add a solution >for this. The burden is on the Octave project to come up with a >cross-platform interface to the different window managers to >implement that capability. What is need from gnuplot is a way to >query the window ID or window handle of a terminal window. > >On a second thought, in Matlab you can program GUIs for your >application. And one may embedd plots in a GUI. That means, you >would need the capability to render a plot in a user-provided >canvas widget. The x11 terminal currently supports this, have >you looked at the gpdemos.tcl in gnuplot's demo directory? >It seems to me, this is what you really want to do, at the end >of the day. > >Ralf > Good points ... worth more than 2c I think ;-) I'll take a look at gpdemos.tcl. Ben |
|
From: Ethan M. <merritt@u.washington.edu> - 2009-02-13 21:20:48
|
On Friday 13 February 2009 13:03:03 Ben Abbott wrote: > > On Friday, February 13, 2009, at 01:04PM, "Ralf Juengling" <jue...@cs...> wrote: > > > > > >On Fri, 13 Feb 2009, Ben Abbott wrote: > > > >>> I am strictly opposed to adding a "position" property to gnuplot's "set term" > >>> commands. If you require the ability to place multiple plots relative to > >>> each other, then use multiplot mode and a larger canvas. > >>> > >> > >> Ethan you convinced me that gnuplot's windows should not be moved by the "set term" command. > >> > >> Is there reason to not allow the windows to be opened at specific positions? > > > >I can't resist but to add my two cents. > > > >Ben was asking that gnuplot supports capabilities which are already > >offered by a system's window manager. I think it is very useful to > >be able to control, per script, the size and position of windows > >opened by that script. But I agree with Ethan and others who > >essentially said that gnuplot is the wrong place to add a solution > >for this. The burden is on the Octave project to come up with a > >cross-platform interface to the different window managers to > >implement that capability. What is need from gnuplot is a way to > >query the window ID or window handle of a terminal window. > > > >On a second thought, in Matlab you can program GUIs for your > >application. And one may embedd plots in a GUI. That means, you > >would need the capability to render a plot in a user-provided > >canvas widget. The x11 terminal currently supports this, have > >you looked at the gpdemos.tcl in gnuplot's demo directory? > >It seems to me, this is what you really want to do, at the end > >of the day. > > > >Ralf > > > > Good points ... worth more than 2c I think ;-) > > I'll take a look at gpdemos.tcl. In a similar vein, one could have the application open new browser windows and tell gnuplot to fill them with plots generated using the canvas or svg terminal. It might be tricky to do that via pipes rather than using temp files, but it has obvious attractions as well. I am currently quite interested in exploring what kinds of things can be done by using a browser as a generic interactive viewer, rather than requiring platform-speicific interactive viewers like gnuplot_x11, aquaterm, or the development version of wxt. Octave could be a neat example of this. Consider, for example, a teaching workshop where the output from one master Octave session is simultaneously visible in a browser window on each student's desktop - locally interactive, but driven remotely. -- Ethan A Merritt |
|
From: Ben A. <bpa...@ma...> - 2009-02-13 23:56:38
|
On Feb 13, 2009, at 6:12 PM, Petr Mikulik wrote: >>>> unless user explicitly changes these values via >>>> set(gcf, 'position', [new values]) >>>> I propose you add a static variable which remembers last >>>> 'position' values >>>> and does "set term ... size position" only in case of a change. I >>>> think this >>>> is a useful compromise. > > I propose the following solution to this case: > > gnuplot: > - I will commit the patch to define GPVAL_TERM_WINDOWID. ok > Octave: > - It will use "set term ..." without "size and position" by default. > - It will have a flag to see whether user has changed (gcf, > 'position') > explicitly; only in this case, it will use "set term .. size > position". > - If user wants get(gcf), then Octave will find the current values by: > 1a. launch new gnuplot instance with > set term x11 position 100,100 size 100,100 > 1b. by means of GPVAL_TERM_WINDOWID and xwininfo, get the > current value of position => these are the correction factors > with respect to the above 100,100 > 1c. close this dummy gnuplot session > 2. get xwininfo from the gcf's session and correct it by the above > factors > > Note that 1. can be done once only. > > Note this will work on X11 only. More portable way is that terminals > report > some GPVAL_ variables about their position on the desktop, but it > would just > increase the piping traffic and I doubt it's worth the effort. > > --- > PM Petr, I'm not following the Octave part. What are the correction factors to be determined by 1a,b,c? Regarding a flag to determine if the use changed the figure's position, we will need to find an approach that does not interfere with other backends. Meaning that setting and interpreting the flag should be isolated to the m-files supporting the gnuplot backend. I can do that if a gnuplot-only listener is assigned to the figure position property (i.e. the listener would store the last property specified by the user). Do you have another suggestion for how that might be done? In any event, when you reply, perhaps this discussion should be moved to Octave's list. Ben |
|
From: Petr M. <mi...@ph...> - 2009-02-15 22:24:26
|
> >gnuplot:
> >- I will commit the patch to define GPVAL_TERM_WINDOWID.
>
> ok
It was just committed.
> >Octave:
> >- It will use "set term ..." without "size and position" by default.
> >- It will have a flag to see whether user has changed (gcf, 'position')
> >explicitly; only in this case, it will use "set term .. size position".
> >- If user wants get(gcf), then Octave will find the current values by:
> > 1a. launch new gnuplot instance with
> > set term x11 position 100,100 size 100,100
> > 1b. by means of GPVAL_TERM_WINDOWID and xwininfo, get the
> > current value of position => these are the correction factors
> > with respect to the above 100,100
> > 1c. close this dummy gnuplot session
> > 2. get xwininfo from the gcf's session and correct it by the above
> > factors
> >
> >Note that 1. can be done once only.
> >
> >Note this will work on X11 only. More portable way is that terminals report
> >some GPVAL_ variables about their position on the desktop, but it would just
> >increase the piping traffic and I doubt it's worth the effort.
>
> I'm not following the Octave part. What are the correction factors to be
> determined by 1a,b,c?
You wanted to know what is the difference between position and size of the
full x11 window (as obtained by xwininfo) and the gnuplot's drawing canvas.
Furthermore, if you combine xwininfo with "unset mouse" and "set mouse", you
can see whether the x11 window is increased in size ("set term x11") or not
("set term wxt").
> Regarding a flag to determine if the user changed the figure's position,
> we will need to find an approach that does not interfere with other
> backends. Meaning that setting and interpreting the flag should be
> isolated to the m-files supporting the gnuplot backend. I can do that if a
> gnuplot-only listener is assigned to the figure position property (i.e.
> the listener would store the last property specified by the user).
>
> Do you have another suggestion for how that might be done?
The easist way is to ignore the location and size if it contains the default
four values.
---
PM
|
|
From: Ben A. <bpa...@ma...> - 2009-02-16 02:48:01
|
On Feb 15, 2009, at 5:15 PM, Petr Mikulik wrote:
>>> gnuplot:
>>> - I will commit the patch to define GPVAL_TERM_WINDOWID.
>>
>> ok
>
> It was just committed.
>
>>> Octave:
>>> - It will use "set term ..." without "size and position" by default.
>>> - It will have a flag to see whether user has changed (gcf,
>>> 'position')
>>> explicitly; only in this case, it will use "set term .. size
>>> position".
>>> - If user wants get(gcf), then Octave will find the current values
>>> by:
>>> 1a. launch new gnuplot instance with
>>> set term x11 position 100,100 size 100,100
>>> 1b. by means of GPVAL_TERM_WINDOWID and xwininfo, get the
>>> current value of position => these are the correction factors
>>> with respect to the above 100,100
>>> 1c. close this dummy gnuplot session
>>> 2. get xwininfo from the gcf's session and correct it by the above
>>> factors
>>>
>>> Note that 1. can be done once only.
>>>
>>> Note this will work on X11 only. More portable way is that
>>> terminals report
>>> some GPVAL_ variables about their position on the desktop, but it
>>> would just
>>> increase the piping traffic and I doubt it's worth the effort.
>>
>> I'm not following the Octave part. What are the correction factors
>> to be
>> determined by 1a,b,c?
>
> You wanted to know what is the difference between position and size
> of the
> full x11 window (as obtained by xwininfo) and the gnuplot's drawing
> canvas.
> Furthermore, if you combine xwininfo with "unset mouse" and "set
> mouse", you
> can see whether the x11 window is increased in size ("set term x11")
> or not
> ("set term wxt").
ok ... It hadn't occurred to me to toggle the mouse on/off.
Ben
|
