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 Dec 29, 2008, at 9:00 PM, Daniel J Sebald wrote:

> Ben Abbott wrote:
>> On Dec 29, 2008, at 1:34 PM, Ethan Merritt wrote:
>>> On Monday 29 December 2008 10:04:32 Ben Abbott wrote:
>>>
>>>> On Dec 29, 2008, at 12:25 PM, Ethan A Merritt wrote:
>>>>
>>>>
>>>>> On Monday 29 December 2008, Ben Abbott wrote:
>>>>>
>>>>>
>>>>>>>>>> Are you suggesting that Octave's plot stream contain only one
>>>>>>>>>> "set
>>>>>>>>>> terminal ..."? ... if so by what means is it possible to  
>>>>>>>>>> clear
>>>>>>>>>> the
>>>>>>>>>> canvas and start from scratch?
>>>>>>>>>
>>>>>>>>> That happens every time you issue a "plot" command.  You don't
>>>>>>>>> have
>>>>>>>>> to do anything special.  Although there is a "clear" command  
>>>>>>>>> if
>>>>>>>>> for
>>>>>>>>> some reason you want to blank the window but not draw  
>>>>>>>>> anything.
>>>>>>>>
>>>>>>>> I'm not sure I understand the context correctly, but ... what  
>>>>>>>> of
>>>>>>>> multiplot? ... there can be multiple plot commands that do not
>>>>>>>> delete
>>>>>>>> anything correct? ... this is the way Octave draws everything.
>>>>>>>
>>>>>>> It probably should not do that.  Do you know why it does?
>>>>>>
>>>>>> Octave & Matlab each place multiple plots in each figure  
>>>>>> window. By
>>>>>> multiple plots, I mean multiple axes in one window. Some axes  
>>>>>> might
>>>>>> be
>>>>>> 2D of various types and others 3D.
>>>>>
>>>>> It seems to me that this would be better done by opening separate
>>>>> windows
>>>>> for each plot, perhaps tiled to be adjacent.  That would let  
>>>>> you  edit
>>>>> and interact with each component plot separately, which is not
>>>>> possible
>>>>> for the separate components of a multiplot.
>>>>>
>>>>> Easy for me to say - I am neither programming nor using Octave.
>>>>
>>>> I agree. However, that would break compatibility with Matlab ...   
>>>> which
>>>> is actually what I'm attempting to improve.
>>>
>>> Well, I'm totally lost.  I don't understand why it would make any
>>> difference to the user, other than the gain in functionality.
>>>
>>>
>>>> Am I correct in inferring that rotation of plots does work but   
>>>> zooming
>>>> does not (which is what I observe for Octave's gnuplot windows on  
>>>> Mac
>>>> OSX).
>>>
>>> No, this is not correct.  At least, not if you have correctly   
>>> described
>>> how Octave uses multiplot. You cannot interact with the individual
>>> component plots of a multiplot.  Not zooming, not rotation,
>>> not mouse tracking, no toggling ruler/grid/logscale, none of that.
>>> Doing things inside multiplot severely limits the features that
>>> gnuplot would normally give you automatically.
>>>
>>>
>>>>> you still have not explained why you (or Octave) would
>>>>> want to close and re-open the terminal plot window before starting
>>>>> a new plot.  What do you gain by this?
>>>>
>>>> Opps, I apparently wasn't clear in my description.
>>>>
>>>> Octave may have many plot windows open simultaneously.  Each  
>>>> gnuplot
>>>> window contains one Octave figure whose objects may be modified  
>>>> via a
>>>> command line interface at the users discretion. The user may  
>>>> close a
>>>> figure's window either via the mouse or via the command line.
>>>>
>>>> I've added support for the position and size options of the x11
>>>> terminal to my local code for octave. I notice that the x11  
>>>> terminal
>>>> only respects these properties for the first instance of "set  
>>>> termina
>>>> x11 ..." in the plot stream. This is different than how the aqua  
>>>> and
>>>> wxt terminals behave. Meaning that each time I change the terminals
>>>> size, both the aqua and wxt windows change their size
>>>
>>>
>>> I think you are either doing something wrong, or failing to explain
>>> the difference between what you are seeing and what you are  
>>> expecting.
>>> The following sequence of commands will open three separate x11 plot
>>> windows with different sizes.  Each window can be managed  
>>> separately.
>>> This behaviour may not be truly identical to that for wxt, but so  
>>> far
>>> as I know the differences are subtle rather than dramatic.
>>> Do you have a counter-example?
>>>
>>>  set term x11 1 title "Plot window #1"
>>>  plot foo
>>>  set term x11 2 title "Plot window #2"
>>>  splot baz
>>>  set term x11 3 title "3rd plot window"
>>>  plot blech
>>>
>>>  # Close window 2, leave 1 and 3 unchanged:
>>>  set term x11 2 close
>>>
>>>  # Replace the contents of window 1, leaving window 3 unchanged
>>>  set term x11 1
>>>  plot new-stuff
>>>
>>>
>>>
>>>> Would it be possible for the x11 terminal to behave in the same   
>>>> manner?
>>>
>>> Please describe "same manner" more explicitly.'
>> Ok, try this
>> 	set term x11 1 size 500,400 position 100,100
>> 	plot sin(x)
>> 	set term x11 1 size 500,200 position 300,100
>> 	close 1
>> 	plot sin(x)
>> After the second plot command the window remains the same size and  
>> in  the same position as the first.
>> If I use the mouse to close the window prior to the second "plot   
>> sin(x)" then I get the effect I desire.
>
> Ben,
>
> I haven't followed this thread closely, but keep in mind that Octave  
> is currently programmed to create a new instance (process, version,  
> whatever) of gnuplot for every plot it creates.  John did things  
> that way because gnuplot currently only has the mouse active in one  
> window due to the fact that plot data is not retained but for the  
> most recent plot.  John figured gnuplot is small, so launch however  
> many versions of it that are required.
>
> So, I think that when you typed "close 1", gnuplot was completely  
> exited and a new plot command starts gnuplot from fresh.  However,  
> when you used the mouse to close the window, the X11 window was  
> closed but gnuplot_x11 is still active so retains the information  
> about the window size before it was externally closed (not by  
> Octave, but by the mouse).
>
> Some work was done on retaining plotting data for all plots but I  
> think it is only in experimental stage right now.  Such a feature  
> would enable Octave to not require opening a new version of gnuplot  
> for every new Octave plot.  Also, my guess is that gnuplot would be  
> able to handle multiplot more robustly with data retention.  There  
> is a bit of work on both sides of the exchange to do that integration.
>
> Dan

ah-ha

I'd not been aware that a new instance of gnuplot was created for each  
plot (although it is quite obvious now that you mention it).

Thanks
Ben

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

[Daniel J S. <dan...@ie...>]

Ben Abbott wrote:
> On Dec 29, 2008, at 1:34 PM, Ethan Merritt wrote:
> 
> 
>>On Monday 29 December 2008 10:04:32 Ben Abbott wrote:
>>
>>>On Dec 29, 2008, at 12:25 PM, Ethan A Merritt wrote:
>>>
>>>
>>>>On Monday 29 December 2008, Ben Abbott wrote:
>>>>
>>>>
>>>>>>>>>Are you suggesting that Octave's plot stream contain only one
>>>>>>>>>"set
>>>>>>>>>terminal ..."? ... if so by what means is it possible to clear
>>>>>>>>>the
>>>>>>>>>canvas and start from scratch?
>>>>>>>>
>>>>>>>>That happens every time you issue a "plot" command.  You don't
>>>>>>>>have
>>>>>>>>to do anything special.  Although there is a "clear" command if
>>>>>>>>for
>>>>>>>>some reason you want to blank the window but not draw anything.
>>>>>>>
>>>>>>>I'm not sure I understand the context correctly, but ... what of
>>>>>>>multiplot? ... there can be multiple plot commands that do not
>>>>>>>delete
>>>>>>>anything correct? ... this is the way Octave draws everything.
>>>>>>
>>>>>>It probably should not do that.  Do you know why it does?
>>>>>
>>>>>Octave & Matlab each place multiple plots in each figure window. By
>>>>>multiple plots, I mean multiple axes in one window. Some axes might
>>>>>be
>>>>>2D of various types and others 3D.
>>>>
>>>>It seems to me that this would be better done by opening separate
>>>>windows
>>>>for each plot, perhaps tiled to be adjacent.  That would let you  
>>>>edit
>>>>and interact with each component plot separately, which is not
>>>>possible
>>>>for the separate components of a multiplot.
>>>>
>>>>Easy for me to say - I am neither programming nor using Octave.
>>>
>>>I agree. However, that would break compatibility with Matlab ...  
>>>which
>>>is actually what I'm attempting to improve.
>>
>>Well, I'm totally lost.  I don't understand why it would make any
>>difference to the user, other than the gain in functionality.
>>
>>
>>>Am I correct in inferring that rotation of plots does work but  
>>>zooming
>>>does not (which is what I observe for Octave's gnuplot windows on Mac
>>>OSX).
>>
>>No, this is not correct.  At least, not if you have correctly  
>>described
>>how Octave uses multiplot. You cannot interact with the individual
>>component plots of a multiplot.  Not zooming, not rotation,
>>not mouse tracking, no toggling ruler/grid/logscale, none of that.
>>Doing things inside multiplot severely limits the features that
>>gnuplot would normally give you automatically.
>>
>>
>>>>you still have not explained why you (or Octave) would
>>>>want to close and re-open the terminal plot window before starting
>>>>a new plot.  What do you gain by this?
>>>
>>>Opps, I apparently wasn't clear in my description.
>>>
>>>Octave may have many plot windows open simultaneously.  Each gnuplot
>>>window contains one Octave figure whose objects may be modified via a
>>>command line interface at the users discretion. The user may close a
>>>figure's window either via the mouse or via the command line.
>>>
>>>I've added support for the position and size options of the x11
>>>terminal to my local code for octave. I notice that the x11 terminal
>>>only respects these properties for the first instance of "set termina
>>>x11 ..." in the plot stream. This is different than how the aqua and
>>>wxt terminals behave. Meaning that each time I change the terminals
>>>size, both the aqua and wxt windows change their size
>>
>>
>>I think you are either doing something wrong, or failing to explain
>>the difference between what you are seeing and what you are expecting.
>>The following sequence of commands will open three separate x11 plot
>>windows with different sizes.  Each window can be managed separately.
>>This behaviour may not be truly identical to that for wxt, but so far
>>as I know the differences are subtle rather than dramatic.
>>Do you have a counter-example?
>>
>>   set term x11 1 title "Plot window #1"
>>   plot foo
>>   set term x11 2 title "Plot window #2"
>>   splot baz
>>   set term x11 3 title "3rd plot window"
>>   plot blech
>>
>>   # Close window 2, leave 1 and 3 unchanged:
>>   set term x11 2 close
>>
>>   # Replace the contents of window 1, leaving window 3 unchanged
>>   set term x11 1
>>   plot new-stuff
>>
>>
>>
>>>Would it be possible for the x11 terminal to behave in the same  
>>>manner?
>>
>>Please describe "same manner" more explicitly.'
> 
> 
> Ok, try this
> 
> 	set term x11 1 size 500,400 position 100,100
> 	plot sin(x)
> 	set term x11 1 size 500,200 position 300,100
> 	close 1
> 	plot sin(x)
> 
> After the second plot command the window remains the same size and in  
> the same position as the first.
> 
> If I use the mouse to close the window prior to the second "plot  
> sin(x)" then I get the effect I desire.

