gnuplot-beta — Developers and beta testers of new gnuplot code

Re: GPVAL_TERM_VCHAR (was: problem with "set x11 {size WW,HH} {position XX,YY}")

[Ben A. <bpa...@ma...>]

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

Re: set term screen

[Petr M. <mi...@ph...>]

Ad "set termopt" -- I think there are problems:

gnuplot> set term x11 title 'hello'
Terminal type set to 'x11'
Options are ' nopersist title "hello"'

gnuplot> set termopt dashed

gnuplot> show term

   terminal type is x11  nopersist dashed

=> thus it has forgotten the title!


> > > > I was thinking how to smoothly support x11, wxt, and others, in a portable 
> > > > way. What about:
> > > > 
> > > > 	set term screen ... options ...
> > > > or
> > > > 	set term default ... options ...
> > > > 
> > > > There, the "screen" terminal is that after gnuplot's start-up, i.e. that in 
> > > > GPVAL_TERM. Then, Octave (or others) won't have to care about
> > > > 	set term x11
> > > > 	set term win
> > > > 	set term aqua
> > > > etc.; it will just do
> > > > 	set term screen|default|other_synonym
> 
> 
> Let's go back to the beginning.
> What exactly is the problem that is being solved?

User/script writes in a portable and elegant way:
	set term screen title 'hello'
	set term screen 4
	set term screen 5 size 400,400
instead of
	term_startup=GPVAL_TERM
        ...
	eval('set term '.term_startup.' title "hello"')
	eval('set term '.term_startup.' 4')
	eval('set term '.term_startup.' 5 size 400,400')
	

> What is it that you want to do with this saved terminal?
> Something different from "set term push" ?

You can push whichever terminal you like; however, the screen terminal stays 
the same.

---
PM

Re: GPVAL_TERM_VCHAR (was: problem with "set x11 {size WW,HH} {position XX,YY}")

[Petr M. <mi...@ph...>]

> >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

Re: GPVAL_TERM_VCHAR

[Timothée L. <tim...@lp...>]

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

Re: GPVAL_TERM_VCHAR (was: problem with "set x11 {size WW,HH} {position XX,YY}")

[Ben A. <bpa...@ma...>]

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

Re: GPVAL_TERM_VCHAR (was: problem with "set x11 {size WW, HH} {position XX, YY}")

[Ethan M. <merritt@u.washington.edu>]

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

Re: GPVAL_TERM_VCHAR (was: problem with "set x11 {size WW, HH} {position XX, YY}")

[Ethan M. <merritt@u.washington.edu>]

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

Re: set term screen

[Ethan M. <merritt@u.washington.edu>]

On Thursday 12 February 2009 15:28:06 Petr Mikulik wrote:
> > > I was thinking how to smoothly support x11, wxt, and others, in a portable 
> > > way. What about:
> > > 
> > > 	set term screen ... options ...
> > > or
> > > 	set term default ... options ...
> > > 
> > > There, the "screen" terminal is that after gnuplot's start-up, i.e. that in 
> > > GPVAL_TERM. Then, Octave (or others) won't have to care about
> > > 	set term x11
> > > 	set term win
> > > 	set term aqua
> > > etc.; it will just do
> > > 	set term screen|default|other_synonym


Let's go back to the beginning.
What exactly is the problem that is being solved?

At time of entry you get some default terminal.
If you want to force that before hand, you can either set GNUTERM
as an environmental variable, or you could invoke the program as
"gnuplot -e 'set term foo'"   or you could place a "set term"
command in ~/.gnuplot.

At this point the terminal that was selected on entry is stored in
GPVAL_TERM.  If you want to keep a copy, you can say SAVE_TERM = GPVAL_TERM.

At this point I lost the chain of argument.
What is it that you want to do with this saved terminal?
Something different from "set term push" ?

I think both "set term screen" and "set term current" 
are horribly confusing.  Why are they not no-ops?  



