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

[m s. <mw...@us...>]

> ----- Original Message -----
> 
> Message: 1
> Date: Fri, 13 Feb 2009 11:42:38 -0500
> From: Ben Abbott <bpa...@ma...>
> Subject: Re: GPVAL_TERM_VCHAR (was: problem with "set x11 {size WW,HH}
> 	{position XX,YY}")
> To: Ethan A Merritt <merritt@u.washington.edu>
> Cc: gnu...@li..., Petr Mikulik
> 	<mi...@ph...>
> Message-ID: <111...@me...>
> Content-Type: text/plain; charset=UTF-8
> 
   <deleted>
> 
> 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,

I don't see why not.  I created the position and size patch to put windows of a specific size at a specific location.   Multiplot was not giving the desired behavior.   For the stuff I do, the user puts in some data and out comes a plot.  They don't even know that Gnuplot is being used and probably don't care.

my $0.02,

Mike Sutton



-- 
Be Yourself @ mail.com!
Choose From 200+ Email Addresses
Get a Free Account at www.mail.com

segfault in plot3d

[James R. V. Z. <jr...@co...>]

I ran across a reliable segfault with the splot command, with the
current CVS code:

        G N U P L O T
        Version 4.3 patchlevel 0
        last modified February 2009

In particular, this is *without* my proposed changes to fit.c

Here's a run under the debugger:

gnuplot> splot 'lin2.dat',x+y
[New Thread 0xb7843a40 (LWP 27810)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7843a40 (LWP 27810)]
calculate_set_of_isolines (value_axis=FIRST_Z_AXIS, cross=false, this_iso=0xbffb32e0, iso_axis=FIRST_Y_AXIS, iso_min=2, iso_step=0.33333333333333331, num_iso_to_use=10, sam_axis=FIRST_X_AXIS, sam_min=1, sam_step=0.030303030303030304, num_sam_to_use=100, need_palette=false) at plot3d.c:1174
(gdb) backtrace
#0  calculate_set_of_isolines (value_axis=FIRST_Z_AXIS, cross=false, this_iso=0xbffb32e0, iso_axis=FIRST_Y_AXIS, iso_min=2, iso_step=0.33333333333333331, num_iso_to_use=10, sam_axis=FIRST_X_AXIS, sam_min=1, sam_step=0.030303030303030304, num_sam_to_use=100, need_palette=false) at plot3d.c:1174
#1  0x080a808c in plot3drequest () at plot3d.c:1909
#2  0x080571d7 in do_line () at command.c:595
#3  0x0805796d in com_line () at command.c:338
#4  0x0809a6dd in main (argc=1, argv=0xbffb35a4) at plot.c:659
(gdb) 

Here's lin2.dat:
---------------------------------------------
#octave:9> for x=[1:4];for y=[2:5]; fprintf('%f %f %f 1\n',x,y,10*x+2*y+randn);end;end
1.000000 2.000000 13.753875 1
1.000000 3.000000 15.843192 1
1.000000 4.000000 17.752269 1
1.000000 5.000000 18.819627 1


2.000000 2.000000 25.480149 1
2.000000 3.000000 26.217588 1
2.000000 4.000000 28.555638 1
2.000000 5.000000 30.757950 1


3.000000 2.000000 33.879955 1
3.000000 3.000000 36.190724 1
3.000000 4.000000 39.199289 1
3.000000 5.000000 40.153219 1


4.000000 2.000000 43.413695 1
4.000000 3.000000 45.938903 1
4.000000 4.000000 49.196757 1
4.000000 5.000000 50.136290 1
#octave:10> diary off
-----------------------------------------


All these commands work fine:

   gnuplot> splot 'fit2.dat'
   gnuplot> splot x+y
   gnuplot> splot x+y,'fit2.dat'

It only fails when plotting the data file first, then the function.
I've had other data files fail, but demo/glasses.dat succeeds.

I set a breakpoint at plot3d.c:1174 in calculate_set_of_isolines() and
followed execution.  When j=0 and i=99, the function reaches end of
the linked list, sets this_iso to zero, then sets points to zero.  The
next time through when j=1 and i=0, the function dies trying to access
points[i].x.  I haven't been able to identify the cause.

I have a couple of other binaries installed.
This version also crashes:
        G N U P L O T
        Version 4.3 patchlevel 0
        last modified January 2007

This version is okay:
        G N U P L O T
        Version 4.2 patchlevel 4 
        last modified Sep 2008


Does anyone else see this?

     - Jim Van Zandt

screendump under Windows

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

Wgnuplot contains button "Print" which executes "screendump" command. This 
command prints the graph by a normal print dialog. I've got a bug report 
that it does not work in colors. I've tried it also, using "Adobe Generic 
Postscript Driver" and "CutePDF" drivers, and the plots are always "almost 
colour" -- for example, in the "test" page: only the polygon is blue and one 
arrow is red. Can somebody test it? How to fix it?

---
PM

Re: set term screen

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

On Monday 16 February 2009, Petr Mikulik wrote:
> > > 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
> > 
> > 	set macros
> > 	screen = GPVAL_TERM
> > 	...
> > 	set term @screen title 'hello'
> > 	set term @screen 4
> > 	set term @screen 5 size 400,400
> 
> Good idea. That's actually the solution working in both gnuplot 4.2 and 4.3.
> 
> > Another possibility is to have the "set term" command accept
> > the terminal name as a string.  
> > 	screen = "x11"
> > 	set term screen 5 size 400,400
> 
> Cool, your patch (committed to cvs) works fine.
> However, I think that the keyword should have preference, not string 
> variables:
> 
> gnuplot> gif='figure.gif'
> gnuplot> set out gif
> gnuplot> set term gif
>                   ^
>      unknown or ambiguous terminal type; type just 'set terminal' for a list

OK.  Done.

> or with "po" variable (abbreviation of "postscript").

The string is passed to exactly the same routine for checking against
the list of terminal names.  The rules for matching are the same as they
have always been.

> I think it may be useful to define
> 	GPVAL_TERM_DEFAULT
> to the default startup terminal name, i.e. the same as the default "pushed" 
> terminal. Then we will have e.g.
>         GNUTERM = "wxt"
>         GPVAL_TERM_DEFAULT = "x11"
>         GPVAL_TERM = "postscript"
 
> Then, external programs (Octave) could use either
> 	set macros; screen=GPVAL_TERM
> 	set term @screen ...options...
> on 4.2 or
> 	set term GPVAL_TERM_DEFAULT ...options...
> on 4.3.

By the way, the use of macros is nice for another reason:
Suppose you set the environmental variable GNUTERM to
   setenv GNUTERM "post eps color solid size 5in, 3in"

When you enter gnuplot, the terminal will just be "post".
But if you immediately say
   set macros
   set term @GNUTERM
then you will get all of the requested terminal properties also.
This can be quite nice for scripting.


-- 
Ethan A Merritt

Re: GPVAL_TERM_WINDOWID under wxt (and qt)

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

> > The GPVAL_TERM_WINDOWID works now OK under X11 terminal. It would be nice to 
> > add this functionality under wx terminal (and qt) as well.
> > 
> > Under wxt, I think it is just needed to update
> > 	gp_exec_event(GE_plotdone, 0, 0, 0, 0, windowid);
> > with the windoid being the actual x11 window id, not a "local" number.
> > 
> > Could somebody provide a patch?
> 
> But neither wxt not qt is necessarily running on top of x11, right?
> So there may not be any x11 window id.

Yes, then it won't be X11 ID.

---
PM

Re: set term screen

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

> > 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
> 
> 	set macros
> 	screen = GPVAL_TERM
> 	...
> 	set term @screen title 'hello'
> 	set term @screen 4
> 	set term @screen 5 size 400,400

Good idea. That's actually the solution working in both gnuplot 4.2 and 4.3.

> Another possibility is to have the "set term" command accept
> the terminal name as a string.  
> 	screen = "x11"
> 	set term screen 5 size 400,400

Cool, your patch (committed to cvs) works fine.
However, I think that the keyword should have preference, not string 
variables:

gnuplot> gif='figure.gif'
gnuplot> set out gif
gnuplot> set term gif
                  ^
     unknown or ambiguous terminal type; type just 'set terminal' for a list

or with "po" variable (abbreviation of "postscript").

***

I think it may be useful to define
	GPVAL_TERM_DEFAULT
to the default startup terminal name, i.e. the same as the default "pushed" 
terminal. Then we will have e.g.
        GNUTERM = "wxt"
        GPVAL_TERM_DEFAULT = "x11"
        GPVAL_TERM = "postscript"

Then, external programs (Octave) could use either
	set macros; screen=GPVAL_TERM
	set term @screen ...options...
on 4.2 or
	set term GPVAL_TERM_DEFAULT ...options...
on 4.3.


---
PM

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

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

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

Re: GPVAL_TERM_WINDOWID under wxt (and qt)

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

On Sunday 15 February 2009, Petr Mikulik wrote:
> The GPVAL_TERM_WINDOWID works now OK under X11 terminal. It would be nice to 
> add this functionality under wx terminal (and qt) as well.
> 
> Under wxt, I think it is just needed to update
> 	gp_exec_event(GE_plotdone, 0, 0, 0, 0, windowid);
> with the windoid being the actual x11 window id, not a "local" number.
> 
> Could somebody provide a patch?

But neither wxt not qt is necessarily running on top of x11, right?
So there may not be any x11 window id.

-- 
Ethan A Merritt

GPVAL_TERM_WINDOWID under wxt (and qt)

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

The GPVAL_TERM_WINDOWID works now OK under X11 terminal. It would be nice to 
add this functionality under wx terminal (and qt) as well.

Under wxt, I think it is just needed to update
	gp_exec_event(GE_plotdone, 0, 0, 0, 0, windowid);
with the windoid being the actual x11 window id, not a "local" number.

Could somebody provide a patch?

---
PM

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

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

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

Re: fitting functions with more independent variables

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

On Friday 13 February 2009, James R. Van Zandt wrote:

>   Though this code allows up to five independent variables, I would
>   really rather there was no fixed limit.  There are at least a couple
>   of challenges in removing the limit:
> 
>   - df_readascii is set up to read a maximum of seven columns.

That isn't quite true.  The limit comes from the number of slots in each
point's data structure.  df_readascii itself is quite happy to read from
as many columns as you like.  It just cannot store all of them into the
data structure belonging to a single point.  There are already several 
plot styles or input modes that involve reading more data than fits into
7 slots.  Plot "with vectors", for example, allocates two data structures
for each point so that it can store values for each end of the vector.
And the 'matrix' keyword allows reading an unlimited number of values
per line (at least so far as I know).  But I don't know if either of these
is a useful model for what you want to do.

	Ethan


>   - For an arbitrary number of variables, we would also need a set of
>     dummy variable names that can be extended.  For example:
>   
>          z
>          x:z
>          x:z:s
>          x:y:z:s
>          x:y:t1:z:s
>          x:y:t1:t2:z:s
>          x:y:t1:t2:t3:z:s
>          x:y:t1:t2:t3:t4:z:s
>          ...
>   
>   This would be incompatible with the names I have used. 
>   
>   Or, we could decide that any user who wants more than five independent
>   variables would have to supply their own dummy variable names in range
>   specs.
> 
> I noticed Z ranges were implemented in the code, but were not
> documented or reported in the log file.  The log file reported "using"
> specs and the fit function.  Also, if some range spec changed a dummy
> variable name, the new name was not reported, making it hard to
> interpret the reported range and fit function.  I have fixed those
> bugs.
> 
> Every now and then while fitting, I have gotten an error message "No
> data to fit" which brings me up short.  So while I was working in the
> area, I expanded the report like this:
> 
>   fit [-4:4][yaks=-2:2][4:4][0:22]  a*x+b*yaks+c*t 'lin3.dat' u 1:2:3:4:5 via a,b,c
>        Read 64 points
>        Skipped 32 points outside range [x=-4:4]
>        Skipped 24 points outside range [yaks=-2:2]
>        Skipped 6 points outside range [t=4:4]
>        Skipped 2 points outside range [z=0:22]
>        No data to fit 
> 
> (If there are points to fit, nothing new is printed.)
> 
> So, let me know what you think.
> 
>            - Jim Van Zandt

-- 
Ethan A Merritt

Re: fitting functions with more independent variables

[James R. V. Z. <jr...@co...>]

  
My new fitting code is working.

I had proposed these formats:

>>>       v:x:y:z:s
>>>       u:v:x:y:z:s
>>>       t:u:v:x:y:z:s

Peter and Ethan objected to the ordering.  I eventually changed my
mind, deciding the following set of formats was easier to implement,
to explain, and to remember:

       z
       x:z
       x:z:s
       x:y:z:s
       x:y:t:z:s
       x:y:t:u:z:s
       x:y:t:u:v:z:s

If you have three or more using specs, then the last one is for
standard deviation, the next to last is for Z values (dependent
variable), and all the preceding ones are for independent variables.
And the first two dummy variables are always 'x' and 'y'.

Here are some examples:

  fit a*x + b*y + c*t 'foo.dat' using 1:2:3:4:(1) via a,b,c
  h(x,y,t,u,v) = a*x + b*y + c*t + d*u + e*v
  fit h(x,y,t,u,v) 'foo.dat' using 1:2:3:4:5:6:(1) via a,b,c,d,e

You can also use ranges, including those that change the dummy
variable names:

  g(x,yaks,tulips) = a*x+b*yaks+c*tulips
  fit [*:9][yaks=*:*][tulips=*:*] g(x,yaks,tulips) 'surface.dat' u 1:2:3:(1) via a,b,c


I have uploaded a patch and a set of data files and demo scripts here:

       http://jrv.oddones.org/fit-patch
       http://jrv.oddones.org/fit-demo.tar.gz

The only code I touched was in fit.c.  However, it involved a lot of
things I have not worked with before, so I would rather other
developers would check out the patch before I commit the changes.

For example:
  
  I'm using the T, U, and V axes to store range information.  Are there
  side effects?  Would it be better to set those entries in df_axis to
  NO_AXIS and store range information separately?
  
  You can still do a one- or two-variable fit with a function using
  "t" as a regular user-defined variable.  However, if your fit
  function includes "t" but you haven't defined it, you don't get an
  "undefined variable" error.  That's because while gnuplot is parsing
  the expression, it assumes "t" is an independent variable, and
  doesn't discover differently until later.  How can this be fixed?
  
  I don't think there are any new memory leaks.  Is there a way to
  automatically check for leaks?

  I think any of the new columns can have time formats.  However, I
  don't use time data myself, and haven't tested it.
  
  Though this code allows up to five independent variables, I would
  really rather there was no fixed limit.  There are at least a couple
  of challenges in removing the limit:

  - df_readascii is set up to read a maximum of seven columns.
  - For an arbitrary number of variables, we would also need a set of
    dummy variable names that can be extended.  For example:
  
         z
         x:z
         x:z:s
         x:y:z:s
         x:y:t1:z:s
         x:y:t1:t2:z:s
         x:y:t1:t2:t3:z:s
         x:y:t1:t2:t3:t4:z:s
         ...
  
  This would be incompatible with the names I have used. 
  
  Or, we could decide that any user who wants more than five independent
  variables would have to supply their own dummy variable names in range
  specs.

I noticed Z ranges were implemented in the code, but were not
documented or reported in the log file.  The log file reported "using"
specs and the fit function.  Also, if some range spec changed a dummy
variable name, the new name was not reported, making it hard to
interpret the reported range and fit function.  I have fixed those
bugs.

Every now and then while fitting, I have gotten an error message "No
data to fit" which brings me up short.  So while I was working in the
area, I expanded the report like this:

  fit [-4:4][yaks=-2:2][4:4][0:22]  a*x+b*yaks+c*t 'lin3.dat' u 1:2:3:4:5 via a,b,c
       Read 64 points
       Skipped 32 points outside range [x=-4:4]
       Skipped 24 points outside range [yaks=-2:2]
       Skipped 6 points outside range [t=4:4]
       Skipped 2 points outside range [z=0:22]
       No data to fit 

(If there are points to fit, nothing new is printed.)

So, let me know what you think.

           - Jim Van Zandt

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

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

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

Re: set term screen

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

On Friday 13 February 2009 01:16:28 Petr Mikulik wrote:

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

Thank you.  That clarifies the goal.

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

Well, you can do better than that:

	set macros
	screen = GPVAL_TERM
	...
	set term @screen title 'hello'
	set term @screen 4
	set term @screen 5 size 400,400

Another possibility is to have the "set term" command accept
the terminal name as a string.  
	screen = "x11"
	set term screen 5 size 400,400

See attached patch.


-- 
Ethan A Merritt

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

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

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

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

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

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

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

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

On Friday, February 13, 2009, at 01:13PM, "Ethan Merritt" <merritt@u.washington.edu> wrote:
>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? 

For Octave's purposes, the canvas would be normalized to unit width and length.

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

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

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

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

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

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

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

[Ralf J. <jue...@cs...>]

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
>

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

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

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

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

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

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

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

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

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

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

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

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

Re: GPVAL_TERM_VCHAR

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

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