Ben,

I haven't followed this thread closely, but keep in mind that Octave is currently programmed to create a new instance (process, version, whatever) of gnuplot for every plot it creates.  John did things that way because gnuplot currently only has the mouse active in one window due to the fact that plot data is not retained but for the most recent plot.  John figured gnuplot is small, so launch however many versions of it that are required.

So, I think that when you typed "close 1", gnuplot was completely exited and a new plot command starts gnuplot from fresh.  However, when you used the mouse to close the window, the X11 window was closed but gnuplot_x11 is still active so retains the information about the window size before it was externally closed (not by Octave, but by the mouse).

Some work was done on retaining plotting data for all plots but I think it is only in experimental stage right now.  Such a feature would enable Octave to not require opening a new version of gnuplot for every new Octave plot.  Also, my guess is that gnuplot would be able to handle multiplot more robustly with data retention.  There is a bit of work on both sides of the exchange to do that integration.

Dan

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

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

On Dec 29, 2008, at 6:05 PM, Ethan Merritt wrote:

> On Monday 29 December 2008 14:36:53 Ben Abbott wrote:
>>
>> On Dec 29, 2008, at 12:15 AM, Ethan A Merritt wrote:
>>
>>> Well, if someone can figure out which bit of code in gplt_x11.c is
>>> getting called erroneously in your original trials, I'd be happy to
>>> help design a fix for it.  But since I can't reproduce the problem
>>> here,
>>> I am entirely dependent on someone else to pin down the precise  
>>> source
>>> of the error.
>>
>>
>> I asked for some help on Octave's mail list. The relevant portion  
>> of a
>> response is below
>>
>> On Dec 29, 2008, at 4:54 PM, Thomas Treichl wrote:
>>
>>> I started the debugger and did 'gnuplot> load "simple_example.gp"'
>>> once again and I cannot see the problem. The reason now might be
>>> that somewhere we have some kind of *timing* problem, ie. if the
>>> commands are typed in per hand then this is 'slow' enough that the
>>> window is not resized - the same happens if I run the program with
>>> the debugger. The debugger needs some time for each line and that's
>>> already enough so that the resizing problem doesn't appear. This
>>> also means that we don't get any further with debugging as we cannot
>>> see the problem if we use gdb. I'm currently out of ideas how we can
>>> track for this problem...
>>
>> So the window grows when gnuplot form the command line and my example
>> is loaded, but does not when run in the debugger.
>>
>> I checked Thomas' hypothesis by placing a "pause(0.1)" after each
>> plot, and the window did not grow.
>
> Yuck. "timing problem" is a symptom, not a cause.
> Nevertheless, please test the following one-line workaround.
> If this fixes it then we can wrap it in some OSX-specific conditional
> test and a comment explaining that it is just an empirical hack for
> a timing problem.
>
> --- gnuplot/src/term.c  2008-12-12 13:06:13.000000000 -0800
> +++ gnuplot-cvs/src/term.c      2008-12-29 15:01:26.000000000 -0800
> @@ -822,6 +822,7 @@ term_end_multiplot()
>      * eventually statusline */
>     mouse_setting.on = save_mouse_state;
>     UpdateStatusline();
> +    usleep(100);
> #endif
> }

Unfortunately, the window continues to grow.

Ben

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

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

On Monday 29 December 2008 14:36:53 Ben Abbott wrote:
> 
> On Dec 29, 2008, at 12:15 AM, Ethan A Merritt wrote:
> 
> > Well, if someone can figure out which bit of code in gplt_x11.c is
> > getting called erroneously in your original trials, I'd be happy to
> > help design a fix for it.  But since I can't reproduce the problem  
> > here,
> > I am entirely dependent on someone else to pin down the precise source
> > of the error.
> 
> 
> I asked for some help on Octave's mail list. The relevant portion of a  
> response is below
> 
> On Dec 29, 2008, at 4:54 PM, Thomas Treichl wrote:
> 
> > I started the debugger and did 'gnuplot> load "simple_example.gp"'  
> > once again and I cannot see the problem. The reason now might be  
> > that somewhere we have some kind of *timing* problem, ie. if the  
> > commands are typed in per hand then this is 'slow' enough that the  
> > window is not resized - the same happens if I run the program with  
> > the debugger. The debugger needs some time for each line and that's  
> > already enough so that the resizing problem doesn't appear. This  
> > also means that we don't get any further with debugging as we cannot  
> > see the problem if we use gdb. I'm currently out of ideas how we can  
> > track for this problem...
> 
> So the window grows when gnuplot form the command line and my example  
> is loaded, but does not when run in the debugger.
> 
> I checked Thomas' hypothesis by placing a "pause(0.1)" after each  
> plot, and the window did not grow.

Yuck. "timing problem" is a symptom, not a cause.
Nevertheless, please test the following one-line workaround.
If this fixes it then we can wrap it in some OSX-specific conditional
test and a comment explaining that it is just an empirical hack for
a timing problem.

--- gnuplot/src/term.c  2008-12-12 13:06:13.000000000 -0800
+++ gnuplot-cvs/src/term.c      2008-12-29 15:01:26.000000000 -0800
@@ -822,6 +822,7 @@ term_end_multiplot()
      * eventually statusline */
     mouse_setting.on = save_mouse_state;
     UpdateStatusline();
+    usleep(100);
 #endif
 }








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

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

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

On Dec 29, 2008, at 12:15 AM, Ethan A Merritt wrote:

> Well, if someone can figure out which bit of code in gplt_x11.c is
> getting called erroneously in your original trials, I'd be happy to
> help design a fix for it.  But since I can't reproduce the problem  
> here,
> I am entirely dependent on someone else to pin down the precise source
> of the error.


I asked for some help on Octave's mail list. The relevant portion of a  
response is below

On Dec 29, 2008, at 4:54 PM, Thomas Treichl wrote:

> I started the debugger and did 'gnuplot> load "simple_example.gp"'  
> once again and I cannot see the problem. The reason now might be  
> that somewhere we have some kind of *timing* problem, ie. if the  
> commands are typed in per hand then this is 'slow' enough that the  
> window is not resized - the same happens if I run the program with  
> the debugger. The debugger needs some time for each line and that's  
> already enough so that the resizing problem doesn't appear. This  
> also means that we don't get any further with debugging as we cannot  
> see the problem if we use gdb. I'm currently out of ideas how we can  
> track for this problem...

So the window grows when gnuplot form the command line and my example  
is loaded, but does not when run in the debugger.

I checked Thomas' hypothesis by placing a "pause(0.1)" after each  
plot, and the window did not grow.

The modified script is attached.

Ben

Aquaterm [was: problem with "set x11 {size WW,HH} {position XX,YY}"]

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

On Monday 29 December 2008 12:27:59 Ben Abbott wrote:

> >
> >> Would it be possible for the x11 terminal to behave in the same  
> >> manner?
> >
> > Please describe "same manner" more explicitly.'
> 
> Ok, try this
> 
> 	set term x11 1 size 500,400 position 100,100
> 	plot sin(x)
> 	set term x11 1 size 500,200 position 300,100
> 	close 1
> 	plot sin(x)
> 
> After the second plot command the window remains the same size and in  
> the same position as the first.

Correct.  The window is already open, and the second "set term" does
not change its basic properties.  This is pretty much necessary in order
to allow sequences like:
     set term x11 ...
        ... plot lots of stuff, perhaps with mouse interaction,
     set term post; set output 'plot_v1.ps'; replot; set term x11 
        ... some more fiddling, perhaps zoom, change view, etc
     set term post; set output 'plot_v2.ps'; replot; set term x11 
        ... etc