> > > Gnuplot will have to ensure that all "set term x11|wxt|qt|win|pm|aqua" 
> > > options are the same (or silently ignored if not relevant).
> > 
> > Don't we already have  "set termoption" for that?
> > It would have to be expanded to accept the size/position commands
> > (if they ever exist on these other terminals) but other than that
> > I think it does exactly what you want.  I have been thinking that
> > the termoption command could accept additional options anyhow.
> 
> I wonder which method is better. In your proposed case, the
> 	set termoption XXX
> would have to be identical to
> 	set terminal CURRENT XXX
> 
> I have just added a patch for the proposed
> 	set term screen XXX
> into sourceforge:
> https://sourceforge.net/tracker/index.php?func=detail&aid=2594217&group_id=2055&atid=302055
> 
> What is better? This:
> 	set term screen 2 title 'hello'
> or
> 	set termopt 2 title 'hello'
> ?
> 
> Maybe we could also add
> 	set term current XXX
> 
> 
> ---
> PM
> 



-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: GPVAL_TERM_VCHAR (was: problem with "set x11 {size WW,HH} {position XX,YY}")

[Ben A. <bpa...@ma...>]

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

Re: gnuplot windows term issue: point size

[Ethan M. <merritt@u.washington.edu>]

On Thursday 12 February 2009 13:27:58 Sebastian Pająk wrote:
> I don't get it. Why point size cannot be fixed? The line weight can be
> set and it is const. even when resizing window, but the size of the
> point is totally ignored!? 

I do not understand what you are saying.
In fact the line weight and the point size behave identically.
Both are arbitrary (line weight in terminal A may not match line weight
in terminal B).

> Points should be autoscaled or at least they should keep fixed size. 

Some terminals do autoscale the points.
Other terminals cannot scale them and so they remain a fixed size.
This is a limitation of not all output devices having the same
properties.

> In Gnuplot their size is impredictable. 
> Another win term bug?

Not a bug.  The point symbol sizes are arbitrary for all terminals.
In many cases gnuplot has no control over the size at all.
For instance, the older pen plotter and character cell devices
simply offer some fixed number of point symbols, and gnuplot
sends the command "use the third symbol, whatever it is".

That is why I suggested to use one of the newer options that do
indeed scale in a predictable way.
 

> 2009/2/12 Ethan Merritt <merritt@u.washington.edu>:
> > On Thursday 12 February 2009 12:33:16 Sebastian Pająk wrote:
> >> Hello
> >>
> >> When I resize manually plot window, all points in the plotting
> >> function become much bigger, even if I'm acctualy decreasing the size
> >> of the window. When I'm sizing window again the points remain with
> >> incorrect size. It can be seen in "test" window also. Is it a bug in
> >> windows terminal?
> >
> > The points are drawn at an arbitrary size, and you cannot expect
> > that size to be consistent across terminals.  Furthermore, the
> > size of the point itself is independent of the current size of the
> > canvas (I think, anyhow, it is possible that there are some terminal
> > types for which this is not true).
> >
> > There are two alternatives which give you more control over the
> > scaling of the plotting symbols, allowing the size to be on some
> > absolute scale relative to the plot axes or to the canvas size.
> >
> > 4.2 or 4.3:
> > Use "with labels" rather than "with points", and control the size
> > of the symbol by changing the font size.  An extreme example is
> > here:
> >    http://skuld.bmsc.washington.edu/people/merritt/gnuplot/index.html#variable_label_size
> >
> > 4.3 only:
> > Use "plot ... with circles", which allows you to give the radius of
> > each circle in either axis coordinates or absolute sizes.
> > Demo here:
> >    http://gnuplot.sourceforge.net/demo_4.3/circles.html
> >
> >
> > --
> > Ethan A Merritt
> >
> 
> ------------------------------------------------------------------------------
> 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
> 



-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: GPVAL_TERM_VCHAR (was: problem with "set x11 {size WW,HH} {position XX,YY}")

[Ben A. <bpa...@ma...>]

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

Re: set term screen

[Petr M. <mi...@ph...>]

> > I was thinking how to smoothly support x11, wxt, and others, in a portable 
> > way. What about:
> > 
> > 	set term screen ... options ...
> > or
> > 	set term default ... options ...
> > 
> > There, the "screen" terminal is that after gnuplot's start-up, i.e. that in 
> > GPVAL_TERM. Then, Octave (or others) won't have to care about
> > 	set term x11
> > 	set term win
> > 	set term aqua
> > etc.; it will just do
> > 	set term screen|default|other_synonym
> > 
> > Gnuplot will have to ensure that all "set term x11|wxt|qt|win|pm|aqua" 
> > options are the same (or silently ignored if not relevant).
> 
> Don't we already have  "set termoption" for that?
> It would have to be expanded to accept the size/position commands
> (if they ever exist on these other terminals) but other than that
> I think it does exactly what you want.  I have been thinking that
> the termoption command could accept additional options anyhow.

