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

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

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

On Thursday, February 12, 2009, at 09:10AM, "Petr Mikulik" <mi...@ph...> wrote:
>> >We all agreed here that Octave should pass these positions to gnuplot only
>> >if they were really changed by user.
>> >
>> >But I wonder how to achieve this...
>> > plot(1:10)
>> > f=gca
>> > set(f, 'position', [1 1 300 300])
>> >
>> >=> crazy plot appears. According to log by "drawnow()", Octave is asking for
>> > set origin 1, 1;
>> > set size 300, 300;
>> >instead of changing numbers in "set term x11 .... size ... position ...".
>> >So, how do you actually change the position of x11 windows?
>> 
>> Do I infer correctly that you expect "set origin" and 'set size" to change the
>> position and size of the window? If my understanding is correct, that use to
>> be the case for *some* canvases, but no longer does that.  For version 4.3,
>> "set origin" and "set size" are used to position each plot on the canvas.
>
>I see a big misunderstanding here. In gnuplot, commands
>	set size x,y    # 0<x<1, 0<y<1
>	set origin x,y  # 0<=x<1, 0<=y<1
>change the plot size inside the drawing canves. This can be changed in 
>Matlab:
>	plot(1:10)
>	set(gca, 'position', [0.25 0.25 0.5 0.5])
>Therefore, in Octave, command
>	set(gca, 'position', [0.25 0.25 0.5 0.5])
>should change the values for "set size ...; set origin" (whatever is the 
>terminal).
>
>Command
>	set term x11 size W,H position X,Y
>where W,H,X,Y are up to screen resolution (e.g. 768, 1024, etc.) ask to 
>position the X11 window (=canvas) somewhere on the monitor). However, 
>I cannot see any "get(gca)" option to change the window position on the 
>screen. Which one is it? If this is available, then it is what should go to
>"set term x11 size position".

The property you're looking for is on the figure.

get (gcf, 'position')

>> >Further,
>> >	set(f, 'tickdir', 'out')
>> >works OK but
>> >	set(f, 'ticklength', [10 10])
>> >is ignored. Can you please fix it?
>> 
>> I'm happy to patch octave's sources if you can tell me what gnuplot commands
>> are needed to change the ticklength.
>
>This is e.g.
>	set xtics scale 8
>

Thanks. I'll put that on my list of to-do's.

Ben

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

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

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?  

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.  

-- 
Ethan A Merritt

Re: set term screen

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

On Thursday 12 February 2009, Petr Mikulik wrote:
> > Anyhow, what if the end user wants to use some terminal type other
> > than x11?
> 
> 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).
> 
> What do you think about it?

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.



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

set term screen

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

> Anyhow, what if the end user wants to use some terminal type other
> than x11?

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

What do you think about it?

---
PM

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

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

> >We all agreed here that Octave should pass these positions to gnuplot only
> >if they were really changed by user.
> >
> >But I wonder how to achieve this...
> > plot(1:10)
> > f=gca
> > set(f, 'position', [1 1 300 300])
> >
> >=> crazy plot appears. According to log by "drawnow()", Octave is asking for
> > set origin 1, 1;
> > set size 300, 300;
> >instead of changing numbers in "set term x11 .... size ... position ...".
> >So, how do you actually change the position of x11 windows?
> 
> Do I infer correctly that you expect "set origin" and 'set size" to change the
> position and size of the window? If my understanding is correct, that use to
> be the case for *some* canvases, but no longer does that.  For version 4.3,
> "set origin" and "set size" are used to position each plot on the canvas.

I see a big misunderstanding here. In gnuplot, commands
	set size x,y    # 0<x<1, 0<y<1
	set origin x,y  # 0<=x<1, 0<=y<1
change the plot size inside the drawing canves. This can be changed in 
Matlab:
	plot(1:10)
	set(gca, 'position', [0.25 0.25 0.5 0.5])
Therefore, in Octave, command
	set(gca, 'position', [0.25 0.25 0.5 0.5])
should change the values for "set size ...; set origin" (whatever is the 
terminal).

Command
	set term x11 size W,H position X,Y
where W,H,X,Y are up to screen resolution (e.g. 768, 1024, etc.) ask to 
position the X11 window (=canvas) somewhere on the monitor). However, 
I cannot see any "get(gca)" option to change the window position on the 
screen. Which one is it? If this is available, then it is what should go to
"set term x11 size position".


> >Further,
> >	set(f, 'tickdir', 'out')
> >works OK but
> >	set(f, 'ticklength', [10 10])
> >is ignored. Can you please fix it?
> 
> I'm happy to patch octave's sources if you can tell me what gnuplot commands
> are needed to change the ticklength.

This is e.g.
	set xtics scale 8


BTW, comparing to Matlab, it seems the the mesh() command in Octave 
would like the following:
	set grid
        set xtics out nomirror scale 1.5
        set ytics out nomirror scale 1.5
        set ztics out scale 1.5


---
PM

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

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

On Feb 12, 2009, at 2:28 AM, Petr Mikulik wrote:

>> Control over window size and position via its scripting language is  
>> something
>> Matlab does. Compatibility with Matlab is a goal for Octave. Of  
>> course, there
>> user controls the scripting language, so there should be no  
>> surprises for the
>> user. In the event a script places a window and the user then moves  
>> it (via
>> the mouse), the window is intended to stay where the mouse placed  
>> it (unless
>> the user moves it again by using the mouse or a script).
>>
>> The properties all have defaults, which may be modified via  
>> Octave's scripting
>> language. The size and position of the figure are special in that  
>> they may be
>> modified by either the scripting language of the mouse.
>
> I think it is very useful to have the option in Octave to position the
> window at an explicit position. In one my application, I draw 4  
> images on
> screen. I would really wish they are created on screen always at the  
> same
> position (and in the same order), so that I'm not confused. Window  
> manager
> would put them automatically ("randomly") at positions where he  
> thinks there
> is enough space.
>
> We all agreed here that Octave should pass these positions to  
> gnuplot only
> if they were really changed by user.
>
> But I wonder how to achieve this...
> 	plot(1:10)
> 	f=gca
> 	set(f, 'position', [1 1 300 300])
>
> => crazy plot appears. According to log by "drawnow()", Octave is  
> asking for
> 	set origin 1, 1;
> 	set size 300, 300;
> instead of changing numbers in "set term x11 .... size ...  
> position ...".
> So, how do you actually change the position of x11 windows?

Do I infer correctly that you expect "set origin" and 'set size" to  
change the position and size of the window? If my understanding is  
correct, that use to be the case for *some* canvases, but no longer  
does that.  For version 4.3,  "set origin" and "set size" are used to  
position each plot on the canvas.

For compatibility with Matlab,  and for 2D plots, Octave will likely  
use the "set bmargin/lmargin/rmargin/tmargin" commmands, as these give  
explicit control of the axes (i.e. plot area sans the tick labels and  
axes labels).

> Further,
> 	set(f, 'tickdir', 'out')
> works OK but
> 	set(f, 'ticklength', [10 10])
> is ignored. Can you please fix it?

I'm happy to patch octave's sources if you can tell me what gnuplot  
commands are needed to change the ticklength.

> Also, Matlab uses capitalization, e.g.
> 	TickDir
> which looks better readable in "get(f)" compared to Octave's  
> minuscules.

This is deliberate. Avoiding CamelCase is part of Octave's coding  
standard. However, the property names are case-insensitive in both  
Octave and Matlab. If compatibility were not important, the property  
names would have been "tick_dir".

Ben

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

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

On Jan 29, 2009, at 4:13 PM, Ethan Merritt wrote:

> On Thursday 29 January 2009 12:32:29 Ben Abbott wrote:
>>
>> On Dec 29, 2008, at 12:15 AM, Ethan A Merritt wrote:
>>
>>> On Sunday 28 December 2008, Ben Abbott wrote:
>>>>
>>>> On Dec 28, 2008, at 9:10 PM, Ethan A Merritt wrote:
>>>>
>>>>> On Sunday 28 December 2008, Ben Abbott wrote:
>>>>>
>>>>
>>>>>> *SNIP*
>>>>>> By the way, it would really be cool if there was a method by  
>>>>>> which
>>>>>> the
>>>>>> size and position of a plot window could be determined. That way
>>>>>> if a
>>>>>> user moves or resizes a window Octave could do some checking and
>>>>>> have
>>>>>> some awareness of such (I'd be stunned if such were possible, but
>>>>>> thought I'd ask).
>>>>>
>>>>> You can do that with a call into xlib; you don't need any special
>>>>> code in gnuplot for that.  You should be able to get all the info
>>>>> you'd get from the command line using "xwininfo"
>>>>
>>>> hmmm ... that may be quite useful.
>>>>
>>>> xwininfo: Window id: 0xc00008 "Figure 1"
>>>>
>>>>  Absolute upper-left X:  440
>>>>  Absolute upper-left Y:  128
>>>>  Relative upper-left X:  0
>>>>  Relative upper-left Y:  22
>>>>  Width: 560
>>>>  Height: 493
>>>>  Depth: 24
>>>>  Visual Class: TrueColor
>>>>  Border width: 0
>>>>  Class: InputOutput
>>>>  Colormap: 0x21 (installed)
>>>>  Bit Gravity State: ForgetGravity
>>>>  Window Gravity State: NorthWestGravity
>>>>  Backing Store State: NotUseful
>>>>  Save Under State: no
>>>>  Map State: IsViewable
>>>>  Override Redirect State: no
>>>>  Corners:  +440+128  -440+128  -440-279  +440-279
>>>>  -geometry 560x493+440+106
>>>>
>>>> Unfortunately, the height includes the portion needed to display  
>>>> the
>>>> cursor's coordinates ... sigh :-(
>>>
>>> That extra height is equal to term->v_char.  This quantity is not
>>> currently exported as a user variable, but it would be trivial to do
>>> so.
>>> Do you want it?  Its name would be GPVAL_TERM_VCHAR.
>>
>> I'm back hoping to better understand what is needed to determine the
>> position of a specific gnuplot x11 window. I can see how xwininfo can
>> be used, but how do I determine the window id (0xc00008 in the
>> instance above)? Would it be necessary to patch gnuplot?
>
> The usual way is to make successive requests to the window mananger
> asking it to step through all the current windows on the display,
> and check each one to see if it is the one you want.  That does not
> require any cooperation or modification of the program that created
> the window in the first place.
>
> It would also be possible to modify gnuplot_x11 so that it reports
> back the id of each new plot window that it opens.  The would involve
> modifying gplt_x11.c,  mouse.c, and perhaps x11.trm, but I think it
> would not be difficult.
>
>> Regarding the proposed GPVAL_TERM_VCHAR, how would be be accessed?
>
> It would be just like any of the other internally-maintained  
> variables.
> The two obvious ones are
>
>   show GPVAL_TERM_VCHAR
> or
>   set print "my/named/pipe/or/other/file"
>   print "term->char =", GPVAL_TERM_VCHAR
>   unset print

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.

TiA
Ben

Re: makefile.mgw : name of c complier for pgnuplot

[Tatsuro M. <tma...@ya...>]

Hello

--- Petr Mikulik wrote:

> Why are the advantages of this "Dragon" MinGW fork compared to MinGW? I 
> couldn't find this info on its web.

I do not know in details. However, Benjamin Linder uses this gcc-4.3.0-TDM for octave-mingw.
The candidate release of gcc-4.3.0 on MINGW includes some mispackaging so that manual corrections are
required to use.
http://www.nabble.com/Re%3A-Octave---Fortran-continued-p21222084.html
http://www.nabble.com/Re%3A-Octave---Fortran-continued-p21249982.html

For my experience on cygwin, the gcc-4.3.2 is better than gcc-4.3.0.
(My own build)
So that I thought that gcc-4.3.2 is better to use. 

The latest candidate release of mingw in the official site is still gcc-4.3.0.
However, the latest release of TDM is gcc-4.4.0-sjlj.

>From my experience, the binaries built by gcc-4.3.2-TDM are faster than those of gcc-4.3.0 even the
same optimizing option.  In addtion,  gcc-4.3.2-TDM produces more stable binaries than those prodeced
by gcc-4.3.0-TDM.

All I told from my experiences. I do not know any technical reasons.

Regards

Tatsuro   

--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

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

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

> Control over window size and position via its scripting language is something
> Matlab does. Compatibility with Matlab is a goal for Octave. Of course, there
> user controls the scripting language, so there should be no surprises for the
> user. In the event a script places a window and the user then moves it (via
> the mouse), the window is intended to stay where the mouse placed it (unless
> the user moves it again by using the mouse or a script).
> 
> The properties all have defaults, which may be modified via Octave's scripting
> language. The size and position of the figure are special in that they may be
> modified by either the scripting language of the mouse.

I think it is very useful to have the option in Octave to position the 
window at an explicit position. In one my application, I draw 4 images on 
screen. I would really wish they are created on screen always at the same 
position (and in the same order), so that I'm not confused. Window manager 
would put them automatically ("randomly") at positions where he thinks there 
is enough space.

We all agreed here that Octave should pass these positions to gnuplot only 
if they were really changed by user.

But I wonder how to achieve this...
	plot(1:10)
	f=gca
	set(f, 'position', [1 1 300 300])

=> crazy plot appears. According to log by "drawnow()", Octave is asking for
	set origin 1, 1;
	set size 300, 300;
instead of changing numbers in "set term x11 .... size ... position ...".
So, how do you actually change the position of x11 windows?

Further,
	set(f, 'tickdir', 'out') 
works OK but 
	set(f, 'ticklength', [10 10])
is ignored. Can you please fix it?

Also, Matlab uses capitalization, e.g.
	TickDir
which looks better readable in "get(f)" compared to Octave's minuscules.

---
PM

Re: makefile.mgw : name of c complier for pgnuplot

[Tatsuro M. <tma...@ya...>]

Hello Petr

I have confirmed your fix on cvs trees.

Thanks!!

Tatsuro

--- Tatsuro MATSUOKAwrote:

> Hello
> 
> In makefile.mgw, it is found that
> $(PGNUPLOT): win/pgnuplot.c version.o
> 	gcc -O2 -DHAVE_STDBOOL_H -s -o $@ win/pgnuplot.c version.o -I. -luser32
> 
> However, gcc is not always name of compiler of GCC on mingw at present.  For GCC-4.3.3-dw2-TDM
> mingw,
> the name of c complier is gcc-dw2 but not gcc.
> 
> I think that it should be
> 
> $(PGNUPLOT): win/pgnuplot.c version.o
> 	$(CC) -O2 -DHAVE_STDBOOL_H -s -o $@ win/pgnuplot.c version.o -I. -luser32
> 
> Regards
> 
> Tatsuro
> 
> 
> 
> 
> --------------------------------------
> Power up the Internet with Yahoo! Toolbar.
> http://pr.mail.yahoo.co.jp/toolbar/
> 


--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

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

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

On Wednesday 11 February 2009 17:26:00 Ben Abbott wrote:
> On Feb 11, 2009, at 6:56 PM, Ethan Merritt wrote:
> 
> > On Wednesday 11 February 2009 15:30:30 Petr Mikulik wrote:
> >
> >>> In any event, I'd prefer that gnuplot allow an existing window be  
> >>> resized
> >>> and/or repositioned. That would remove the need to "close" an  
> >>> existing
> >>> window.
> >>
> >> The problem is not in the "close" option. The problem is that Octave
> >> issues before each "plot" this command:
> >>
> >> 	set terminal x11 close enhanced title "Figure 1" size 560,420
> >> 	position 300,148
> >>
> >> i.e. Octave wants to reset size and position. However, I think that  
> >> the
> >> size+position options should be added only if user has explicitly
> >> "set(gca,..., size/position, nnn)"; otherwise, these values should  
> >> not be
> >> passed to gnuplot and the positioning should be done by the window  
> >> manager
> >> and user's mouse movements. The default value of size/position in  
> >> Octave
> >> should be "auto" or "default" but not an explicit number.
> >
> > I strongly agree.  An application program has no business changing my
> > window sizes or positions.
> 
> I think we are all in agreement. From the perspective of octave the  
> user communicates to gnuplot via octave. The intent is that octave  
> will only change the window position when the user requests it. And  
> when moved by the mouse, the window will remain where the user placed  
> it (provided he does not ask octave to move it).

I may still be missing the point.  If the user places a window somewhere
by mouse, it will stay there on its own without any extra code in
gnuplot or in Octave.  Is the idea to allow Octave to save the state
of a session in which the user has manually positioned the windows?
That I can understand, and it can be done by re-creating the windows in
their previous positions (now that Petr has added a way to read them out).
But I don't see why there is a need to move an existing window under
software control - what's the intent there?

> > I was reluctant to add this capability to
> > gnuplot in the first place, and the current conversation is not
> > reassuring me.  At the least, I advocate for some simple way that the
> > end user can disable all such position/sizing commands.
> > I am tempted to add an XResource:
> > 	gnuplot.leave-my-windows-alone:	yes   (default)
> 
> I'm confused by the context of your comments, or perhaps you're not  
> familiar with the details of what I'm hoping to do?
> 
>  From the octave side each figure/window has a list of properties  
> which the user may modify. These properties include position and size  
> (the actual figure property is called "position" and includes position  
> and size info [X, Y, W, H]).

Are you saying that the I have to fill in a whole table of
properties, just to open a window?  Surely not.
Or does "modify" just mean "move or resize using the mouse"?

Your description seems to intermingle the notion of session management
(i.e. screen contents and layout) and the notion of keeping a history of
the figure generation. What if I originally created a figure using my
wide-screen terminal at the lab, but then want to edit it later
on my small laptop?   I don't think it's a good idea to mix screen layout
information with figure properties;  they are two entirely different things.

I guess I need to find an Octave user, and look over their shoulder for
a while to see how a typical session would go.

-- 
Ethan A Merritt

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

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

On Feb 11, 2009, at 8:54 PM, Ethan Merritt wrote:

> On Wednesday 11 February 2009 17:26:00 Ben Abbott wrote:
>> On Feb 11, 2009, at 6:56 PM, Ethan Merritt wrote:
>>
>>> On Wednesday 11 February 2009 15:30:30 Petr Mikulik wrote:
>>>
>>>>> In any event, I'd prefer that gnuplot allow an existing window be
>>>>> resized
>>>>> and/or repositioned. That would remove the need to "close" an
>>>>> existing
>>>>> window.
>>>>
>>>> The problem is not in the "close" option. The problem is that  
>>>> Octave
>>>> issues before each "plot" this command:
>>>>
>>>> 	set terminal x11 close enhanced title "Figure 1" size 560,420
>>>> 	position 300,148
>>>>
>>>> i.e. Octave wants to reset size and position. However, I think that
>>>> the
>>>> size+position options should be added only if user has explicitly
>>>> "set(gca,..., size/position, nnn)"; otherwise, these values should
>>>> not be
>>>> passed to gnuplot and the positioning should be done by the window
>>>> manager
>>>> and user's mouse movements. The default value of size/position in
>>>> Octave
>>>> should be "auto" or "default" but not an explicit number.
>>>
>>> I strongly agree.  An application program has no business changing  
>>> my
>>> window sizes or positions.
>>
>> I think we are all in agreement. From the perspective of octave the
>> user communicates to gnuplot via octave. The intent is that octave
>> will only change the window position when the user requests it. And
>> when moved by the mouse, the window will remain where the user placed
>> it (provided he does not ask octave to move it).
>
> I may still be missing the point.  If the user places a window  
> somewhere
> by mouse, it will stay there on its own without any extra code in
> gnuplot or in Octave.  Is the idea to allow Octave to save the state
> of a session in which the user has manually positioned the windows?
> That I can understand, and it can be done by re-creating the windows  
> in
> their previous positions (now that Petr has added a way to read them  
> out).
> But I don't see why there is a need to move an existing window under
> software control - what's the intent there?

Control over window size and position via its scripting language is  
something Matlab does. Compatibility with Matlab is a goal for Octave.  
Of course, there user controls the scripting language, so there should  
be no surprises for the user. In the event a script places a window  
and the user then moves it (via the mouse), the window is intended to  
stay where the mouse placed it (unless the user moves it again by  
using the mouse or a script).

>>> I was reluctant to add this capability to
>>> gnuplot in the first place, and the current conversation is not
>>> reassuring me.  At the least, I advocate for some simple way that  
>>> the
>>> end user can disable all such position/sizing commands.
>>> I am tempted to add an XResource:
>>> 	gnuplot.leave-my-windows-alone:	yes   (default)
>>
>> I'm confused by the context of your comments, or perhaps you're not
>> familiar with the details of what I'm hoping to do?
>>
>> From the octave side each figure/window has a list of properties
>> which the user may modify. These properties include position and size
>> (the actual figure property is called "position" and includes  
>> position
>> and size info [X, Y, W, H]).
>
> Are you saying that the I have to fill in a whole table of
> properties, just to open a window?  Surely not.
> Or does "modify" just mean "move or resize using the mouse"?

The properties all have defaults, which may be modified via Octave's  
scripting language. The size and position of the figure are special in  
that they may be modified by either the scripting language of the mouse.

> Your description seems to intermingle the notion of session management
> (i.e. screen contents and layout) and the notion of keeping a  
> history of
> the figure generation. What if I originally created a figure using my
> wide-screen terminal at the lab, but then want to edit it later
> on my small laptop?   I don't think it's a good idea to mix screen  
> layout
> information with figure properties;  they are two entirely different  
> things.

I'm unclear what you're referring to ... but if I infer correctly,  
Octave doesn't concern itself with the history of the figure position.  
It is only concerned with where the user place it last.

Regarding the value of mixing screen layout with figure properties, I  
see your point. However, this is a historic choice of Mathworks. Thus,  
from my position it is a matter of compatibility.

> I guess I need to find an Octave user, and look over their shoulder  
> for
> a while to see how a typical session would go.

As Octave's behavior in this is still under development, you might get  
a better idea seeing how Matlab behaves.

Ben

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

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

On Feb 11, 2009, at 6:56 PM, Ethan Merritt wrote:

> On Wednesday 11 February 2009 15:30:30 Petr Mikulik wrote:
>
>>> In any event, I'd prefer that gnuplot allow an existing window be  
>>> resized
>>> and/or repositioned. That would remove the need to "close" an  
>>> existing
>>> window.
>>
>> The problem is not in the "close" option. The problem is that Octave
>> issues before each "plot" this command:
>>
>> 	set terminal x11 close enhanced title "Figure 1" size 560,420
>> 	position 300,148
>>
>> i.e. Octave wants to reset size and position. However, I think that  
>> the
>> size+position options should be added only if user has explicitly
>> "set(gca,..., size/position, nnn)"; otherwise, these values should  
>> not be
>> passed to gnuplot and the positioning should be done by the window  
>> manager
>> and user's mouse movements. The default value of size/position in  
>> Octave
>> should be "auto" or "default" but not an explicit number.
>
> I strongly agree.  An application program has no business changing my
> window sizes or positions.

I think we are all in agreement. From the perspective of octave the  
user communicates to gnuplot via octave. The intent is that octave  
will only change the window position when the user requests it. And  
when moved by the mouse, the window will remain where the user placed  
it (provided he does not ask octave to move it).

> I was reluctant to add this capability to
> gnuplot in the first place, and the current conversation is not
> reassuring me.  At the least, I advocate for some simple way that the
> end user can disable all such position/sizing commands.
> I am tempted to add an XResource:
> 	gnuplot.leave-my-windows-alone:	yes   (default)

I'm confused by the context of your comments, or perhaps you're not  
familiar with the details of what I'm hoping to do?

 From the octave side each figure/window has a list of properties  
which the user may modify. These properties include position and size  
(the actual figure property is called "position" and includes position  
and size info [X, Y, W, H]).

> Anyhow, what if the end user wants to use some terminal type other
> than x11?  Is there any particular reason that Octave wouldn't work
> independent of the gnuplot terminal type?

Actually, we like to be able to allow our users to modify the position  
and size of all figure windows, regardless of the terminal type.  
However, my impression is that this is not realistic ... what about  
aquaterm for example?

> I don't see any particular
> advantage to pushing the x11 terminal given the better performance  
> of wxt,
> or the newly proposed qt, or even aquaterm if the aqua team would get
> off its butt and  release the version that's been sitting in cvs for  
> the last 2 years.


If the same functionality were available for wxt and/or qt I'll be  
highly motivated to support that as well ... aquaterm too, but I  
agree, its development appears to have sloooowwweeed down :-(

Ben

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

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

On Wednesday 11 February 2009 15:30:30 Petr Mikulik wrote:

> > In any event, I'd prefer that gnuplot allow an existing window be resized 
> > and/or repositioned. That would remove the need to "close" an existing 
> > window.
>
> The problem is not in the "close" option. The problem is that Octave 
> issues before each "plot" this command:
> 
> 	set terminal x11 close enhanced title "Figure 1" size 560,420
> 	position 300,148
> 
> i.e. Octave wants to reset size and position. However, I think that the 
> size+position options should be added only if user has explicitly 
> "set(gca,..., size/position, nnn)"; otherwise, these values should not be 
> passed to gnuplot and the positioning should be done by the window manager 
> and user's mouse movements. The default value of size/position in Octave 
> should be "auto" or "default" but not an explicit number.

I strongly agree.  An application program has no business changing my
window sizes or positions.  I was reluctant to add this capability to
gnuplot in the first place, and the current conversation is not
reassuring me.  At the least, I advocate for some simple way that the
end user can disable all such position/sizing commands.
I am tempted to add an XResource:
	gnuplot.leave-my-windows-alone:	yes   (default)

Anyhow, what if the end user wants to use some terminal type other
than x11?  Is there any particular reason that Octave wouldn't work
independent of the gnuplot terminal type? I don't see any particular
advantage to pushing the x11 terminal given the better performance of wxt,
or the newly proposed qt, or even aquaterm if the aqua team would get
off its butt and  release the version that's been sitting in cvs for
the last 2 years.

> By default, Octave should ask for
> 	set terminal x11 enhanced title "Figure 1"
> as it has been doing until now.

-- 
Ethan A Merritt

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

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

On Feb 11, 2009, at 6:30 PM, Petr Mikulik wrote:

>>> BTW, I've tested the freshly released octave-3.1.52 and I'm  
>>> disappointed
>>> about the plotting window behaviour. Gnuplot graph window gets  
>>> always closed
>>> and reopened, but not at the previous position, but at some default
>>> position. Moreover, it hijacks the focus. Hitting the "space"  
>>> hotkey helps
>>> to go back, however, is this behaviour really desired? Octave is  
>>> executing
>>> 	set term x11 close size nnn,nnn position nnn,nnn
>>> I think the repositioning command should be issued only if user has
>>> explicitly changed it. Do I have to recompile Octave in order to  
>>> get rid of
>>> this behaviour, or is there some magic "set(gca)" to put the  
>>> window to
>>> the screen corner?
>>
>> The window closing is a compromise to permit the window to be  
>> repositioned
>> by octave. If you have some idea how the window may be repositioned  
>> and
>> resized by latter "set term x11 ..." commands, I'm all for it.
>>
>> Regarding your suggestion of executing "set term x11 close size  
>> nnn,nnn
>> position nnn,nnn" only when the figure position is explicitly  
>> changed, I
>> agree. However, the current backend support does not communicate this
>> information (meaning the current backend doesn't know what was  
>> changed or
>> why a redraw of the figure is needed).
>>
>> I have some ideas of how to do this, but it will take me a while to  
>> get
>> around to that.
>>
>> In any event, I'd prefer that gnuplot allow an existing window be  
>> resized
>> and/or repositioned. That would remove the need to "close" an  
>> existing
>> window.
>
> The problem is not in the "close" option. The problem is that Octave
> issues before each "plot" this command:
>
> 	set terminal x11 close enhanced title "Figure 1" size 560,420
> 	position 300,148
>
> i.e. Octave wants to reset size and position. However, I think that  
> the
> size+position options should be added only if user has explicitly
> "set(gca,..., size/position, nnn)"; otherwise, these values should  
> not be
> passed to gnuplot and the positioning should be done by the window  
> manager
> and user's mouse movements. The default value of size/position in  
> Octave
> should be "auto" or "default" but not an explicit number.
>
> By default, Octave should ask for
> 	set terminal x11 enhanced title "Figure 1"
> as it has been doing until now.

I understand. From the octave end, the problem has been knowing when  
the position/size has changed. Now that the x11 window id is  
available, I will do something to correct this.

Ben

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

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

> >BTW, I've tested the freshly released octave-3.1.52 and I'm disappointed 
> >about the plotting window behaviour. Gnuplot graph window gets always closed 
> >and reopened, but not at the previous position, but at some default 
> >position. Moreover, it hijacks the focus. Hitting the "space" hotkey helps 
> >to go back, however, is this behaviour really desired? Octave is executing
> >	set term x11 close size nnn,nnn position nnn,nnn
> >I think the repositioning command should be issued only if user has 
> >explicitly changed it. Do I have to recompile Octave in order to get rid of 
> >this behaviour, or is there some magic "set(gca)" to put the window to 
> >the screen corner?
> 
> The window closing is a compromise to permit the window to be repositioned 
> by octave. If you have some idea how the window may be repositioned and 
> resized by latter "set term x11 ..." commands, I'm all for it.
> 
> Regarding your suggestion of executing "set term x11 close size nnn,nnn 
> position nnn,nnn" only when the figure position is explicitly changed, I 
> agree. However, the current backend support does not communicate this 
> information (meaning the current backend doesn't know what was changed or 
> why a redraw of the figure is needed).
> 
> I have some ideas of how to do this, but it will take me a while to get 
> around to that.
> 
> In any event, I'd prefer that gnuplot allow an existing window be resized 
> and/or repositioned. That would remove the need to "close" an existing 
> window.

The problem is not in the "close" option. The problem is that Octave 
issues before each "plot" this command:

	set terminal x11 close enhanced title "Figure 1" size 560,420
	position 300,148

i.e. Octave wants to reset size and position. However, I think that the 
size+position options should be added only if user has explicitly 
"set(gca,..., size/position, nnn)"; otherwise, these values should not be 
passed to gnuplot and the positioning should be done by the window manager 
and user's mouse movements. The default value of size/position in Octave 
should be "auto" or "default" but not an explicit number.

By default, Octave should ask for
	set terminal x11 enhanced title "Figure 1"
as it has been doing until now.

---
PM

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

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

On Wednesday, February 11, 2009, at 10:08AM, "Petr Mikulik" <mi...@ph...> wrote:
>On Fri, 6 Feb 2009, Ethan Merritt wrote:
>
>> On Friday 06 February 2009 13:57:41 Petr Mikulik wrote:
>> > > The intent is to update GPVAL_TERM_WINDOWID when the main program receives a
>> > > "new window" event from gnuplot_x11, right?  
>> > > 
>> > > I am trying to point out that not every command "set term x11 <num>" creates
>> > > a new window. If an old window is re-used, you won't receive this event and
>> > > therefore GPVAL_TERM_WINDOWID  will not be updated.
>> > > 
>> > > The patch currently has the event generated each time the buffered command
>> > > list is re-executed, which I think is not right.  Probably it should go in
>> > > pr_window(), immediately after the call to XCreateWindow().
>> > 
>> > When I tested it, it was filling the variable after the "plot" command has 
>> > been completed (not after "set term x11"), i.e. after the graph has been 
>> > drawn.
>> 
>> I think the correct patch on the gplt_x11.c end is something like the one
>> attached here.
>
>I have updated the patch
>[ 2570385 ] GPVAL_X11_WINDOWID
>https://sourceforge.net/tracker/?func=detail&atid=302055&aid=2570385&group_id=2055
>with Ethan's solution and an additional wrapper over GE_plotdone sender. 
>Now, only changed window ID's are sent to gnuplot for the variable 
>GPVAL_TERM_WINDOWID to be updated.
>
>Ben, can you please test it? Would it suite the needs in Octave?

Looks good to me.

gnuplot> plot sin(x)
AGAIN: gplt_x11.c:3727: SENDING NEW WINDOWID 0x200026 TO GNUPLOT...
gnuplot> mouse.c:1848: set current_x11_windowid to 200026
gnuplot> show var GPVAL_TERM_WINDOWID

	Variables beginning with GPVAL_TERM_WINDOWID:
	GPVAL_TERM_WINDOWID = 2097190

Ben

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

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

On Wednesday, February 11, 2009, at 10:08AM, "Petr Mikulik" <mi...@ph...> wrote:
>On Fri, 6 Feb 2009, Ethan Merritt wrote:
>
>> On Friday 06 February 2009 13:57:41 Petr Mikulik wrote:
>> > > The intent is to update GPVAL_TERM_WINDOWID when the main program receives a
>> > > "new window" event from gnuplot_x11, right?  
>> > > 
>> > > I am trying to point out that not every command "set term x11 <num>" creates
>> > > a new window. If an old window is re-used, you won't receive this event and
>> > > therefore GPVAL_TERM_WINDOWID  will not be updated.
>> > > 
>> > > The patch currently has the event generated each time the buffered command
>> > > list is re-executed, which I think is not right.  Probably it should go in
>> > > pr_window(), immediately after the call to XCreateWindow().
>> > 
>> > When I tested it, it was filling the variable after the "plot" command has 
>> > been completed (not after "set term x11"), i.e. after the graph has been 
>> > drawn.
>> 
>> I think the correct patch on the gplt_x11.c end is something like the one
>> attached here.
>
>I have updated the patch
>[ 2570385 ] GPVAL_X11_WINDOWID
>https://sourceforge.net/tracker/?func=detail&atid=302055&aid=2570385&group_id=2055
>with Ethan's solution and an additional wrapper over GE_plotdone sender. 
>Now, only changed window ID's are sent to gnuplot for the variable 
>GPVAL_TERM_WINDOWID to be updated.
>
>Ben, can you please test it? Would it suite the needs in Octave?
>
>BTW, I've tested the freshly released octave-3.1.52 and I'm disappointed 
>about the plotting window behaviour. Gnuplot graph window gets always closed 
>and reopened, but not at the previous position, but at some default 
>position. Moreover, it hijacks the focus. Hitting the "space" hotkey helps 
>to go back, however, is this behaviour really desired? Octave is executing
>	set term x11 close size nnn,nnn position nnn,nnn
>I think the repositioning command should be issued only if user has 
>explicitly changed it. Do I have to recompile Octave in order to get rid of 
>this behaviour, or is there some magic "set(gca)" to put the window to 
>the screen corner?
>

Petr,

The window closing is a compromise to permit the window to be repositioned by octave. If you have some idea how the window may be repositioned and resized by latter "set term x11 ..." commands, I'm all for it.

Regarding your suggestion of executing "set term x11 close size nnn,nnn position nnn,nnn" only when the figure position is explicitly changed, I agree. However, the current backend support does not communicate this information (meaning the current backend doesn't know what was changed or why a redraw of the figure is needed).

I have some ideas of how to do this, but it will take me a while to get around to that.

In any event, I'd prefer that gnuplot allow an existing window be resized and/or repositioned. That would remove the need to "close" an existing window.

Ben

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

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

On Fri, 6 Feb 2009, Ethan Merritt wrote:

> On Friday 06 February 2009 13:57:41 Petr Mikulik wrote:
> > > The intent is to update GPVAL_TERM_WINDOWID when the main program receives a
> > > "new window" event from gnuplot_x11, right?  
> > > 
> > > I am trying to point out that not every command "set term x11 <num>" creates
> > > a new window. If an old window is re-used, you won't receive this event and
> > > therefore GPVAL_TERM_WINDOWID  will not be updated.
> > > 
> > > The patch currently has the event generated each time the buffered command
> > > list is re-executed, which I think is not right.  Probably it should go in
> > > pr_window(), immediately after the call to XCreateWindow().
> > 
> > When I tested it, it was filling the variable after the "plot" command has 
> > been completed (not after "set term x11"), i.e. after the graph has been 
> > drawn.
> 
> I think the correct patch on the gplt_x11.c end is something like the one
> attached here.

I have updated the patch
[ 2570385 ] GPVAL_X11_WINDOWID
https://sourceforge.net/tracker/?func=detail&atid=302055&aid=2570385&group_id=2055
with Ethan's solution and an additional wrapper over GE_plotdone sender. 
Now, only changed window ID's are sent to gnuplot for the variable 
GPVAL_TERM_WINDOWID to be updated.

Ben, can you please test it? Would it suite the needs in Octave?

BTW, I've tested the freshly released octave-3.1.52 and I'm disappointed 
about the plotting window behaviour. Gnuplot graph window gets always closed 
and reopened, but not at the previous position, but at some default 
position. Moreover, it hijacks the focus. Hitting the "space" hotkey helps 
to go back, however, is this behaviour really desired? Octave is executing
	set term x11 close size nnn,nnn position nnn,nnn
I think the repositioning command should be issued only if user has 
explicitly changed it. Do I have to recompile Octave in order to get rid of 
this behaviour, or is there some magic "set(gca)" to put the window to 
the screen corner?

---
PM

Re: makefile.mgw : name of c complier for pgnuplot

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

> 	gcc -O2 -DHAVE_STDBOOL_H -s -o $@ win/pgnuplot.c version.o -I. -luser32
> 	$(CC) -O2 -DHAVE_STDBOOL_H -s -o $@ win/pgnuplot.c version.o -I. -luser32

I've put this to cvs.

>From this release, I have changed GCC compiler from 4.3.0-dw2-TDM to 
> 4.3.2-dw-2-TDM. Owing to higher stability of 4.3.2-dw-2-TDM than 
> 4.3.0-dw2-TDM , binaries of complied with -O3 -fomit-frame-pointer seem to 
> be stable. (For 4.3.0-dw2-TDM, binaries with -O3 -fomit-frame-pointer were 
> unstable so that I used -O3 but not -O3 -fomit-frame-pointer )

Why are the advantages of this "Dragon" MinGW fork compared to MinGW? I 
couldn't find this info on its web.

---
PM

gnuplot 4.3 (cvs) (2009-02-07) for windows (GCC-complier updated)

[Tatsuro M. <tma...@ya...>]

Hello

I have updated  gnuplot 4.3 (cvs) (2009-02-07) for windows.

>From this release, I have changed GCC compiler from 4.3.0-dw2-TDM to 4.3.2-dw-2-TDM.
Owing to higher stability of 4.3.2-dw-2-TDM than 4.3.0-dw2-TDM , binaries of complied
with -O3 -fomit-frame-pointerseem to be stable. (For 4.3.0-dw2-TDM, binaries with 
-O3 -fomit-frame-pointer were unstable so that I used -O3 but not -O3 -fomit-frame-pointer )

Regards

Tatsuro


--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

makefile.mgw : name of c complier for pgnuplot

[Tatsuro M. <tma...@ya...>]

Hello

In makefile.mgw, it is found that
$(PGNUPLOT): win/pgnuplot.c version.o
	gcc -O2 -DHAVE_STDBOOL_H -s -o $@ win/pgnuplot.c version.o -I. -luser32

However, gcc is not always name of compiler of GCC on mingw at present.  For GCC-4.3.3-dw2-TDM mingw,
the name of c complier is gcc-dw2 but not gcc.

I think that it should be

$(PGNUPLOT): win/pgnuplot.c version.o
	$(CC) -O2 -DHAVE_STDBOOL_H -s -o $@ win/pgnuplot.c version.o -I. -luser32

Regards

Tatsuro




--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Re: configure.in and libgd

[Allin C. <cot...@wf...>]

On Mon, 9 Feb 2009, Allin Cottrell wrote:

> There's something wrong with the handling of the linker line for
> libgd in gnuplot's configure.in...
>
> I'm not sure exactly what's the best fix here, but it seems that
> adding "-lpng" should somehow be made conditional on
> the libgd_LIBS variable not already including a directive to link
> to (some variant of) libpng.

Here's a stab at a patch.  Probably could be more elegant.

Allin Cottrell

configure.in and libgd

[Allin C. <cot...@wf...>]

There's something wrong with the handling of the linker line for
libgd in gnuplot's configure.in.  Consider a system that has a
correct gdlib.config: gnuplot does

libgd_LIBS=`gdlib-config --libs`

That's fine, but it should be the end of the story. However,
further down in configure.in, the script unconditionally adds
"-ljpeg" (when checking for JPEG support) and "-lpng" (when
checking for PNG support).  The problem is that if libgd is linked
against libpng12.so, and if there also exists on the system the
older (or compatibility) library libpng.so, then gnuplot will end
up linked against both libpng12 and libpng.

E.g., gdlib-config --libs gives:

-lXpm -lX11 -lfontconfig -lfreetype -lpng12 -lz -lm

and in src/Makefile we get:

TERMLIBS =  <...> -lz -lgd -lXpm -lX11 \
-lfontconfig -lfreetype -lpng12 -lz -lm -lfreetype -lpng

I'm not sure exactly what's the best fix here, but it seems that
adding "-lpng" should somehow be made conditional on
the libgd_LIBS variable not already including a directive to link
to (some variant of) libpng.

-- 
Allin Cottrell
Department of Economics
Wake Forest University

Binaries of gnuplot 4.3 (cvs) on windows and cygwin is up dated (Changelog Date 2009-02-07)

[Tatsuro M. <tma...@ya...>]

Hello

Binaries of gnuplot 4.3 (cvs) on cygwin and windows are up dated (Changelog Date 2009-02-07)

cygwin
http://www.tatsuromatsuoka.com/gnuplot/Eng/cygbin/

windows
http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/

Notes
Cygwin release
 A zip compressed file of the gnuplot manual in html format (htmldocs.zip) is added.

Windows release
 Add links of "Windows Help program (WinHlp32.exe) for Windows Vista", which is required to use
wgnuplot.hlp on windows vista. 

Thanks to Prof. Shigeharu Takeno giving me information.

Regards

Tatsuro  

--------------------------------------
Yahoo! JAPAN - Internet safety for children and parents.
http://pr.mail.yahoo.co.jp/security/