> Regarding my expectations, you are correct, I associated gnuplot's  
> "close" option with deleting the window and all its options. I tried  
> inserting a "set term x11 1 close"  after the first "plot sin(x)" and  
> prior to the second and I got the effect I desired.
 
> The aqua terminal behaves differently. The command below produce a  
> change in the window size.
> 
> 	set term aqua 1 size 500 400
> 	plot sin(x)
> 	set term aqua 1 size 500 200
> 	plot sin(x)
> 
> Unfortunately, there is no "close" option for the aqua terminal.

I don't know that much about the aqua terminal, and its project page on
SourceForge appears moribund.   The documentation for use with gnuplot,
for instance, still refers to gnuplot version 3.8.

I tried to stir up interest over there to at least release the existing
2-year-old aquaterm version 1.1 that includes support for transparency,
but even that hasn't happened. "Close" sounds like it would be a trivial
change, but it won't help anyone unless/until the aquaterm developers
are willing to release and distribute a version that supports it.

Perhaps you will be more successful than I was in prodding them to make
a new release. I was told back in June that "the code is set for a 1.1
release, but needs testing on Intel Macs and 10.5.x".  Maybe if you
volunteer to be a tester, they will make a release candidate for you
to test?

The project website is here:
    https://sourceforge.net/projects/aquaterm/

And some people to prod are here:
    hba...@us...
    ama...@us...
    per...@ma...

> In any event, you've revealed another solution to me. I'll use "close"  
> for the x11 terminal before updating the plot window.
> 
> >> (at least wxt
> >> did before I began running 4.3+, not the wxt terminal does not work
> >> for me).
> >
> > Are you saying that you have observed a recent regression in wxt?
> > Please file a separate bug report. I am not aware of any outstanding
> > problems other than the general incompatibility with Mac OSX.
> 
> I assume the wxt terminal is working. Thus, I'll invest some effort  
> ensuring I have everything set up correctly. Just to be sure, what wx  
> version is needed? I have wxmac 2.8.3 installed.

So far as I know, the wxt terminal has never worked under OSX;
I've been told that the control flow is inherently incompatible with the
OSX graphics model.  Timothée Lecomte has been working on a re-design that
would allow it, but he doesn't have much time to devote to it.


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

Re: automake , I am is needing help

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