I wonder which method is better. In your proposed case, the
	set termoption XXX
would have to be identical to
	set terminal CURRENT XXX

I have just added a patch for the proposed
	set term screen XXX
into sourceforge:
https://sourceforge.net/tracker/index.php?func=detail&aid=2594217&group_id=2055&atid=302055

What is better? This:
	set term screen 2 title 'hello'
or
	set termopt 2 title 'hello'
?

Maybe we could also add
	set term current XXX


---
PM

Re: GPVAL_TERM_VCHAR (was: problem with "set x11 {size WW,HH} {position XX,YY}")

[Petr M. <mi...@ph...>]

> 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

Re: GPVAL_TERM_VCHAR (was: problem with "set x11 {size WW, HH} {position XX, YY}")

[Ethan M. <merritt@u.washington.edu>]

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

Re: GPVAL_TERM_VCHAR (was: problem with "set x11 {size WW,HH} {position XX,YY}")

[Ben A. <bpa...@ma...>]

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

Re: gnuplot windows term issue: point size

[Petr M. <mi...@ph...>]

> When I resize manually plot window, all points in the plotting
function become much bigger, even if I'm acctualy decreasing the size
of the window. When I'm sizing window again the points remain with
incorrect size. It can be seen in "test" window also. Is it a bug in
windows terminal?

Hit "e" hotkey or type "replot" to replot the window.

---
PM

Re: gnuplot windows term issue: point size

[Sebastian P. <spc...@gm...>]

I don't get it. Why point size cannot be fixed? The line weight can be
set and it is const. even when resizing window, but the size of the
point is totally ignored!? Points should be autoscaled or at least
they should keep fixed size. In Gnuplot their size is impredictable.
Another win term bug?


2009/2/12 Ethan Merritt <merritt@u.washington.edu>:
> On Thursday 12 February 2009 12:33:16 Sebastian Pająk wrote:
>> Hello
>>
>> When I resize manually plot window, all points in the plotting
>> function become much bigger, even if I'm acctualy decreasing the size
>> of the window. When I'm sizing window again the points remain with
>> incorrect size. It can be seen in "test" window also. Is it a bug in
>> windows terminal?
>
> The points are drawn at an arbitrary size, and you cannot expect
> that size to be consistent across terminals.  Furthermore, the
> size of the point itself is independent of the current size of the
> canvas (I think, anyhow, it is possible that there are some terminal
> types for which this is not true).
>
> There are two alternatives which give you more control over the
> scaling of the plotting symbols, allowing the size to be on some
> absolute scale relative to the plot axes or to the canvas size.
>
> 4.2 or 4.3:
> Use "with labels" rather than "with points", and control the size
> of the symbol by changing the font size.  An extreme example is
> here:
>    http://skuld.bmsc.washington.edu/people/merritt/gnuplot/index.html#variable_label_size
>
> 4.3 only:
> Use "plot ... with circles", which allows you to give the radius of
> each circle in either axis coordinates or absolute sizes.
> Demo here:
>    http://gnuplot.sourceforge.net/demo_4.3/circles.html
>
>
> --
> Ethan A Merritt
>

Re: gnuplot win32 problem: proportional log scale

[Sebastian P. <spc...@gm...>]

2009/2/12 Ethan Merritt <merritt@u.washington.edu>:
> On Thursday 12 February 2009 12:29:44 Sebastian Pająk wrote:
>> Hello
>>
>> I've made a 2D plot with "set logscale xy" and "set size ratio -1". In
>> windows terminal I can see that decades in the Y axis aren't the same
>> size, also they are wider than the decades in Y axis (not much, about
>> 5%-6%). This problem doesn't exists in different terminals like png or
>> emf. What can be the problem?
>
> "set size ratio"  does not work correctly for all terminals.
> I don't know about the windows terminal specifically.
> Possibly if you adjust the window first so that it is square,
> the aspect ratio will become [more] correct.
>

I don't want graph to be square. I want it to have equal lenght of
decades on both axes, it not always mean square. Resizing window by
hand to have equal decades is impossible.

