Re: x11.trm terminal options

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

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