On Monday 29 December 2008 13:43:48 pl...@pi... wrote:
> Ethan Merritt wrote:
> > On Monday 29 December 2008 05:12:09 pl...@pi... wrote:
> >> Hi,
> >>
> >> I'm trying to follow the tortuous workings of automake to add a new dir
> >> for svg javascript. I am is needing help ;)
> > 
> > I am a bit confused.
> > Are you talking about adding a new directory to the cvs source tree?
> > That has nothing in particular to do with automake.
> > The commands would be:
> >     mkdir temp/javascriptdir
> >     cp $my-new-stuff/* temp/javascriptdir
> >     cvs add term/javascriptdir
> >     cvs commit -m 'Add javascriptdir to the source tree'
> > But you can't do that unless you have write access to the cvs tree.
> 
> No, that will have to be done later to set up any fixed files to be
> distributed like the postscript files but for now I have created them
> locally.
> 
> What I want to do in ensure the new dir is created and installed by
> 'make install'. It would seem it has to get included in am__installdirs
> but I cant see how.

The attached patch should do it.
Season to taste if the files are called something other than *.js





> 
> thanks.
> 
> > 
> >> I want to copy the use of the postscriptdir and have defined varibable
> >> javascriptdir but cannnot see how to add this to the list of installdirs
> >> to get it created and populated.
> >>
> >> term/Makefile:am__installdirs = "$(DESTDIR)$(luadir)"
> >> "$(DESTDIR)$(postscriptdir)"
> > 
> > Still confused, but perhaps you want:
> > 
> > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> > diff -ur gnuplot/term/Makefile.am.in  gnuplot-cvs/term/Makefile.am.in
> > --- gnuplot-old/term/Makefile.am.in 2008-12-23 11:22:18.000000000 -0800
> > +++ gnuplot-new/term/Makefile.am.in     2008-12-29 10:44:25.000000000 -0800
> > @@ -2,7 +2,7 @@
> >  AUTOMAKE_OPTIONS = foreign 1.2h
> > 
> >  EXTRA_DIST = README Makefile.am.in driver.h impcodes.h \
> > -object.h post.h $(CORETERM) PostScript lua
> > +object.h post.h $(CORETERM) PostScript lua javascriptdir
> > 
> >  postscriptdir = $(pkgdatadir)/$(VERSION_MAJOR)/PostScript
> > 
> > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> > 
> > That will ensure that your new directory is included in a tarball of the
> > distributed package.  I suggest that naming this directory simply "svg"
> > would be better than "javascriptdir", because it might end up holding
> > other svg-related things that are not javascript.
> > 
> > 
> >  
> >> maybe someone familiar with this could point me in the right direction.
> >>
> >> I have modified svg.trm to read in a script from that dir and insert it
> >> as a <script> tag at the top of the SVG output. That much works so I
> >> have a mechanism within gnuplot to add interactive content to svg.
> >>
> >>
> >> thanks , Peter.
> > 
> > 
> 
> 



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

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

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

On Dec 29, 2008, at 4:34 PM, Ethan Merritt wrote:

> On Monday 29 December 2008 12:27:59 Ben Abbott wrote:
>
>>>
>>>> Would it be possible for the x11 terminal to behave in the same
>>>> manner?
>>>
>>> Please describe "same manner" more explicitly.'
>>
>> Ok, try this
>>
>> 	set term x11 1 size 500,400 position 100,100
>> 	plot sin(x)
>> 	set term x11 1 size 500,200 position 300,100
>> 	close 1
>> 	plot sin(x)
>>
>> After the second plot command the window remains the same size and in
>> the same position as the first.
>
> Correct.  The window is already open, and the second "set term" does
> not change its basic properties.  This is pretty much necessary in  
> order
> to allow sequences like:
>     set term x11 ...
>        ... plot lots of stuff, perhaps with mouse interaction,
>     set term post; set output 'plot_v1.ps'; replot; set term x11
>        ... some more fiddling, perhaps zoom, change view, etc
>     set term post; set output 'plot_v2.ps'; replot; set term x11
>        ... etc
>
>> Regarding my expectations, you are correct, I associated gnuplot's
>> "close" option with deleting the window and all its options. I tried
>> inserting a "set term x11 1 close"  after the first "plot sin(x)" and
>> prior to the second and I got the effect I desired.
>
>> The aqua terminal behaves differently. The command below produce a
>> change in the window size.
>>
>> 	set term aqua 1 size 500 400
>> 	plot sin(x)
>> 	set term aqua 1 size 500 200
>> 	plot sin(x)
>>
>> Unfortunately, there is no "close" option for the aqua terminal.
>
> I don't know that much about the aqua terminal, and its project page  
> on
> SourceForge appears moribund.   The documentation for use with  
> gnuplot,
> for instance, still refers to gnuplot version 3.8.
>
> I tried to stir up interest over there to at least release the  
> existing
> 2-year-old aquaterm version 1.1 that includes support for  
> transparency,
> but even that hasn't happened. "Close" sounds like it would be a  
> trivial
> change, but it won't help anyone unless/until the aquaterm developers
> are willing to release and distribute a version that supports it.
>
> Perhaps you will be more successful than I was in prodding them to  
> make
> a new release. I was told back in June that "the code is set for a 1.1
> release, but needs testing on Intel Macs and 10.5.x".  Maybe if you
> volunteer to be a tester, they will make a release candidate for you
> to test?

It should be simple enough for me to make a local package for my  
package management system (Fink with descends from Debian).

> The project website is here:
>    https://sourceforge.net/projects/aquaterm/
>
> And some people to prod are here:
>    hba...@us...
>    ama...@us...
>    per...@ma...

Ok. I'll add that to my list of things to look at.

>> In any event, you've revealed another solution to me. I'll use  
>> "close"
>> for the x11 terminal before updating the plot window.
>>
>>>> (at least wxt
>>>> did before I began running 4.3+, not the wxt terminal does not work
>>>> for me).
>>>
>>> Are you saying that you have observed a recent regression in wxt?
>>> Please file a separate bug report. I am not aware of any outstanding
>>> problems other than the general incompatibility with Mac OSX.
>>
>> I assume the wxt terminal is working. Thus, I'll invest some effort
>> ensuring I have everything set up correctly. Just to be sure, what wx
>> version is needed? I have wxmac 2.8.3 installed.
>
> So far as I know, the wxt terminal has never worked under OSX;
> I've been told that the control flow is inherently incompatible with  
> the
> OSX graphics model.  Timothée Lecomte has been working on a re- 
> design that
> would allow it, but he doesn't have much time to devote to it.

Strange. There are some lunix gui related things that Mac OSX has  
trouble with.

I had occasionally run the wxt terminal with gnuplot 4.2.3 on my Intel  
powerbook and still can on my PPC based powerbook. I played with  
closing the wxt terminal. It works as the x11 terminal does.  
Unfortunately, there is not "size" option for wxt when running gnuplot  
4.2.3.

Since I began building 4.3 from the cvs (on my intel), the wxt  
terminal not worked for me. Is there an easy way to determine what has  
changed ... perhaps the addition of the "size" option is responsible.

Ben

Re: automake , I am is needing help

[<pl...@pi...>]

Ethan Merritt wrote:
> On Monday 29 December 2008 05:12:09 pl...@pi... wrote:
>> Hi,
>>
>> I'm trying to follow the tortuous workings of automake to add a new dir
>> for svg javascript. I am is needing help ;)
> 
> I am a bit confused.
> Are you talking about adding a new directory to the cvs source tree?
> That has nothing in particular to do with automake.
> The commands would be:
>     mkdir temp/javascriptdir
>     cp $my-new-stuff/* temp/javascriptdir
>     cvs add term/javascriptdir
>     cvs commit -m 'Add javascriptdir to the source tree'
> But you can't do that unless you have write access to the cvs tree.

No, that will have to be done later to set up any fixed files to be
distributed like the postscript files but for now I have created them
locally.

What I want to do in ensure the new dir is created and installed by
'make install'. It would seem it has to get included in am__installdirs
but I cant see how.

thanks.

> 
>> I want to copy the use of the postscriptdir and have defined varibable
>> javascriptdir but cannnot see how to add this to the list of installdirs
>> to get it created and populated.
>>
>> term/Makefile:am__installdirs = "$(DESTDIR)$(luadir)"
>> "$(DESTDIR)$(postscriptdir)"
> 
> Still confused, but perhaps you want:
> 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> diff -ur gnuplot/term/Makefile.am.in  gnuplot-cvs/term/Makefile.am.in
> --- gnuplot-old/term/Makefile.am.in 2008-12-23 11:22:18.000000000 -0800
> +++ gnuplot-new/term/Makefile.am.in     2008-12-29 10:44:25.000000000 -0800
> @@ -2,7 +2,7 @@
>  AUTOMAKE_OPTIONS = foreign 1.2h
> 
>  EXTRA_DIST = README Makefile.am.in driver.h impcodes.h \
> -object.h post.h $(CORETERM) PostScript lua
> +object.h post.h $(CORETERM) PostScript lua javascriptdir
> 
>  postscriptdir = $(pkgdatadir)/$(VERSION_MAJOR)/PostScript
> 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> 
> That will ensure that your new directory is included in a tarball of the
> distributed package.  I suggest that naming this directory simply "svg"
> would be better than "javascriptdir", because it might end up holding
> other svg-related things that are not javascript.
> 
> 
>  
>> maybe someone familiar with this could point me in the right direction.
>>
>> I have modified svg.trm to read in a script from that dir and insert it
>> as a <script> tag at the top of the SVG output. That much works so I
>> have a mechanism within gnuplot to add interactive content to svg.
>>
>>
>> thanks , Peter.
> 
> 

brainstorming SVG_INTERACTIVE

[<pl...@pi...>]

Hi Ethan,

I have the basic mechanics in place to add some interactivity to
svg.trm, so  I need to look at how to integrate this into the rest of
gnuplot.

One of the main needs is to sprinkle a few id=xxx markers into the
various path and group elements so they can be identified and
modified via js and the DOM.

If I want to add another arguement to the functions made visisble in
TERM_TABLE that would seem to mean changing every call and also the
terminals that dont support the new features. While feasible, it seems a
bit radical.

It is generally a good idea to have at least one 'joker' arguement as a
structure pointer in such interdependant interfaces. This allows for
future expansion without altering the prototypes and reorganising the
whole code structure.



This is certainly a result of a long running project that has evolved
well beyond it's original objectives. At some stage it may be worth
adding such extra args.


I had a look at the href patch which seems to work by adding a href
variable to some structures and an SVG_href() function to output the
xlink code. This works quite well for the labels and the command syntax
is clear but it looks less robust for more general entities like plots ,
where trying to wrap it needs several flags to keep track of things.

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

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

On Dec 29, 2008, at 1:34 PM, Ethan Merritt wrote:

> On Monday 29 December 2008 10:04:32 Ben Abbott wrote:
>>
>> On Dec 29, 2008, at 12:25 PM, Ethan A Merritt wrote:
>>
>>> On Monday 29 December 2008, Ben Abbott wrote:
>>>
>>>>>>>> Are you suggesting that Octave's plot stream contain only one
>>>>>>>> "set
>>>>>>>> terminal ..."? ... if so by what means is it possible to clear
>>>>>>>> the
>>>>>>>> canvas and start from scratch?
>>>>>>>
>>>>>>> That happens every time you issue a "plot" command.  You don't
>>>>>>> have
>>>>>>> to do anything special.  Although there is a "clear" command if
>>>>>>> for
>>>>>>> some reason you want to blank the window but not draw anything.
>>>>>>
>>>>>> I'm not sure I understand the context correctly, but ... what of
>>>>>> multiplot? ... there can be multiple plot commands that do not
>>>>>> delete
>>>>>> anything correct? ... this is the way Octave draws everything.
>>>>>
>>>>> It probably should not do that.  Do you know why it does?
>>>>
>>>> Octave & Matlab each place multiple plots in each figure window. By
>>>> multiple plots, I mean multiple axes in one window. Some axes might
>>>> be
>>>> 2D of various types and others 3D.
>>>
>>> It seems to me that this would be better done by opening separate
>>> windows
>>> for each plot, perhaps tiled to be adjacent.  That would let you  
>>> edit
>>> and interact with each component plot separately, which is not
>>> possible
>>> for the separate components of a multiplot.
>>>
>>> Easy for me to say - I am neither programming nor using Octave.
>>
>> I agree. However, that would break compatibility with Matlab ...  
>> which
>> is actually what I'm attempting to improve.
>
> Well, I'm totally lost.  I don't understand why it would make any
> difference to the user, other than the gain in functionality.
>
>> Am I correct in inferring that rotation of plots does work but  
>> zooming
>> does not (which is what I observe for Octave's gnuplot windows on Mac
>> OSX).
>
> No, this is not correct.  At least, not if you have correctly  
> described
> how Octave uses multiplot. You cannot interact with the individual
> component plots of a multiplot.  Not zooming, not rotation,
> not mouse tracking, no toggling ruler/grid/logscale, none of that.
> Doing things inside multiplot severely limits the features that
> gnuplot would normally give you automatically.
>
>>> you still have not explained why you (or Octave) would
>>> want to close and re-open the terminal plot window before starting
>>> a new plot.  What do you gain by this?
>>
>> Opps, I apparently wasn't clear in my description.
>>
>> Octave may have many plot windows open simultaneously.  Each gnuplot
>> window contains one Octave figure whose objects may be modified via a
>> command line interface at the users discretion. The user may close a
>> figure's window either via the mouse or via the command line.
>>
>> I've added support for the position and size options of the x11
>> terminal to my local code for octave. I notice that the x11 terminal
>> only respects these properties for the first instance of "set termina
>> x11 ..." in the plot stream. This is different than how the aqua and
>> wxt terminals behave. Meaning that each time I change the terminals
>> size, both the aqua and wxt windows change their size
>
>
> I think you are either doing something wrong, or failing to explain
> the difference between what you are seeing and what you are expecting.
> The following sequence of commands will open three separate x11 plot
> windows with different sizes.  Each window can be managed separately.
> This behaviour may not be truly identical to that for wxt, but so far
> as I know the differences are subtle rather than dramatic.
> Do you have a counter-example?
>
>    set term x11 1 title "Plot window #1"
>    plot foo
>    set term x11 2 title "Plot window #2"
>    splot baz
>    set term x11 3 title "3rd plot window"
>    plot blech
>
>    # Close window 2, leave 1 and 3 unchanged:
>    set term x11 2 close
>
>    # Replace the contents of window 1, leaving window 3 unchanged
>    set term x11 1
>    plot new-stuff
>
>
>> Would it be possible for the x11 terminal to behave in the same  
>> manner?
>
> Please describe "same manner" more explicitly.'

Ok, try this

	set term x11 1 size 500,400 position 100,100
	plot sin(x)
	set term x11 1 size 500,200 position 300,100
	close 1
	plot sin(x)

After the second plot command the window remains the same size and in  
the same position as the first.

If I use the mouse to close the window prior to the second "plot  
sin(x)" then I get the effect I desire.

Regarding my expectations, you are correct, I associated gnuplot's  
"close" option with deleting the window and all its options. I tried  
inserting a "set term x11 1 close"  after the first "plot sin(x)" and  
prior to the second and I got the effect I desired.

The aqua terminal behaves differently. The command below produce a  
change in the window size.

	set term aqua 1 size 500 400
	plot sin(x)
	set term aqua 1 size 500 200
	plot sin(x)

Unfortunately, there is no "close" option for the aqua terminal.

In any event, you've revealed another solution to me. I'll use "close"  
for the x11 terminal before updating the plot window.

>> (at least wxt
>> did before I began running 4.3+, not the wxt terminal does not work
>> for me).
>
> Are you saying that you have observed a recent regression in wxt?
> Please file a separate bug report. I am not aware of any outstanding
> problems other than the general incompatibility with Mac OSX.

I assume the wxt terminal is working. Thus, I'll invest some effort  
ensuring I have everything set up correctly. Just to be sure, what wx  
version is needed? I have wxmac 2.8.3 installed.

Ben

Re: automake , I am is needing help

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

On Monday 29 December 2008 05:12:09 pl...@pi... wrote:
> Hi,
> 
> I'm trying to follow the tortuous workings of automake to add a new dir
> for svg javascript. I am is needing help ;)

I am a bit confused.
Are you talking about adding a new directory to the cvs source tree?
That has nothing in particular to do with automake.
The commands would be:
    mkdir temp/javascriptdir
    cp $my-new-stuff/* temp/javascriptdir
    cvs add term/javascriptdir
    cvs commit -m 'Add javascriptdir to the source tree'
But you can't do that unless you have write access to the cvs tree.

> I want to copy the use of the postscriptdir and have defined varibable
> javascriptdir but cannnot see how to add this to the list of installdirs
> to get it created and populated.
> 
> term/Makefile:am__installdirs = "$(DESTDIR)$(luadir)"
> "$(DESTDIR)$(postscriptdir)"

Still confused, but perhaps you want:

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
diff -ur gnuplot/term/Makefile.am.in  gnuplot-cvs/term/Makefile.am.in
--- gnuplot-old/term/Makefile.am.in 2008-12-23 11:22:18.000000000 -0800
+++ gnuplot-new/term/Makefile.am.in     2008-12-29 10:44:25.000000000 -0800
@@ -2,7 +2,7 @@
 AUTOMAKE_OPTIONS = foreign 1.2h

 EXTRA_DIST = README Makefile.am.in driver.h impcodes.h \
-object.h post.h $(CORETERM) PostScript lua
+object.h post.h $(CORETERM) PostScript lua javascriptdir

 postscriptdir = $(pkgdatadir)/$(VERSION_MAJOR)/PostScript

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

That will ensure that your new directory is included in a tarball of the
distributed package.  I suggest that naming this directory simply "svg"
would be better than "javascriptdir", because it might end up holding
other svg-related things that are not javascript.


 
> maybe someone familiar with this could point me in the right direction.
> 
> I have modified svg.trm to read in a script from that dir and insert it
> as a <script> tag at the top of the SVG output. That much works so I
> have a mechanism within gnuplot to add interactive content to svg.
> 
> 
> thanks , Peter.


-- 
Ethan A Merritt

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

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

On Monday 29 December 2008 10:04:32 Ben Abbott wrote:
> 
> On Dec 29, 2008, at 12:25 PM, Ethan A Merritt wrote:
> 
> > On Monday 29 December 2008, Ben Abbott wrote:
> >
> >>>>>> Are you suggesting that Octave's plot stream contain only one  
> >>>>>> "set
> >>>>>> terminal ..."? ... if so by what means is it possible to clear  
> >>>>>> the
> >>>>>> canvas and start from scratch?
> >>>>>
> >>>>> That happens every time you issue a "plot" command.  You don't  
> >>>>> have
> >>>>> to do anything special.  Although there is a "clear" command if  
> >>>>> for
> >>>>> some reason you want to blank the window but not draw anything.
> >>>>
> >>>> I'm not sure I understand the context correctly, but ... what of
> >>>> multiplot? ... there can be multiple plot commands that do not  
> >>>> delete
> >>>> anything correct? ... this is the way Octave draws everything.
> >>>
> >>> It probably should not do that.  Do you know why it does?
> >>
> >> Octave & Matlab each place multiple plots in each figure window. By
> >> multiple plots, I mean multiple axes in one window. Some axes might  
> >> be
> >> 2D of various types and others 3D.
> >
> > It seems to me that this would be better done by opening separate  
> > windows
> > for each plot, perhaps tiled to be adjacent.  That would let you edit
> > and interact with each component plot separately, which is not  
> > possible
> > for the separate components of a multiplot.
> >
> > Easy for me to say - I am neither programming nor using Octave.
> 
> I agree. However, that would break compatibility with Matlab ... which  
> is actually what I'm attempting to improve.

Well, I'm totally lost.  I don't understand why it would make any
difference to the user, other than the gain in functionality.


> Am I correct in inferring that rotation of plots does work but zooming  
> does not (which is what I observe for Octave's gnuplot windows on Mac  
> OSX).

No, this is not correct.  At least, not if you have correctly described
how Octave uses multiplot. You cannot interact with the individual
component plots of a multiplot.  Not zooming, not rotation, 
not mouse tracking, no toggling ruler/grid/logscale, none of that.
Doing things inside multiplot severely limits the features that
gnuplot would normally give you automatically.

> > you still have not explained why you (or Octave) would
> > want to close and re-open the terminal plot window before starting
> > a new plot.  What do you gain by this?
> 
> Opps, I apparently wasn't clear in my description.
> 
> Octave may have many plot windows open simultaneously.  Each gnuplot  
> window contains one Octave figure whose objects may be modified via a  
> command line interface at the users discretion. The user may close a  
> figure's window either via the mouse or via the command line.
> 
> I've added support for the position and size options of the x11  
> terminal to my local code for octave. I notice that the x11 terminal  
> only respects these properties for the first instance of "set termina  
> x11 ..." in the plot stream. This is different than how the aqua and  
> wxt terminals behave. Meaning that each time I change the terminals  
> size, both the aqua and wxt windows change their size 


I think you are either doing something wrong, or failing to explain
the difference between what you are seeing and what you are expecting.
The following sequence of commands will open three separate x11 plot
windows with different sizes.  Each window can be managed separately.
This behaviour may not be truly identical to that for wxt, but so far
as I know the differences are subtle rather than dramatic.
Do you have a counter-example?

    set term x11 1 title "Plot window #1"
    plot foo
    set term x11 2 title "Plot window #2"
    splot baz
    set term x11 3 title "3rd plot window"
    plot blech

    # Close window 2, leave 1 and 3 unchanged:
    set term x11 2 close

    # Replace the contents of window 1, leaving window 3 unchanged
    set term x11 1
    plot new-stuff


> Would it be possible for the x11 terminal to behave in the same manner?

Please describe "same manner" more explicitly.

> (at least wxt    
> did before I began running 4.3+, not the wxt terminal does not work  
> for me).

Are you saying that you have observed a recent regression in wxt?
Please file a separate bug report. I am not aware of any outstanding
problems other than the general incompatibility with Mac OSX.

> btw, if there are not know problem with the wxt terminal, let me know  
> and I'll submit a bug report.

Please do.


-- 
Ethan A Merritt

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

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

On Dec 29, 2008, at 12:25 PM, Ethan A Merritt wrote:

> On Monday 29 December 2008, Ben Abbott wrote:
>
>>>>>> Are you suggesting that Octave's plot stream contain only one  
>>>>>> "set
>>>>>> terminal ..."? ... if so by what means is it possible to clear  
>>>>>> the
>>>>>> canvas and start from scratch?
>>>>>
>>>>> That happens every time you issue a "plot" command.  You don't  
>>>>> have
>>>>> to do anything special.  Although there is a "clear" command if  
>>>>> for
>>>>> some reason you want to blank the window but not draw anything.
>>>>
>>>> I'm not sure I understand the context correctly, but ... what of
>>>> multiplot? ... there can be multiple plot commands that do not  
>>>> delete
>>>> anything correct? ... this is the way Octave draws everything.
>>>
>>> It probably should not do that.  Do you know why it does?
>>
>> Octave & Matlab each place multiple plots in each figure window. By
>> multiple plots, I mean multiple axes in one window. Some axes might  
>> be
>> 2D of various types and others 3D.
>
> It seems to me that this would be better done by opening separate  
> windows
> for each plot, perhaps tiled to be adjacent.  That would let you edit
> and interact with each component plot separately, which is not  
> possible
> for the separate components of a multiplot.
>
> Easy for me to say - I am neither programming nor using Octave.

I agree. However, that would break compatibility with Matlab ... which  
is actually what I'm attempting to improve.

>>>> My impression is that Octave relies upon "set terminal ..." to  
>>>> clear
>>>> the canvas, but if "clear" does that, I'd rather go that route.
>>>
>>> Clear can be used inside of a stream of multiplot commands,
>>> whereas resetting the terminal obviously cannot.  So it you really  
>>> are
>>> using multiplot to draw new plots for some reason, "clear" is
>>> the way to go.
>>
>> Octave doesn't reset the terminal while multiplot is one. Rather it
>> (1) sets the terminal, (2) turns on multiplot, (3) draws all axes /
>> graphics objects, (4) turns off multiplot. When an object of the
>> figure is changed, the sequence is repeated.
>
> As I said above, this approach seems very cumbersome compared to
> drawing and maintaining each component plot on its own.  If nothing  
> else,
> maintaining them in parallel would allow mouse interactions to  
> continue
> in parallel, whereas mousing within a multiplot is very limited.

Am I correct in inferring that rotation of plots does work but zooming  
does not (which is what I observe for Octave's gnuplot windows on Mac  
OSX).

> Aside from that, you still have not explained why you (or Octave)  
> would
> want to close and re-open the terminal plot window before starting a
> new plot.  What do you gain by this?

Opps, I apparently wasn't clear in my description.

Octave may have many plot windows open simultaneously.  Each gnuplot  
window contains one Octave figure whose objects may be modified via a  
command line interface at the users discretion. The user may close a  
figure's window either via the mouse or via the command line.

I've added support for the position and size options of the x11  
terminal to my local code for octave. I notice that the x11 terminal  
only respects these properties for the first instance of "set termina  
x11 ..." in the plot stream. This is different than how the aqua and  
wxt terminals behave. Meaning that each time I change the terminals  
size, both the aqua and wxt windows change their size (at least wxt   
did before I began running 4.3+, not the wxt terminal does not work  
for me).

Would it be possible for the x11 terminal to behave in the same manner?

btw, if there are not know problem with the wxt terminal, let me know  
and I'll submit a bug report.

>> At the moment, my modification to the plotstream has introduced some
>> problems, so my understanding is suspect.
>>
>>>>>> 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.
>>
>> If it would work under Windows as well, then I certainly would like  
>> to
>> have that. How might octave access the information? Would v_char =
>> getenv ("GPVAL_TERM_VCHAR") do the trick (assuming you're speaking of
>> the shell environment and both octave and gnuplot are sharing the  
>> same
>> environment ... are they?) or is some other method needed?
>
> If you are sending commands to gnuplot, you can just refer to that
> variable by name.  If you need to pass it back from gnuplot to the
> calling program, then it is probably best to set up full two-way
> communication via pipes.

ok. When I get that far, I'll likely be back on the help list.

>>>> In any event, I've got plenty of new information to assimilate. I
>>>> should spend some time applying what (I think) I have learned and
>>>> then
>>>> come back.
>>>>
>>>> Regarding my original problem, if there is a desire to change
>>>> gnuplot,
>>>> I'm happy to help out (if I can) or solicit some help for a MacOSX
>>>> user with better programming skills than myself.
>>>
>>> Well, if someone can figure out which bit of code in gplt_x11.c is
>>> getting called erroneously in your original trials, I'd be happy to
>>> help design a fix for it.  But since I can't reproduce the problem
>>> here,
>>> I am entirely dependent on someone else to pin down the precise  
>>> source
>>> of the error.
>>
>> ok. I have one of octave's contributers in mind who may be inclined  
>> to
>> help out.
>>
>> Ben
> -- 
> Ethan A Merritt
> Biomolecular Structure Center
> University of Washington, Seattle 98195-7742

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

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

On Monday 29 December 2008, Ben Abbott wrote:

> >>>> Are you suggesting that Octave's plot stream contain only one "set
> >>>> terminal ..."? ... if so by what means is it possible to clear the
> >>>> canvas and start from scratch?
> >>>
> >>> That happens every time you issue a "plot" command.  You don't have
> >>> to do anything special.  Although there is a "clear" command if for
> >>> some reason you want to blank the window but not draw anything.
> >>
> >> I'm not sure I understand the context correctly, but ... what of
> >> multiplot? ... there can be multiple plot commands that do not delete
> >> anything correct? ... this is the way Octave draws everything.
> >
> > It probably should not do that.  Do you know why it does?
> 
> Octave & Matlab each place multiple plots in each figure window. By  
> multiple plots, I mean multiple axes in one window. Some axes might be  
> 2D of various types and others 3D.

It seems to me that this would be better done by opening separate windows
for each plot, perhaps tiled to be adjacent.  That would let you edit
and interact with each component plot separately, which is not possible
for the separate components of a multiplot.

Easy for me to say - I am neither programming nor using Octave.

> >> My impression is that Octave relies upon "set terminal ..." to clear
> >> the canvas, but if "clear" does that, I'd rather go that route.
> >
> > Clear can be used inside of a stream of multiplot commands,
> > whereas resetting the terminal obviously cannot.  So it you really are
> > using multiplot to draw new plots for some reason, "clear" is
> > the way to go.
> 
> Octave doesn't reset the terminal while multiplot is one. Rather it  
> (1) sets the terminal, (2) turns on multiplot, (3) draws all axes /  
> graphics objects, (4) turns off multiplot. When an object of the  
> figure is changed, the sequence is repeated.

As I said above, this approach seems very cumbersome compared to
drawing and maintaining each component plot on its own.  If nothing else,
maintaining them in parallel would allow mouse interactions to continue
in parallel, whereas mousing within a multiplot is very limited.

Aside from that, you still have not explained why you (or Octave) would
want to close and re-open the terminal plot window before starting a
new plot.  What do you gain by this?


> At the moment, my modification to the plotstream has introduced some  
> problems, so my understanding is suspect.
> 
> >>>> 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.
> 
> If it would work under Windows as well, then I certainly would like to  
> have that. How might octave access the information? Would v_char =  
> getenv ("GPVAL_TERM_VCHAR") do the trick (assuming you're speaking of  
> the shell environment and both octave and gnuplot are sharing the same  
> environment ... are they?) or is some other method needed?

If you are sending commands to gnuplot, you can just refer to that
variable by name.  If you need to pass it back from gnuplot to the
calling program, then it is probably best to set up full two-way
communication via pipes.








> >> In any event, I've got plenty of new information to assimilate. I
> >> should spend some time applying what (I think) I have learned and  
> >> then
> >> come back.
> >>
> >> Regarding my original problem, if there is a desire to change  
> >> gnuplot,
> >> I'm happy to help out (if I can) or solicit some help for a MacOSX
> >> user with better programming skills than myself.
> >
> > Well, if someone can figure out which bit of code in gplt_x11.c is
> > getting called erroneously in your original trials, I'd be happy to
> > help design a fix for it.  But since I can't reproduce the problem  
> > here,
> > I am entirely dependent on someone else to pin down the precise source
> > of the error.
> 
> ok. I have one of octave's contributers in mind who may be inclined to  
> help out.
> 
> Ben
> 
> 



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

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

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

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:
>>>
>>>>> So now I have another question.
>>>>> You are re-opening the same x11 display window for every plot.
>>>>> I don't understand why you want to do that, since you could just
>>>>> leave
>>>>> the previous window in place if the size is not supposed to  
>>>>> change.
>>>>>
>>>>> Be that as it may, you could try explicitly closing the previous
>>>>> window
>>>>> before re-opening it:
>>>>>
>>>>>  set term x11 1 size FOO,BAZ
>>>>>  ...plot stuff
>>>>>
>>>>>  set term x11 1 close
>>>>>  set term x11 1 size FOO,BAZ
>>>>>  ...plot different stuff
>>>>
>>>> I'm a bit uncertain about the terminology.
>>>>
>>>> What I understand is done in Octave is that a plot stream is opened
>>>> for a figure and it is not closed until the figure is deleted/ 
>>>> closed.
>>>
>>> Maybe. But you are talking about the stream from Octave to gnuplot,
>>> I think? Rather than the stream from gnuplot to gnuplot_x11?
>>
>> Correct, I speaking of the plot stream from Octave to gnuplot (my
>> knowledge of how gnuplot works is nil)
>>
>>>> Are you suggesting that Octave's plot stream contain only one "set
>>>> terminal ..."? ... if so by what means is it possible to clear the
>>>> canvas and start from scratch?
>>>
>>> That happens every time you issue a "plot" command.  You don't have
>>> to do anything special.  Although there is a "clear" command if for
>>> some reason you want to blank the window but not draw anything.
>>
>> I'm not sure I understand the context correctly, but ... what of
>> multiplot? ... there can be multiple plot commands that do not delete
>> anything correct? ... this is the way Octave draws everything.
>
> It probably should not do that.  Do you know why it does?

Octave & Matlab each place multiple plots in each figure window. By  
multiple plots, I mean multiple axes in one window. Some axes might be  
2D of various types and others 3D.

>> My impression is that Octave relies upon "set terminal ..." to clear
>> the canvas, but if "clear" does that, I'd rather go that route.
>
> Clear can be used inside of a stream of multiplot commands,
> whereas resetting the terminal obviously cannot.  So it you really are
> using multiplot to draw new plots for some reason, "clear" is
> the way to go.

Octave doesn't reset the terminal while multiplot is one. Rather it  
(1) sets the terminal, (2) turns on multiplot, (3) draws all axes /  
graphics objects, (4) turns off multiplot. When an object of the  
figure is changed, the sequence is repeated.

At the moment, my modification to the plotstream has introduced some  
problems, so my understanding is suspect.

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

If it would work under Windows as well, then I certainly would like to  
have that. How might octave access the information? Would v_char =  
getenv ("GPVAL_TERM_VCHAR") do the trick (assuming you're speaking of  
the shell environment and both octave and gnuplot are sharing the same  
environment ... are they?) or is some other method needed?

>> In any event, I've got plenty of new information to assimilate. I
>> should spend some time applying what (I think) I have learned and  
>> then
>> come back.
>>
>> Regarding my original problem, if there is a desire to change  
>> gnuplot,
>> I'm happy to help out (if I can) or solicit some help for a MacOSX
>> user with better programming skills than myself.
>
> Well, if someone can figure out which bit of code in gplt_x11.c is
> getting called erroneously in your original trials, I'd be happy to
> help design a fix for it.  But since I can't reproduce the problem  
> here,
> I am entirely dependent on someone else to pin down the precise source
> of the error.

ok. I have one of octave's contributers in mind who may be inclined to  
help out.

Ben

automake , I am is needing help

[<pl...@pi...>]

Hi,

I'm trying to follow the tortuous workings of automake to add a new dir
for svg javascript. I am is needing help ;)

I want to copy the use of the postscriptdir and have defined varibable
javascriptdir but cannnot see how to add this to the list of installdirs
to get it created and populated.

term/Makefile:am__installdirs = "$(DESTDIR)$(luadir)"
"$(DESTDIR)$(postscriptdir)"


maybe someone familiar with this could point me in the right direction.

I have modified svg.trm to read in a script from that dir and insert it
as a <script> tag at the top of the SVG output. That much works so I
have a mechanism within gnuplot to add interactive content to svg.


thanks , Peter.

gnuplot 4.3 (cvs) cygwin, windows and djgpp binaries updated (ChangeLog Date 2008-12-27)

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

Hello

I have prepared gnuplot 4.3 (cvs) for cygwin, windows and djgpp binaries prepared by gcc 4.3.x.
(latest ChangeLog date: 2008-12-27)

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

http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/
windows and djgpp binaries

Regards

Tatsuro



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

Re: links to gnuplot online documentation

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

On Sunday 28 December 2008, Ralf Juengling wrote:
> Hello,
> 
> I am working on a language interface for gnuplot
> which is pretty close to the gnuplot plotting command
> language. For instance, for every plotting style my
> interface has a corresponding function for adding
> a line to a graph/plot.
> 
> I want to take advantage of this close correspondence
> and refer to the gnuplot online documentation in the
> help texts for my interface. I see that the online
> documentation for the current development version
> has anchors to the plotting styles, like
> 
> http://www.gnuplot.info/docs_4.3/gnuplot.html#lines.
> 
> Will this url eventually be
> 
> http://www.gnuplot.info/docs/gnuplot.html#lines
> 
> ? The current link to plotting style 'lines' is
> 
> http://www.gnuplot.info/docs/node254.html
> 
> which does not look like a stable url. Are there plans
> for more stable and systematic urls to the gnuplot
> online documentation?


The html documentation is created automatically from the
TeX documentation. At least two paths exist to do this,
latex2html and "makeinfo -html".  Both have some problems,
and latex2html is no longer being actively maintained that
I know of.  So it's kind of out of our control.

If you are aware of some other path to generate html pages
from a *.tex document or perhaps from a *.pdf document,
please speak up!


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

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

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

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:
> >
> >>> So now I have another question.
> >>> You are re-opening the same x11 display window for every plot.
> >>> I don't understand why you want to do that, since you could just  
> >>> leave
> >>> the previous window in place if the size is not supposed to change.
> >>>
> >>> Be that as it may, you could try explicitly closing the previous
> >>> window
> >>> before re-opening it:
> >>>
> >>>   set term x11 1 size FOO,BAZ
> >>>   ...plot stuff
> >>>
> >>>   set term x11 1 close
> >>>   set term x11 1 size FOO,BAZ
> >>>   ...plot different stuff
> >>
> >> I'm a bit uncertain about the terminology.
> >>
> >> What I understand is done in Octave is that a plot stream is opened
> >> for a figure and it is not closed until the figure is deleted/closed.
> >
> > Maybe. But you are talking about the stream from Octave to gnuplot,
> > I think? Rather than the stream from gnuplot to gnuplot_x11?
> 
> Correct, I speaking of the plot stream from Octave to gnuplot (my  
> knowledge of how gnuplot works is nil)
> 
> >> Are you suggesting that Octave's plot stream contain only one "set
> >> terminal ..."? ... if so by what means is it possible to clear the
> >> canvas and start from scratch?
> >
> > That happens every time you issue a "plot" command.  You don't have
> > to do anything special.  Although there is a "clear" command if for
> > some reason you want to blank the window but not draw anything.
> 
> I'm not sure I understand the context correctly, but ... what of  
> multiplot? ... there can be multiple plot commands that do not delete  
> anything correct? ... this is the way Octave draws everything. 

It probably should not do that.  Do you know why it does?

> My impression is that Octave relies upon "set terminal ..." to clear 
> the canvas, but if "clear" does that, I'd rather go that route.

Clear can be used inside of a stream of multiplot commands,
whereas resetting the terminal obviously cannot.  So it you really are 
using multiplot to draw new plots for some reason, "clear" is
the way to go.

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

 > In any event, I've got plenty of new information to assimilate. I  
> should spend some time applying what (I think) I have learned and then  
> come back.
> 
> Regarding my original problem, if there is a desire to change gnuplot,  
> I'm happy to help out (if I can) or solicit some help for a MacOSX  
> user with better programming skills than myself.

Well, if someone can figure out which bit of code in gplt_x11.c is 
getting called erroneously in your original trials, I'd be happy to
help design a fix for it.  But since I can't reproduce the problem here,
I am entirely dependent on someone else to pin down the precise source
of the error.

-- 
Ethan A Merritt

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

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

On Dec 28, 2008, at 9:10 PM, Ethan A Merritt wrote:

> On Sunday 28 December 2008, Ben Abbott wrote:
>
>>> So now I have another question.
>>> You are re-opening the same x11 display window for every plot.
>>> I don't understand why you want to do that, since you could just  
>>> leave
>>> the previous window in place if the size is not supposed to change.
>>>
>>> Be that as it may, you could try explicitly closing the previous
>>> window
>>> before re-opening it:
>>>
>>>   set term x11 1 size FOO,BAZ
>>>   ...plot stuff
>>>
>>>   set term x11 1 close
>>>   set term x11 1 size FOO,BAZ
>>>   ...plot different stuff
>>
>> I'm a bit uncertain about the terminology.
>>
>> What I understand is done in Octave is that a plot stream is opened
>> for a figure and it is not closed until the figure is deleted/closed.
>
> Maybe. But you are talking about the stream from Octave to gnuplot,
> I think? Rather than the stream from gnuplot to gnuplot_x11?

Correct, I speaking of the plot stream from Octave to gnuplot (my  
knowledge of how gnuplot works is nil)

>> Are you suggesting that Octave's plot stream contain only one "set
>> terminal ..."? ... if so by what means is it possible to clear the
>> canvas and start from scratch?
>
> That happens every time you issue a "plot" command.  You don't have
> to do anything special.  Although there is a "clear" command if for
> some reason you want to blank the window but not draw anything.

I'm not sure I understand the context correctly, but ... what of  
multiplot? ... there can be multiple plot commands that do not delete  
anything correct? ... this is the way Octave draws everything. My  
impression is that Octave relies upon "set terminal ..." to clear the  
canvas, but if "clear" does that, I'd rather go that route.

>> It is not permissible for Octave to close the window and open a new
>> stream/window, as this would be a significant deviation from how
>> Matlab works and compatibility with Matlab is a rather important
>> feature.
>
> ?? But that seems to be what your test script is doing already.

Yes.  However, but I hope to overcome that problem, or at the least  
allow the user to specify size and position via Octave's figure  
properties.

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

In any event, I've got plenty of new information to assimilate. I  
should spend some time applying what (I think) I have learned and then  
come back.

Regarding my original problem, if there is a desire to change gnuplot,  
I'm happy to help out (if I can) or solicit some help for a MacOSX  
user with better programming skills than myself.

Thanks
Ben

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

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

On Sunday 28 December 2008, Ben Abbott wrote:

> > So now I have another question.
> > You are re-opening the same x11 display window for every plot.
> > I don't understand why you want to do that, since you could just leave
> > the previous window in place if the size is not supposed to change.
> >
> > Be that as it may, you could try explicitly closing the previous  
> > window
> > before re-opening it:
> >
> >    set term x11 1 size FOO,BAZ
> >    ...plot stuff
> >
> >    set term x11 1 close
> >    set term x11 1 size FOO,BAZ
> >    ...plot different stuff
> 
> I'm a bit uncertain about the terminology.
> 
> What I understand is done in Octave is that a plot stream is opened  
> for a figure and it is not closed until the figure is deleted/closed.

Maybe. But you are talking about the stream from Octave to gnuplot,
I think? Rather than the stream from gnuplot to gnuplot_x11?
 
> Are you suggesting that Octave's plot stream contain only one "set  
> terminal ..."? ... if so by what means is it possible to clear the  
> canvas and start from scratch?

That happens every time you issue a "plot" command.  You don't have
to do anything special.  Although there is a "clear" command if for
some reason you want to blank the window but not draw anything.

 > It is not permissible for Octave to close the window and open a new  
> stream/window, as this would be a significant deviation from how  
> Matlab works and compatibility with Matlab is a rather important  
> feature. 

?? But that seems to be what your test script is doing already.

> Meaning a specific plot window should not change size/  
> position unless the user specifically tells it to (which might be the  
> result of actions by the mouse).

Again, that's what has always been the case for gnuplot also,
and the ability to specify the initial size does not change it.

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



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

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

[<pl...@pi...>]

Ben Abbott wrote:

>>>> Ben
>> So this seems to confirm my suggestion that it is related to the  
>> window
>> being stretched to add the cursor output zone. There is probably some
>> difference in the way events are triggered and processed on OSX that
>> leads to it getting several mouse events, each one pumping the window
>> height.
>>
>> Can you arrange it so that your mouse is away from where the x window
>> appears so that there is no mouse events? On linux that will give a  
>> plot
>> with no extra space for mouse position output.
>>
>> On linux a static mouse in the window's area whenit comes up does not
>> cause any output or window increase until it is moved. I think that is
>> where the difference lies.
> 
> Mouse oriented focus doens't make any difference. However, your  
> question did ring a bell.
> 
> The X11 on Mac OSX has preferences for (1) Focus Follows Mouse and/or  
> (2) Focus On New Windows. I had (1) unchecked and (2) checked.
> 
> With (1) checked and (2) unchecked the problem with the growing window  
> is gone. Nice deduction!
> 
> Ben
> 
> 

I tried those focus settings on linux and it still works correctly.

one can see the extra bit of window flash in and out and finally
remaining off until there is some mouse action.

It seems the event that would reduce the extra area is either not firing
or getting purged without having effect.

This is probably going to need someone on a Mac to do some debugging.

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

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

On Dec 28, 2008, at 4:32 PM, Ethan A Merritt wrote:

> On Sunday 28 December 2008, Ben Abbott wrote:
>>
>> On Dec 28, 2008, at 4:12 PM, Ethan A Merritt wrote:
>>
>>> On Sunday 28 December 2008, you wrote:
>>>>
>>>> On Dec 28, 2008, at 3:31 PM, Ethan A Merritt wrote:
>>>>
>>>>> On Sunday 28 December 2008, you wrote:
>>>>>>
>>>>>> On Dec 28, 2008, at 1:53 PM, Ethan A Merritt wrote:
>>>>>>
>>>>>>> On Sunday 28 December 2008, Ben Abbott wrote:
>>>>>>>>
>>>>>>>> On Dec 28, 2008, at 1:59 AM, Ethan A Merritt wrote:
>>>>>>>>
>>>>>>>>> On Saturday 27 December 2008, Ben Abbott wrote:
>>>>>>>>>>
>>>>>>>>>> I've concatenated several plot streams produced by Octave to
>>>>>>>>>> demonstrate what
>>>>>>>>>> I am seeing. The file is attached.
>>>>>>>>>>> Just type the command below. The resulting plot should  
>>>>>>>>>>> grow in
>>>>>>>>>>> height each
>>>>>>>>>> time it is plotted.
>>>>>>>>>
>>>>>>>>> I see no change in the plot window size; each plot is redrawn
>>>>>>>>> exactly on top
>>>>>>>>> of the previous one.  My machine is running
>>>>>>>>> x11-server-xorg-1.4.0.90
>>>>>>>>> kdebase-kdm-3.5.9
>>>>>>>>>
>>>>>>>>> I think that to debug this we will need to know your operating
>>>>>>>>> system
>>>>>>>>> environment, and in particular the window manager and the X-
>>>>>>>>> server
>>>>>>>>> being used.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I'm running Mac OSX 10.5.6 and with the X-server XQuartz 2.3.1.
>>>>>>>> If by
>>>>>>>> "operating system environment" you're looking for more than I
>>>>>>>> gave,
>>>>>>>> let me know what it is you'd like to see. For more info on
>>>>>>>> XQuartx
>>>>>>>> see
>>>>>>>> the link below.
>>>>>>>>
>>>>>>>> 	http://xquartz.macosforge.org/trac/wiki
>>>>>>>>
>>>>>>>> I've spent some time reducing the number of gnuplot commands
>>>>>>>> needed
>>>>>>>> to
>>>>>>>> produce the problem. If the 4 lines below are placed  
>>>>>>>> iteratively
>>>>>>>> in a
>>>>>>>> file, the resulting window progressively grows taller (with the
>>>>>>>> title
>>>>>>>> bar being static).
>>>>>>>>
>>>>>>>> 	set terminal x11 size 560,480 position 440,106
>>>>>>>> 	set multiplot;
>>>>>>>> 	plot x
>>>>>>>> 	unset multiplot;
>>>>>>>>
>>>>>>>> I've attached another file for this simplified example.
>>>>>>>>
>>>>>>>> In any event, the problem appears to only exist (for me) in
>>>>>>>> multiplot
>>>>>>>> mode. I also noticed that the final window height is not always
>>>>>>>> the
>>>>>>>> same.
>>>>>>>
>>>>>>> Could you please try adding the command "unset mouse" to the
>>>>>>> beginning
>>>>>>> of your test script, and check whether that makes any  
>>>>>>> difference?
>>>>>>
>>>>>> bingo!
>>>>>>
>>>>>> When "unset mouse" precedes the first "set terminal x11 ..."
>>>>>> command
>>>>>> the resulting plot is unaware of the mouse.
>>>>>>
>>>>>> However, when I tried ...
>>>>>>
>>>>>> 	set terminal x11 size 560,480 position 440,106
>>>>>> 	set multiplot;
>>>>>> 	plot x
>>>>>> 	unset multiplot;
>>>>>> 	unset mouse
>>>>>>
>>>>>> The tracing of the cursor still works.
>>>>>>
>>>>>> Is this behavior expected/intended? ... meaning; Are the mouse
>>>>>> actions
>>>>>> enabled when the mouse is set and the 1st "set terminal [...]"
>>>>>> command
>>>>>> is encountered? ... and that subsequent "unset mouse" commands  
>>>>>> will
>>>>>> not turn the mouse actions off?
>>>>>>
>>>>>> Ben
>>>>>>
>>>>>> p.s. when the mouse actions are active my x11 window extends  
>>>>>> down a
>>>>>> bit. My impression is that the degree to which it extends is the
>>>>>> same
>>>>>> as the amount the window grows, I assume this was what your were
>>>>>> thinking?
>>>>>
>>>>> Yeah.  Not that it really explains anything.
>>>>>
>>>>> I'll make a wild guess that the problem is related to the code
>>>>> introduced by the comment at line 4284 of gplt_x11.c
>>>>>
>>>>> 4284:
>>>>> /* it seems to be impossible to distinguish between a
>>>>> * resize caused by our call to XResizeWindow(), and
>>>>> * resize started by the user/windowmanager; but we can
>>>>> * make a good guess which can only fail if the user
>>>>> * resizes the window while we're also resizing it
>>>>> * ourselves: */
>>>>>
>>>>> It claims to be working around various window-manager quirks.
>>>>> You could try commenting out various sections of that code, or
>>>>> adding debug statement to keep track of which code path is being
>>>>> triggered. It may be that an additional test, or conditional code
>>>>> for Mac OSX, could bypass the problematic code path.
>>>>
>>>> I'm unskilled unskilled in c/c++. So for my purposes I'll settle  
>>>> with
>>>> including "unset mouse" after "unset multiplot".
>>>>
>>>> Given the qualification above, it appears to me that this will
>>>> produce
>>>> consistent results across different architectures, correct?
>>>
>>> I think we can do better than that.  Turning off mouse interaction
>>> altogether is more drastic than simply turning off the extra space  
>>> at
>>> the bottom of the window that echoes the current coordinates.
>>> What I really wanted to test was the equivalent of toggling the
>>> tracking window via the 'm' hotkey.  But we don't currently have a  
>>> way
>>> of doing that from the command line.
>>>
>>> Petr Mikulik was proposing (maybe even had a patch?) to provide
>>> command line equivalents for all the hotkey operations.  Perhaps he
>>> has a suggestion.
>>>
>>
>> I agree. I have no desire to turn off the mouse interaction.
>>
>> What surprised me is that the mouse interaction still works for me if
>> "unset mouse" occurs after "unset multiplot".
>
>
> So now I have another question.
> You are re-opening the same x11 display window for every plot.
> I don't understand why you want to do that, since you could just leave
> the previous window in place if the size is not supposed to change.
>
> Be that as it may, you could try explicitly closing the previous  
> window
> before re-opening it:
>
>    set term x11 1 size FOO,BAZ
>    ...plot stuff
>
>    set term x11 1 close
>    set term x11 1 size FOO,BAZ
>    ...plot different stuff

