Re: wxWidgets terminal : XPM cursors and icons

[<tim...@en...>]

Ethan, your message arrived as I was sending mine, it is nice to see=20
that our ideas are not so different.
Here are some thoughts :

Ethan A Merritt wrote:
> On Sunday 04 June 2006 08:54 am, Ethan A Merritt wrote:
>  =20
>> It's the same old problem: gnuplot mixes the input streams from the
>> keyboard and the current terminal into a single queue.  Thus both
>> terminal events and keyboard input are read via term->waitforinput().
>> If you change the terminal, you change the input routine and no longer
>> read events from the previous terminal. =20
>>    =20
>
> On the other hand, the only terminals that implement term->waitforinput
> seem to be x11, wxt, and ggi.  I think we can ignore ggi, if not delete
> it from the tree altogether.  And other than for debugging/comparison, =
I=20
> can't think why you would routinely be switching back and forth between
> x11 and wxt.
>  =20
Agreed, but supporting several waitforinput() should not be that hard,=20
see my previous message.
> So the real issue is when you are using either x11 or wxt, but shift
> temporarily to a different terminal for printing.  Perhaps the answer
> is that in such a case gnuplot could continue to channel input through
> the previous driver's waitforinput() routine.  I think maybe this can
> be done in two steps:
>
>  - When a new terminal is set, we conditionally set a new variable
> 	if (term->waitforinput)
> 		current_waitforinput =3D term->waitforinput;
>
>  - Replace existing references to term->waitforinput() by the new
>    pointer current_waitforinput. I found 3 occurrances in command.c
>    and another 3 in readline.c
>  =20
That's indeed the first step of the simplest approach... The value of=20
"term" has to be changed too when calling current_wiaitforinput() so=20
that the event system calls the right term->puttmptext() and friends.
> I have placed a small patch on SourceForge that does this.
> It seems to work for x11, with a few glitches that appear minor but
> may turn out to be profound. However, if the terminal is set to wxt and
> than to something else, this patch causes a lot of binary junk to spew
> back to the console terminal window.  I don't understand this at all.
> Timoth=E9e, can you have a look to see why this happens?
>  =20
I see exactly the same binary junk with the X11 terminal ! What you see=20
is the binary PNG output sent to stdout, I think. If you try with the=20
postscript terminal, you see the ascii output of the postscript commands=20
instead...

Regards,

Timoth=E9e