Menu
▾
▴
gnuplot-beta
|
From: Hans-Bernhard B. <br...@ph...> - 2003-10-24 10:50:46
|
On Thu, 23 Oct 2003, Daniel J Sebald wrote: [...] > 2) If you think the above problem should be modified, > do you feel that > > a) graphics windows should not appear until something > is actually plotted to them Yes. A gnuplot X11 graph window serves no purpose whatsoever until a graph is plotted into it, so there's no point displaying it until that point in time. > With regard to 2, note that if one types "set output 'name'" > followed by no plot commands, but then "set output", the > file 'name' will be created. Is there an analogy here between > a file and a window? Not really. Arguably, that behaviour of 'set output' is wrong itself. > 3) Looking at the X11_options() in x11.trm it is very similar > to other parsing/interpretting schemes, however it doesn't have > the many checks for repeated entry, valid entry, etc. Some > commands are sent to gplt_x11 even before the end of parsing. That's a bug, then. But AFAICS, the only command sent to gplt_x11.c before parsing of the options is finished is an update of the window number. -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
|
From: Daniel J S. <dan...@ie...> - 2003-10-25 23:04:59
|
I believe I have a few simple mods to address points
1 and 2 below. Point 1 is simply a matter of breaking
out of a loop when a number change code 'N' is seen
by Gnuplot. It is then possible to resize all windows
after a "set term x11".
2c below I've ruled out as an alternative. It is confusing
when the windows behave that way. This is accomplished
by doing an X11_init() in the X11_options() of x11.trm.
The ramification of doing this is that the X11 window
must be created even if just a "set term x11" is called.
Why? Looking through the gplt_x11.c code there are
many many places where a pointer in the plot table
called "plot->window" of type Window is used without
testing first if it is valid. Rather than touch up all these
occurrences, I've just made sure the windows are
initialized whenever a new window number is used in some way.
[But really, the proper thing to do would be to check the
sanity of the "plot->window" variable before using it.
The reason is that if the plot being drawn to is destroyed
in some way and "plot->window" gets set back to
zero, gplt_x11 will not crash. E.g., if a slow graph is
drawing and the "destroy" button is pressed.]
The alternatives 2a and 2b are achieved by a simple
mod of:
#define DISPLAY_WINDOW_UPON_CREATION 0
#if DISPLAY_WINDOW_UPON_CREATION
XMapWindow(dpy, plot->window);
#endif
inside the pr_window() routine of gplt_x11.c. If the defined
value is 0 the window is not made visible until something
is actually plotted to it. If the defined value is 1, the empty
window is displayed upon creation, i.e., a "set term x11"
As for issue 3, I may go through and make sure some
reasonable tests for duplicated options is done.
Dan
Daniel J Sebald wrote:
> My original message must have been lost by SF, but I
> don't think it needs resending to clarify the issue. The
> points up to this point are
>
> 1) I think the problem of x11 windows getting stuck
> when only a "set term x11 #" should be fixed at some
> point. Nobody needs to change this, I can do so with
> Petr's help. But, feel free to comment.
>
> 2) If you think the above problem should be modified,
> do you feel that
>
> a) graphics windows should not appear until something
> is actually plotted to them
>
> b) graphics windows should _always_ appear when
> "set term x11 ..." is entered
>
> c) the first x11 window should not appear until something
> is actually plotted, but after that "set term x11 ..." will
> cause a new blank window to appear.
>
> With regard to 2, note that if one types "set output 'name'"
> followed by no plot commands, but then "set output", the
> file 'name' will be created. Is there an analogy here between
> a file and a window?
>
> The next point is
>
> 3) Looking at the X11_options() in x11.trm it is very similar
> to other parsing/interpretting schemes, however it doesn't have
> the many checks for repeated entry, valid entry, etc. Some
> commands are sent to gplt_x11 even before the end of parsing.
> So even if there is something bogus in the "set term x11"
> command, a portion of the command could have been processed.
> Should it do that? Or should it wait until it is known that the whole
> command is valid? For example,
>
> "set term x11 3 "TimesFont""
>
> will show an error message because "font" is missing before
> the font name, but it will in fact change the x11 window to 3.
>
> If you feel point 2b above should be the case, then
>
> "set term x11 1 2 noraise"
>
> where someone mistypes the 12 will cause window 1 and window
> 2 to show on the desktop. In fact, as it currently is
>
> "set term x11 1 2 noraise reset 3 4 raise"
>
> is fine by Gnuplot. Should there be some checks to prevent
> this kind of thing?
>
> Dan
>
>
> Daniel J Sebald wrote:
>
>>
>>
>> Daniel J Sebald wrote:
>>
>>> In other words, from a fresh invocation
>>>
>>> set term x11 3
>>>
>>> creates no window. But
>>>
>>> plot sin(x)
>>> set term x11 3
>>>
>>> creates _two_ windows.
>>
>>
>>
>>
>> You are probably wondering what I mean because the
>> current version doesn't do this, as I just realized. What
>> I am speaking of the system's behavior after an alteration
>> to the 'N' option for changing the X11 window via
>>
>> "set term x11 5"
>>
>> [If you type the following, you'll notice you are unable
>> to resize the first plot... that should be fixed at some
>> point.
>>
>> plot sin(x)
>> set term x11 4
>> {try resizing first plot}]
>>
>> I guess the question boils down to should the command
>>
>> set term x11 7
>>
>> cause an empty X11 window to appear on the desktop
>> if it didn't already exist? Or should it be until after something
>> is actually plotted to the window that it appears on the
>> desktop?
>>
>> Dan
>>
>
--
Dan Sebald
email: daniel . sebald @ ie ee . o rg
URL: ht tp://acer-access.c om/~dsebald @ acer-access.c om/
--
Dan Sebald
email: daniel . sebald @ ie ee . o rg
URL: ht tp://acer-access.c om/~dsebald @ acer-access.c om/
|
|
From: Ethan A M. <merritt@u.washington.edu> - 2003-10-26 03:15:24
|
On Thursday 23 October 2003 11:46 pm, Daniel J Sebald wrote: > Point 1 is simply a matter of breaking > out of a loop when a number change code 'N' is seen > by Gnuplot. It is then possible to resize all windows > after a "set term x11". OK. That sounds like a pure bug-fix. Did you check the rest of that loop to see if all the other options have proper exit code also? > 2c below I've ruled out as an alternative. It is confusing > when the windows behave that way. This is accomplished > by doing an X11_init() in the X11_options() of x11.trm. Are you saying this is only needed for (c)? Or are you proposing to do this for (a) also? > [But really, the proper thing to do would be to check the > sanity of the "plot->window" variable before using it. Or maybe to set this to point at a dummy structure when a window is destroyed, instead of setting it to NULL. > The alternatives 2a and 2b are achieved by a simple > mod of: (b) is to pop up a blank window as soon as the terminal type is set, right? I do not like that idea at all. I'd like to have a look at the proposed code changes before offering a final opinion. -- Ethan A Merritt Department of Biochemistry & Biomolecular Structure Center University of Washington, Seattle |
|
From: Daniel J S. <dan...@ie...> - 2003-10-27 09:31:01
|
Ethan A Merritt wrote: >On Thursday 23 October 2003 11:46 pm, Daniel J Sebald wrote: > > >>Point 1 is simply a matter of breaking >>out of a loop when a number change code 'N' is seen >>by Gnuplot. It is then possible to resize all windows >>after a "set term x11". >> >> > >OK. That sounds like a pure bug-fix. Did you check the >rest of that loop to see if all the other options have proper >exit code also? > There are one or two others, but they are ones for which following commands (always sent by gnuplo)t kick it out of the loop. For example, the 'G' always has other commands immediately following it. The 'N' was the only one where a single command would be issued. But if I remember correctly, just changing the 'N' case so that it kicks out of the loop for the current CVS raises a different problem, one address with the mods I made. >>2c below I've ruled out as an alternative. It is confusing >>when the windows behave that way. This is accomplished >>by doing an X11_init() in the X11_options() of x11.trm. >> >> > >Are you saying this is only needed for (c)? Or are you >proposing to do this for (a) also? > > > >>[But really, the proper thing to do would be to check the >>sanity of the "plot->window" variable before using it. >> >> > >Or maybe to set this to point at a dummy structure when >a window is destroyed, instead of setting it to NULL. > > > >>The alternatives 2a and 2b are achieved by a simple >>mod of: >> >> > >(b) is to pop up a blank window as soon as the terminal >type is set, right? I do not like that idea at all. > Based upon the feedback from you and Hans, the 2a/b/c cases now boil down to "no window appear until when something is plotted." >I'd like to have a look at the proposed code changes >before offering a final opinion. > No problem. I'll make the patch available in a couple days after Petr and I agree it behaves as designed. I think you'll like it. Dan |
|
From: Daniel J S. <dan...@ie...> - 2003-10-24 18:51:26
|
Hans-Bernhard Broeker wrote:
>>With regard to 2, note that if one types "set output 'name'"
>>followed by no plot commands, but then "set output", the
>>file 'name' will be created. Is there an analogy here between
>>a file and a window?
>>
>>
>
>Not really. Arguably, that behaviour of 'set output' is wrong itself.
>
I've looked at the code in term.c regarding opening the file.
It looks like the terminal initialization is very safely done with
appropriate checks of a variable "term_initialised". I'm
wondering if the actual "fopen()" can't be held off until the
function "term_start_plot()". In graphics.c at the start of
the "do_plot()" routine is
term_init(); /* may set xmax/ymax */
term_start_plot();
and in graph3d.c at the start of the "do_plot3d()" routine is
term_start_plot();
[Why there isn't a term_init() there also, I don't know.]
So, it would mean keeping track of the output file name using
a character pointer and realloc() and keeping track of the
binary/ascii file type. In term_start_plot(), check if the file
name is non-NULL, and if so open the file and free()
the memory for the name and set the pointer back to NULL.
Ethan, right before the term_init() call is a note you left
regarding font sizes. Perhaps you are familiar with the
sequence of events and can tell if a simple change is possible.
Does it seem like that would work?
[Different topic below.]
>>3) Looking at the X11_options() in x11.trm it is very similar
>>to other parsing/interpretting schemes, however it doesn't have
>>the many checks for repeated entry, valid entry, etc. Some
>>commands are sent to gplt_x11 even before the end of parsing.
>>
>>
>
>That's a bug, then. But AFAICS, the only command sent to gplt_x11.c
>before parsing of the options is finished is an update of the window
>number.
>
I've added the necessary checks for duplicate entry. At
the end is a #define switch:
if (duplication) {
#if NOT_PROCESS_IF_DUPLICATION
int_error(c_token-1, "duplicated or contradicting arguments in
X11 term options");
#else
if (!shown_warning)
int_warn(c_token-1, "duplicated or contradicting arguments
in X11 term options");
shown_warning = TRUE;
#endif
}
and nothing is done until after that test. I set the variable
NOT_PROCESS_IF_DUPLICATION true simply because
there are a number of situations where what the user enters
could error inside parse.c and util.c. I don't want to modify
anything there in those files to allow continuation.
So it works fine. But I recall something now. I believe there
was a discussion a while back about the ability to close a
single X11 graph from the command line. So perhaps if both
a "reset" and a number appear in the options, only the plot
associated with that number could be closed. Right now it
will reset the whole thing (i.e., close all windows) and then
switch to plot number. How does that sound?
Dan
--
Dan Sebald
email: daniel . sebald @ ie ee . o rg
URL: ht tp://acer-access.c om/~dsebald @ acer-access.c om/
|
|
From: Ethan M. <merritt@u.washington.edu> - 2003-10-24 19:24:30
|
On Friday 24 October 2003 12:06, Daniel J Sebald wrote:
> I've looked at the code in term.c regarding opening the file.
> It looks like the terminal initialization is very safely done with
> appropriate checks of a variable "term_initialised". I'm
> wondering if the actual "fopen()" can't be held off until the
> function "term_start_plot()".
Apparently you are not the first one to think so. The comment
in term_init (term.c line 406) reads:
/* this is nasty - we cannot just term_set_output(outstr)
* since term_set_output will first free outstr and we
* end up with an invalid pointer. I think I would
* prefer to defer opening output file until first plot.
*/
> and in graph3d.c at the start of the "do_plot3d()" routine is
>
> term_start_plot();
> [Why there isn't a term_init() there also, I don't know.]
The first thing term_start_plot() does is call term_init().
So it isn't really necessary in graphics.c at all.
> So, it would mean keeping track of the output file name using
> a character pointer and realloc() and keeping track of the
> binary/ascii file type. In term_start_plot(), check if the file
> name is non-NULL, and if so open the file and free()
> the memory for the name and set the pointer back to NULL.
>
> Does it seem like that would work?
It could be made to work, but I see several problems. =20
The first is that if the output file is illegal it makes far more sense
to get that error message immediately from the 'set output' command.
If you defer trying to open the file until later, the error message
becomes decoupled from the command that caused it.
Also, remember that some terminal types can put multiple plots
into a single file, while others cannot. I would have
to delve into the code to see if moving the file open to=20
term_start_plot() would trip over that difference or not.
--=20
Ethan A Merritt merritt@u.washington.edu
Biomolecular Structure Center Box 357742
University of Washington, Seattle, WA 98195
|
|
From: Daniel J S. <dan...@ie...> - 2003-10-24 20:35:42
|
Ethan Merritt wrote: >On Friday 24 October 2003 12:06, Daniel J Sebald wrote: > > >>I've looked at the code in term.c regarding opening the file. >>It looks like the terminal initialization is very safely done with >>appropriate checks of a variable "term_initialised". I'm >>wondering if the actual "fopen()" can't be held off until the >>function "term_start_plot()". >> >> > >Apparently you are not the first one to think so. The comment >in term_init (term.c line 406) reads: > /* this is nasty - we cannot just term_set_output(outstr) > * since term_set_output will first free outstr and we > * end up with an invalid pointer. I think I would > * prefer to defer opening output file until first plot. > */ > Well, I'm going to leave what to do (if anything) up to you. The end of this comment, however... isn't "term_start_plot()" called upon first plot? >>and in graph3d.c at the start of the "do_plot3d()" routine is >> >> term_start_plot(); >>[Why there isn't a term_init() there also, I don't know.] >> >> > >The first thing term_start_plot() does is call term_init(). >So it isn't really necessary in graphics.c at all. > Ah, I see. >>So, it would mean keeping track of the output file name using >>a character pointer and realloc() and keeping track of the >>binary/ascii file type. In term_start_plot(), check if the file >>name is non-NULL, and if so open the file and free() >>the memory for the name and set the pointer back to NULL. >> >>Does it seem like that would work? >> >> > >It could be made to work, but I see several problems. > >The first is that if the output file is illegal it makes far more sense >to get that error message immediately from the 'set output' command. >If you defer trying to open the file until later, the error message >becomes decoupled from the command that caused it. > I agree, but I'm not sure that is a major transgression. If Gnuplot were to instead display a message at the time of attempted plotting "can't open <filename>", that is just as good I think. Say for example there is an existing file of the name specified but it is write protected. The user then deletes the file from the OS. They wouldn't need to retype 'set output "XYZ"', s/he could just reissue the plot command. >Also, remember that some terminal types can put multiple plots >into a single file, while others cannot. I would have >to delve into the code to see if moving the file open to >term_start_plot() would trip over that difference or not. > I think the closing of the file would remain exactly the way it is. When "set output" is called it should be closed. No changes there. The strategy I would argue for in "term_start_plot()" is if there is a valid output file string then attempt opening. If there is a valid output string and gpoutfile is currently valid, close that gpoutfile before attempting to open. Only when the open is successful should gpoutfile be set and the string cleared. If not successful at opening then do not clear the file name. That way if the user tries to plot time and again, the same message of "can't open XYZ" will appear. If you think the behavior above is preferred, then I would say remove any opening of a file from set_term_output() and things would naturally fall into place. In other words, the only thing that set_term_output() can do is modify the file output string or close an open file. (It should always close an open file, even if the file name is the same as the file name that was given previously.) Dan -- Dan Sebald email: daniel . sebald @ ie ee . o rg URL: ht tp://acer-access.c om/~dsebald @ acer-access.c om/ |
|
From: Ethan M. <merritt@u.washington.edu> - 2003-10-24 19:29:59
|
On Friday 24 October 2003 12:06, Daniel J Sebald wrote:
> I've added the necessary checks for duplicate entry. At
> the end is a #define switch:
>
> if (duplication) {
> #if NOT_PROCESS_IF_DUPLICATION
> int_error(c_token-1, "duplicated or contradicting arguments in
> X11 term options");
> #else
> if (!shown_warning)
> int_warn(c_token-1, "duplicated or contradicting arguments
> in X11 term options");
> shown_warning =3D TRUE;
> #endif
> }
Let's not proliferate conditional code. Go for one or the
other (error or warning).
> So it works fine. But I recall something now. I believe there
> was a discussion a while back about the ability to close a
> single X11 graph from the command line. So perhaps if both
> a "reset" and a number appear in the options, only the plot
> associated with that number could be closed. Right now it
> will reset the whole thing (i.e., close all windows) and then
> switch to plot number. How does that sound?
I think that should be a separate command. "reset" and
"close" do not mean the same thing to me.
I did try to add that feature a while ago, but it turned out to
be harder than it sounded at first blush. So it remains on the
list of things that would be nice but are non-trivial.
--=20
Ethan A Merritt merritt@u.washington.edu
Biomolecular Structure Center Box 357742
University of Washington, Seattle, WA 98195
|
|
From: Daniel J S. <dan...@ie...> - 2003-10-24 20:49:37
|
Ethan Merritt wrote: >>#if NOT_PROCESS_IF_DUPLICATION >> >Let's not proliferate conditional code. Go for one or the >other (error or warning). > I'd vote for error then simply because that is the way "plot" and "splot" behave. Nothing is done if you don't have valid syntax. >>So it works fine. But I recall something now. I believe there >>was a discussion a while back about the ability to close a >>single X11 graph from the command line. So perhaps if both >>a "reset" and a number appear in the options, only the plot >>associated with that number could be closed. Right now it >>will reset the whole thing (i.e., close all windows) and then >>switch to plot number. How does that sound? >> >> > >I think that should be a separate command. "reset" and >"close" do not mean the same thing to me. > So you would want a syntax set term x11 close 5 (or set term x11 5 close is the equivalent) ? That seems just fine to me and it makes sense too. It is just adding one more case in the case statement. Easy. >I did try to add that feature a while ago, but it turned out to >be harder than it sounded at first blush. So it remains on the >list of things that would be nice but are non-trivial. > It did take a while to figure out exactly where to put the code, but after that not bad. From gplt_x11's perspective it would be one line of code to close the window in question. That would effectively wipe out any attributes to that window. The next time the user plots to that window, the window's attributes will have been reset. I could add a code word 'C' or 'c' (not used, surprisingly) inside gplt_x11.c. Dan -- Dan Sebald email: daniel . sebald @ ie ee . o rg URL: ht tp://acer-access.c om/~dsebald @ acer-access.c om/ |
|
From: Daniel J S. <dan...@ie...> - 2003-10-24 22:52:45
|
Ethan Merritt wrote:
>On Friday 24 October 2003 14:01, Daniel J Sebald wrote:
>
>
>>Ethan Merritt wrote>
>>
>>
>>>I did try to add that feature a while ago, but it turned out to
>>>be harder than it sounded at first blush. So it remains on the
>>>list of things that would be nice but are non-trivial.
>>>
>>>
>>It did take a while to figure out exactly where to
>>put the code, but after that not bad. From gplt_x11's
>>perspective it would be one line of code to close
>>the window in question.
>>
>>
>
>You are missing the hard part. The gplt_x11
>process you currently have a pipe to may or may not
>be the same process that opened the window you
>want to close. How do you communicate with the
>original gnuplot_x11 process to tell it to close the
>window?
>
>Of course it's possible. You could keep a list of old
>pipe descriptors, being careful of course never to
>close any of them. But it's non-trivial.
>
>Or you could just give up and not handle this case,
>but it seems a pity to do a half-baked job.
>
Well, I've programmed a simple close statement and it works
fine over a single pipe, i.e., single instance of gplt_x11. On the
x11.trm side of things it is
if (set_number && !set_close && X11_ipc) {
fprintf(X11_ipc, "N%d\n", X11_plot_number);
fflush(X11_ipc);
} else if (set_close && X11_ipc) {
fprintf(X11_ipc, (set_number ? "C%d\n" : "C\n"), X11_plot_number);
fflush(X11_ipc);
}
[Any objection to using the conditional inside the fprintf
in that way? I think the argument is just ignored if
set_number is not true.]
As for the issue with different processes, I'm wondering
how this situation comes about. That would mean the
user is opening different pipes intentionally. (Let's
rule out the accidental destroying of the pipe and a
new one being created...) So if there are multiple pipes each
one running a version of gplt_x11, what would be the
sense of having built a multiwindow gplt_x11 in the first
place? x11.trm could have handled the various windows
on its own. Also, if this is an issue with "close", it is also
an issue with the current "set term x11 #" because that
could be other pipes as well.
From gplt_x11's side of things, everything is fine, I believe.
I'd say it is worth having because in most situations it will
work as expected. So instead of half-baked, it's
nine-tenths-baked. :)
Dan
--
Dan Sebald
email: daniel . sebald @ ie ee . o rg
URL: ht tp://acer-access.c om/~dsebald @ acer-access.c om/
|
|
From: Daniel J S. <dan...@ie...> - 2003-10-27 09:11:11
|
Ethan Merritt wrote: >On Friday 24 October 2003 15:22, Daniel J Sebald wrote: > > >>As for the issue with different processes, I'm wondering >>how this situation comes about. >> >> > >Minimal example from command line: > >set term x11 1 persist >plot something() >set term x11 reset >set term x11 2 persist >plot somthingelse() >set term x11 1 close >^^^^^^^^^^^ will fail > >window 1 is still on the screen and still responding to >mouse events, but is being controlled by a different >gnuplot_x11 process than window 2. > Oh yeah, persist. I forgot about that. Well, that is sort of above and beyond a normal driver anyway... >In practice I would expect this to be more of an >issue with scripts and automated drivers. > but yes, I guess for scripts the persist finds a use, e.g., a script that launches gnuplot, plots, then exits gnuplot but wants to retain the windows. >I don't know exactly what goes on inside Octave, >but if it ever sends a 'set term reset' at all, I should >think this could happen fairly easily. > I don't think the issue is with 'set term reset' unless Octave puts Gnuplot into persist mode. >From looking at the code, I also think it can happen >if a non-tty process switches from nomouse to mouse >within a session. Opening a new X11 term with nomouse >and non-tty causes it to shut down the back_ipc, >and then the next open _with_ a mouse starts a >whole new gnuplot_x11 so it can get a mousing >channel. But I don't have a real-world example of >that. > Hmm... that seems like something that would be fixable. >>So if there are multiple pipes each >>one running a version of gplt_x11, what would be the >>sense of having built a multiwindow gplt_x11 in the first >>place? >> >> > >Good question. I wouldn't have done it this way. > > > >> x11.trm could have handled the various windows >>on its own. >> >> > >Yup. And I think that would be better. >But it would be a lot of work to change over. > Of course, gplt_x11.c would serve as a good basis. The storing of "commands" sent across the pipe as code words could be replaced by the storing of gnuplot internal commands. In the long run, my guess is that the two manners of storing a plot boil down to roughly the same amount of memory usage per plot. But I'm not totally put off by the gplt_x11 scheme of things. There are only a couple of complaints for me: One, the use of ASCII to store all the information bloats memory. Two, there is no way to send what is appearing in an X11 window to a printer or file. That is, say someone generates ten plots on the screen and wants to print any one of them. [I tend to avoid this sort of development approach, opting to do almost everything from script files so I can repeat what I did.] The person would need to retrace all his or her commands to get back to the plot they want and then use the PostScript driver. So, in some sense it would be nice have a system where instead of storing the code letter commands, the terminal function calls are saved and can be directed to PostScript. But, as you pointed out this might be a lot of work because Gnuplot does different things in a few spots based upon the type of terminal. An alternative might be for gplt_x11 to have some mode where it can generate PostScript from its code letter commands. >I'm hoping that someone will write a multi-window >Qt driver and we can just switch over to using that instead >of x11.trm > I'm not familiar with Qt. What part of the system commands for describing the plot would be stored? Internal Gnuplot? Gnuplot terminal commands? Dan |
|
From: Daniel J S. <dan...@ie...> - 2003-10-25 22:14:32
|
Hans-Bernhard Broeker wrote: >On Thu, 23 Oct 2003, Daniel J Sebald wrote: > >[...] > > >>2) If you think the above problem should be modified, >>do you feel that >> >>a) graphics windows should not appear until something >> is actually plotted to them >> >> > >Yes. A gnuplot X11 graph window serves no purpose whatsoever until a >graph is plotted into it, so there's no point displaying it until that >point in time. > OK. Seems agreement is emerging on that. So, gplt_x11 will create the window in memory (because of all the plot->window references) but not display it until something is plotted. An alternative can be investigated later, e.g., waiting until 'G' (prepare plot) is sent to do the actual individual plot update. >>With regard to 2, note that if one types "set output 'name'" >>followed by no plot commands, but then "set output", the >>file 'name' will be created. Is there an analogy here between >>a file and a window? >> >> > >Not really. Arguably, that behaviour of 'set output' is wrong itself. > I will check if that can be modified easily. It may not be as entwined as gplt_x11.c. >>3) Looking at the X11_options() in x11.trm it is very similar >>to other parsing/interpretting schemes, however it doesn't have >>the many checks for repeated entry, valid entry, etc. Some >>commands are sent to gplt_x11 even before the end of parsing. >> >> > >That's a bug, then. But AFAICS, the only command sent to gplt_x11.c >before parsing of the options is finished is an update of the window >number. > > But why even update that? How about the precedence idea of waiting until the line is verified as valid, then if "reset", reset; if "number", number; the rest? That way "set term x11 reset 19 noraise" is the same as "set term x11 noraise 19 reset". Also, "reset" should set the number back to 0, unless a number is also given. This is a cleaner and easier way of doing things I think. Should take ten minutes. Dan -- Dan Sebald email: daniel . sebald @ ie ee . o rg URL: ht tp://acer-access.c om/~dsebald @ acer-access.c om/ |
Thanks for helping keep SourceForge clean.
X