I'm a bit uncertain about the terminology.

What I understand is done in Octave is that a plot stream is opened  
for a figure and it is not closed until the figure is deleted/closed.

Are you suggesting that Octave's plot stream contain only one "set  
terminal ..."? ... if so by what means is it possible to clear the  
canvas and start from scratch?

It is not permissible for Octave to close the window and open a new  
stream/window, as this would be a significant deviation from how  
Matlab works and compatibility with Matlab is a rather important  
feature. Meaning a specific plot window should not change size/ 
position unless the user specifically tells it to (which might be the  
result of actions by the mouse).

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

Ben

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

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

On Dec 28, 2008, at 4:30 PM, peter wrote:

> Ben Abbott wrote:
>
>>>>> I've spent some time reducing the number of gnuplot commands
>>>>> needed to
>>>>> produce the problem. If the 4 lines below are placed iteratively
>>>>> in a
>>>>> file, the resulting window progressively grows taller (with the
>>>>> title
>>>>> bar being static).
>>>>>
>>>>> 	set terminal x11 size 560,480 position 440,106
>>>>> 	set multiplot;
>>>>> 	plot x
>>>>> 	unset multiplot;
>>>>>
>>>>> I've attached another file for this simplified example.
>>>>>
>>>>> In any event, the problem appears to only exist (for me) in
>>>>> multiplot
>>>>> mode. I also noticed that the final window height is not always  
>>>>> the
>>>>> same.
>>>> Could you please try adding the command "unset mouse" to the
>>>> beginning
>>>> of your test script, and check whether that makes any difference?
>>> bingo!
>>>
>>> When "unset mouse" precedes the first "set terminal x11 ..." command
>>> the resulting plot is unaware of the mouse.
>>>
>>> However, when I tried ...
>>>
>>> 	set terminal x11 size 560,480 position 440,106
>>> 	set multiplot;
>>> 	plot x
>>> 	unset multiplot;
>>> 	unset mouse
>>>
>>> The tracing of the cursor still works.
>>>
>>> Is this behavior expected/intended? ... meaning; Are the mouse
>>> actions enabled when the mouse is set and the 1st "set terminal
>>> [...]" command is encountered? ... and that subsequent "unset mouse"
>>> commands will not turn the mouse actions off?
>>>
>>> Ben
>>
>
> So this seems to confirm my suggestion that it is related to the  
> window
> being stretched to add the cursor output zone. There is probably some
> difference in the way events are triggered and processed on OSX that
> leads to it getting several mouse events, each one pumping the window
> height.
>
> Can you arrange it so that your mouse is away from where the x window
> appears so that there is no mouse events? On linux that will give a  
> plot
> with no extra space for mouse position output.
>
> On linux a static mouse in the window's area whenit comes up does not
> cause any output or window increase until it is moved. I think that is
> where the difference lies.

Mouse oriented focus doens't make any difference. However, your  
question did ring a bell.

The X11 on Mac OSX has preferences for (1) Focus Follows Mouse and/or  
(2) Focus On New Windows. I had (1) unchecked and (2) checked.

With (1) checked and (2) unchecked the problem with the growing window  
is gone. Nice deduction!

Ben