Re: x11.trm terminal options

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

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