So this is a bug in win term... hmmm

> --
> Ethan A Merritt
>

Re: gnuplot win32 problem: proportional log scale

[Ethan M. <merritt@u.washington.edu>]

On Thursday 12 February 2009 12:29:44 Sebastian Pająk wrote:
> Hello
> 
> I've made a 2D plot with "set logscale xy" and "set size ratio -1". In
> windows terminal I can see that decades in the Y axis aren't the same
> size, also they are wider than the decades in Y axis (not much, about
> 5%-6%). This problem doesn't exists in different terminals like png or
> emf. What can be the problem?

"set size ratio"  does not work correctly for all terminals.
I don't know about the windows terminal specifically.
Possibly if you adjust the window first so that it is square,
the aspect ratio will become [more] correct.

-- 
Ethan A Merritt

Re: gnuplot windows term issue: point size

[Ethan M. <merritt@u.washington.edu>]

On Thursday 12 February 2009 12:33:16 Sebastian Pająk wrote:
> Hello
> 
> When I resize manually plot window, all points in the plotting
> function become much bigger, even if I'm acctualy decreasing the size
> of the window. When I'm sizing window again the points remain with
> incorrect size. It can be seen in "test" window also. Is it a bug in
> windows terminal?

The points are drawn at an arbitrary size, and you cannot expect
that size to be consistent across terminals.  Furthermore, the
size of the point itself is independent of the current size of the
canvas (I think, anyhow, it is possible that there are some terminal
types for which this is not true).

There are two alternatives which give you more control over the
scaling of the plotting symbols, allowing the size to be on some
absolute scale relative to the plot axes or to the canvas size.

4.2 or 4.3:
Use "with labels" rather than "with points", and control the size
of the symbol by changing the font size.  An extreme example is
here:
    http://skuld.bmsc.washington.edu/people/merritt/gnuplot/index.html#variable_label_size

4.3 only:
Use "plot ... with circles", which allows you to give the radius of
each circle in either axis coordinates or absolute sizes.
Demo here:
    http://gnuplot.sourceforge.net/demo_4.3/circles.html


-- 
Ethan A Merritt

gnuplot windows term issue: point size

[Sebastian P. <spc...@gm...>]

Hello

When I resize manually plot window, all points in the plotting
function become much bigger, even if I'm acctualy decreasing the size
of the window. When I'm sizing window again the points remain with
incorrect size. It can be seen in "test" window also. Is it a bug in
windows terminal?

Here is what the "effect": http://bayimg.com/BaNLhAabI

sys: Windows xp pro sp3
gnuplot: svn

Sebastian Pająk

gnuplot windows & png term issue: font

[Sebastian P. <spc...@gm...>]

Hello

I have two problems related to fonts in gnuplot:

1. How can I change font family in the command for win terminal?

I've tried:
set term windows font "Courier New" 12
set term windows font "Courier" 12
set term windows font "cour" 12
set term windows font "cour.ttf" 12
set term windows font "C:/WINDOWS/Fonts/cour.ttf" 12

but none from above works (but 1st command works for emf term..
strange). Gnuplot says font is changed but when I replot I still have
default font (probably Arial or similar)

2. How can I set encoding in png terminal to see polish letters like
"ą" "ę" "ś" etc.

I've tried:
set encoding utf8
set encoding cp1250

there is no effect, I see only strange signs instead of letters

Sebastian Pająk

gnuplot win32 problem: proportional log scale

[Sebastian P. <spc...@gm...>]

Hello

I've made a 2D plot with "set logscale xy" and "set size ratio -1". In
windows terminal I can see that decades in the Y axis aren't the same
size, also they are wider than the decades in Y axis (not much, about
5%-6%). This problem doesn't exists in different terminals like png or
emf. What can be the problem?

Sebastian

Re: GPVAL_TERM_VCHAR (was: problem with "set x11 {size WW, HH} {position XX, YY}")

[Ethan M. <merritt@u.washington.edu>]

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.

 
> >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 don't think it would be visible to the user or to user scripts, except
that it would result in improved behaviour of the "set size ratio ..." and
"set view equal xy..." commands.


> 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
> 


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: GPVAL_TERM_VCHAR (was: problem with "set x11 {size WW,HH} {position XX,YY}")

[Ben A. <bpa...@ma...>]

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