gnuplot-beta — Developers and beta testers of new gnuplot code

Re: wxgnuplot and the screen terminal

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

On Friday 14 April 2006 03:32 pm, Daniel J Sebald wrote:
> 
> In the case of Linux, putting the terminal code into individual 
> driver files (object files) might be nice.

But the screen terminal drivers are small, so you would not
gain much (remember that gnuplot_x11 is a separate executable).

The big terminals are hpglxxx and postscript.
That is why I originally wanted to pull the prolog text out
out of post.trm.

Figure from last year attached.

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

Re: wxgnuplot and the screen terminal

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

Petr Mikulik wrote:
> Some ideas about "screen" terminals, for discussion:

> Or some functionality like that. I hope you caught the point.
> Please think about it.

In the case of Linux, putting the terminal code into individual driver files (object files) might be nice.  It would require some mechanism to install the driver in response to "set term".  Then again, gnuplot is a relatively small program in todays software world even with all the terminal drivers inside.  But if there were an imbedded application, it might be nice.

Dan

Re: wxgnuplot and the screen terminal

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

> On Friday 14 April 2006 01:06 pm, you wrote:
>>
>> I would prefer to see a new entry in the term table, for term->close()=
,
>
> That would be a bit confusing, because it would logically operate on th=
e
> current terminal.  The idea of "set term close <num>" is that it closes
> an old terminal plot window, while leaving the current one untouched.
> You could probably make it work, but I'm not thrilled about the semanti=
cs.
>
>> which could probably go along with new term->raise(), term->lower()
>> instead of the way these two calls are currently implemented directly =
in
>> command.c
>
> I would rather see all the 'raise' and 'lower' commands go away
> altogether.
> My position remains that an application program has no business raising=
 or
> lowering my windows.  But yes, a terminal entry point would be cleaner
> than the current special case coding in command.c

I agree with you, however regarding the recent discussions about the
spacebar which is supposed to raise the gnuplot window, it seems that
these functions which raise/lower windows are needed. I can imagine a
similar syntax for "close" :

"raise" =3D> raise all terminal windows
"raise <n>" =3D> raise n-th terminal window
"lower" =3D> lower all terminal windows
"lower <n>" =3D> lower n-th terminal window
"close" =3D> close all terminal windows
"close <n>" =3D> close n-th terminal window

Timoth=E9e

Re: wxgnuplot and the screen terminal

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

On Friday 14 April 2006 01:06 pm, you wrote:
> 
> I would prefer to see a new entry in the term table, for term->close(),

That would be a bit confusing, because it would logically operate on the
current terminal.  The idea of "set term close <num>" is that it closes
an old terminal plot window, while leaving the current one untouched.
You could probably make it work, but I'm not thrilled about the semantics.

> which could probably go along with new term->raise(), term->lower()
> instead of the way these two calls are currently implemented directly in
> command.c

I would rather see all the 'raise' and 'lower' commands go away altogether.  
My position remains that an application program has no business raising or
lowering my windows.  But yes, a terminal entry point would be cleaner
than the current special case coding in command.c


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

Re: wxgnuplot and the screen terminal

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

>> So yes, perhaps "set term screen <num>",  where
>> "screen" is taken from GNUTERM, and <num> is ignored for
>> terminals that don't support multiple windows.
>
> My main motivation: prepare infrastructure for a portable way of gnuplo=
t
> screen terminal capabilities. There will be a rewrite of gnuplot files =
for
> octave, for example, so prepare gnuplot for this.
> For example, we cannot live with Octave's figure.m implementation with
> hardcoded "set term x11 5".
>
>
> Screen terminals should be unified so that they are capable of
>     set terminal screen {<n>}
>                         {title "<string>"}
>                         {{no}enhanced}
>                         {font <fontspec>}
>                         {{no}persist}
>  		       {{no}raise}
>                         {close}

I appreciate this initiative, but I have one remark concerning this synta=
x
: why should "close" be here ? It is very different from other entries fo=
r
'set terminal' which do not correspond to actions, but to settings.

I would prefer to see a new entry in the term table, for term->close(),
which could probably go along with new term->raise(), term->lower()
instead of the way these two calls are currently implemented directly in
command.c

Regards,

Timoth=E9e

Re: wxgnuplot and the screen terminal

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

On Friday 14 April 2006 08:48 am, Petr Mikulik wrote:

> > perhaps "set term screen <num>",  where "screen" is taken from 
> > GNUTERM, and <num> is ignored for terminals that don't support multiple windows.
> 
> For example, we cannot live with Octave's figure.m implementation with  
> hardcoded "set term x11 5".

exactly

> Screen terminals should be unified so that they are capable of
>     set terminal screen {<n>}
>                         {title "<string>"}
>                         {{no}enhanced}
>                         {font <fontspec>}
>                         {{no}persist}
>  		       {{no}raise}
>                         {close}

I agree with this, but the mechanism is already in place:
	set term pop
	set termoption enhance font "Times,11" ...

We would just need to expand the list of keywords accepted by
'set termoption'.    Hmm. "persist" might be a problem.

> >That is what the environmental variable GNUTERM is for.
> 
> But it is not available from within gnuplot unless gnuplot
> supports new  string function getenv('GNUTERM')? 

What do you mean "available"?
The value of GNUTERM is stored as the terminal name on entry.
So if you immediately do a "set term push", then you have
saved whatever the GNUTERM default was and can recover it
later with "set term pop".   

But yes, we could also copy it into a udv called GNUTERM.
That is so easy that I might as well just go ahead and add it :-)


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

Re: wxgnuplot and the screen terminal

[Petr M. <mi...@ph...>]

> So yes, perhaps "set term screen <num>",  where
> "screen" is taken from GNUTERM, and <num> is ignored for
> terminals that don't support multiple windows.

My main motivation: prepare infrastructure for a portable way of gnuplot 
screen terminal capabilities. There will be a rewrite of gnuplot files for 
octave, for example, so prepare gnuplot for this.
For example, we cannot live with Octave's figure.m implementation with 
hardcoded "set term x11 5".


Screen terminals should be unified so that they are capable of
    set terminal screen {<n>}
                        {title "<string>"}
                        {{no}enhanced}
                        {font <fontspec>}
                        {{no}persist}
 		       {{no}raise}
                        {close}

on any OS. And you could do just once in a startup script:
    set terminal defaultscreen x11
    set terminal defaultscreen windows
    set terminal defaultscreen pm
    set terminal defaultscreen wxterminal


>That is what the environmental variable GNUTERM is for.

But it is not available from within gnuplot unless gnuplot supports new 
string function getenv('GNUTERM')? Please notice that `echo GNUTERM` is not 
available in wgnuplot.exe.

---
PM

Re: wxgnuplot and the screen terminal

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

On Friday 14 April 2006 06:45 am, Petr Mikulik wrote:
> Some ideas about "screen" terminals, for discussion:
> 
> Users, scripts and driving programs have to take care where they are,
> and use "set term x11" or "set term windows" accordingly.

If it is  supposed to be a portable script, it should not
assume anything about the local default terminal.
That is what the environmental variable GNUTERM is for.
I do take your point about about multiple numbered plot
widows, though.

So yes, perhaps "set term screen <num>",  where
"screen" is taken from GNUTERM, and <num> is ignored for
terminals that don't support multiple windows.

> - There is no advantage for users to have both wxt and x11,
> wxt and win in one gnuplot executable.

You can add aquaterm to that list.

That may eventually be true, but we are not quite there yet.
I'm a great fan of the new wxt terminal, and have been using
it by default recently.  But there are still some things that the
x11 term can do that are not yet working in wxt, and I believe
the same is true for the windows terminals (not sure, though,
since I haven't tested a version with Bastian Maerkisch's new
patches). 

 
> - Executable called "wxgnuplot" would use wxterminal by default, all others
>    the OS native (even when wx being compiled in).
> 
> - When wx terminal is built-in, then x11 or win terminals are not compiled
>    in, but their "set term ..." are redirected to wxt. Then, using "set term
>    x11", "set term win", "set term wxt" does always the same thing whereever
>    you run the given script.
> 
> - There can be a unique dummy screen terminal name e.g. "set term screen"
>    that "hides" these "set term some_OS_screen_terminal".
> 
> - It is only the OS/2 gnuplot which can have both x11 and pm in
>    simultaneously. However, wxt is not working there (or at least untested).
> 
> Or some functionality like that. I hope you caught the point.
> Please think about it.
> 
> ---
> PM
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

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

wxgnuplot and the screen terminal

[Petr M. <mi...@ph...>]

Some ideas about "screen" terminals, for discussion:

Users, scripts and driving programs have to take care where they are, and 
use "set term x11" or "set term windows" accordingly. The portable solution 
for "terminal recovery" is "set term pop". However, you cannot do "set term 
MY_OS_SCREEN 5".

My reflections:

- There is no advantage for users to have both wxt and x11, wxt and win in
   one gnuplot executable.

- Executable called "wxgnuplot" would use wxterminal by default, all others
   the OS native (even when wx being compiled in).

- When wx terminal is built-in, then x11 or win terminals are not compiled
   in, but their "set term ..." are redirected to wxt. Then, using "set term
   x11", "set term win", "set term wxt" does always the same thing whereever
   you run the given script.

- There can be a unique dummy screen terminal name e.g. "set term screen"
   that "hides" these "set term some_OS_screen_terminal".

- It is only the OS/2 gnuplot which can have both x11 and pm in
   simultaneously. However, wxt is not working there (or at least untested).

Or some functionality like that. I hope you caught the point.
Please think about it.

---
PM

Re: Connect gnuplot_x11 to exterior application window

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

Dave Denholm wrote:
> Daniel J Sebald <dan...@ie...> writes:
> 
> 
>>Dave Denholm wrote:
>>
>>>Daniel J Sebald <dan...@ie...> writes:
>>>
>>>
>>>>>I also disagree with the comments about
>>>>>/* NOTE:  The removing of plots via the ErrorHandler routine is
>>>>>rather
>>>>>  tricky.  The error events can happen at any time during execution of
>>>>>  the program, very similar to an interrupt.
>>>>
>>>>I think it is.  I spent a lot of time on that code trying to dream
>>>>up a safe way of maintaining the list.
>>>>
>>>>>It's nowhere near as bad as that. The errors can only be delivered to
>>>>>the program when xlib is actually reading from the socket. That can
>>>>>only happen either when it is waiting for a reply to a round-trip
>>>>>request, or when you are reading events.
>>>>
>>>>I'm not sure that implies the problem doesn't exist.  The issue is
>>>>the following.  The ErrorHandler is called in response to the "close
>>>>window" or "destroy window" (whatever it is called) that comes from
>>>>the system by pressing that little box with an x in it at the top
>>>>right corner.
>>>
>>>Well, that's true at a high level, but you have missed many important
>>>details.
>>
>>Dave, you obviously know much more about X than I.  I mean, I looked
>>at plenty of the documentation, fooled around with xprop, watched
>>for messages, etc., but I think that unless a person really
>>understands the concept of what the system core of X is doing, it's
>>a case of addressing the problem with a programming solution as
>>opposed to setting up the X communication appropriately. 
>>
> 
> 
> I used to do a lot of work at the x protocol level. (google for
> ntrigue or wincenter if you are interested). We didn't have xlib, so
> we were working directly at the packet level.
> 
> A really useful tool is "xmon" : comes in two parts, which you pipe
> together :
> 
>  xmonui | xmond
> 
> (slightly weird). Xmonui puts up a gui, and sends commands out on
> stdout. xmond is the actual protocol monitor, reading config from
> stdin. It tends to get confused by the many X extensions,
> unfortunately. I think there is a newer protocol monitor available now.
> 
> So with
> 
> $ xmonui | xmond -port 1 -server eclipse:0
> 
> $ DISPLAY=localhost:1 gnuplot
> 
> I then have gnuplot connecting through xmond and forward onto the real
> X server on eclipse:0

You are way above my skill level on this.


> So I'm still not sure what errors you actually got. So I'd be
> reluctant to change working code without being able to reproduce the
> scenario you were seeing.

You are probably right on that.  (In fact, you are.  I've just searched back through emails and patches.)  Maybe it wasn't the x-box that caused the error directly.  I see there is another way to Remove_Plot_From_Linked_List(event->xkey.window) inside process events.  I can't recall now the circumstance when the system issues an error.  It seemed common, an I must have been doing it fairly easily in order to test things.

Who knows, maybe when I first looked at it the "close" event option wasn't set up right so it may have been the scenario you suggested, i.e., X loopbacks an error because of the mishandled "close".  Perhaps in the meantime it was fixed and I figured to just let the error handler stay as is.

Ethan and I had some conversation about XKill, but that doesn't ring a bell.

Can you think of any other way to close an Xwindow?  Maybe this chunk of error handling code is no longer relevant.

...

BTW, I see that this

 	prevErrorHandler = XSetErrorHandler(DrawRotatedErrorHandler);
[snip]
	XSetErrorHandler(prevErrorHandler);

construct is probably to avoid queueing the plot for destruction in the case of an error generated by an X font problem.  A better way of doing that would probably simply be to add a selective condition in the above ErrorHandler based upon error_event.

Dan

Re: Connect gnuplot_x11 to exterior application window

[Dave D. <dde...@es...>]

Daniel J Sebald <dan...@ie...> writes:

> Dave Denholm wrote:
>> Daniel J Sebald <dan...@ie...> writes:
>>
>>>>I also disagree with the comments about
>>>>/* NOTE:  The removing of plots via the ErrorHandler routine is
>>>>rather
>>>>   tricky.  The error events can happen at any time during execution of
>>>>   the program, very similar to an interrupt.
>>>
>>>I think it is.  I spent a lot of time on that code trying to dream
>>> up a safe way of maintaining the list.
>>>>It's nowhere near as bad as that. The errors can only be delivered to
>>>>the program when xlib is actually reading from the socket. That can
>>>>only happen either when it is waiting for a reply to a round-trip
>>>>request, or when you are reading events.
>>>
>>>I'm not sure that implies the problem doesn't exist.  The issue is
>>>the following.  The ErrorHandler is called in response to the "close
>>>window" or "destroy window" (whatever it is called) that comes from
>>>the system by pressing that little box with an x in it at the top
>>>right corner.
>> Well, that's true at a high level, but you have missed many important
>> details.
>
> Dave, you obviously know much more about X than I.  I mean, I looked
> at plenty of the documentation, fooled around with xprop, watched
> for messages, etc., but I think that unless a person really
> understands the concept of what the system core of X is doing, it's
> a case of addressing the problem with a programming solution as
> opposed to setting up the X communication appropriately. 
>

I used to do a lot of work at the x protocol level. (google for
ntrigue or wincenter if you are interested). We didn't have xlib, so
we were working directly at the packet level.

A really useful tool is "xmon" : comes in two parts, which you pipe
together :

 xmonui | xmond

(slightly weird). Xmonui puts up a gui, and sends commands out on
stdout. xmond is the actual protocol monitor, reading config from
stdin. It tends to get confused by the many X extensions,
unfortunately. I think there is a newer protocol monitor available now.

So with

$ xmonui | xmond -port 1 -server eclipse:0

$ DISPLAY=localhost:1 gnuplot

I then have gnuplot connecting through xmond and forward onto the real
X server on eclipse:0



> It sounds like you are thinking that the window could be configured
> to have that "close button" send the window an event like any other
> so that the core can just simply take care of it, as opposed to that
> notification coming back through ErrorHandler. 
>

As far as I can see, we already have that property set.

I do 'test' in gnuplot, to create the X window. Then close it with the
window manager. On xmond I get the following output

                                 ....SYNTHETIC EVENT: ClientMessage
         ............REQUEST: NoOperation
         ............REQUEST: DestroyWindow
         ............REQUEST: FreePixmap
         ............REQUEST: FreePixmap
         ............REQUEST: FreePixmap
         ............REQUEST: FreePixmap
         ............REQUEST: FreePixmap
         ............REQUEST: FreePixmap
         ............REQUEST: FreePixmap
         ............REQUEST: FreePixmap
         ............REQUEST: FreePixmap
         ............REQUEST: FreePixmap
         ............REQUEST: FreePixmap
         ............REQUEST: FreePixmap
         ............REQUEST: FreePixmap
         ............REQUEST: FreePixmap
                                 ..............EVENT: UnmapNotify
                                 ..............EVENT: DestroyNotify
         ............REQUEST: NoOperation



so the window manager sent a synthetic ClientMessage event to gnuplot,
reporting that I had attempted to close the window. In turn gnuplot
asked for the window to be destroyed. There were no errors generated
anywhere. (I'm using an old solaris CDE system, BTW).

It was presumably the code in gnuplot

    case ClientMessage:
	if (event->xclient.message_type == WM_PROTOCOLS &&
	    event->xclient.format == 32 && event->xclient.data.l[0] == WM_DELETE_WINDOW) {
	    Remove_Plot_From_Linked_List(event->xclient.window);
	}


that deleted the window. And of course this definely happens synchronously.


However, that assumes an ICCCM-compliant window manager.
I tried using xprop to delete the WM_PROTOCOLS property from the
window. But then when I tried closing the window, the server dropped
the connection completely, rather than just closing the window. Window
manager probably did an XKillClient()  which is what xkill does.


So I'm still not sure what errors you actually got. So I'd be
reluctant to change working code without being able to reproduce the
scenario you were seeing.

dd
-- 
Dave Denholm              <dde...@es...>       http://www.esmertec.com

Re: Connect gnuplot_x11 to exterior application window

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

Dave Denholm wrote:
> Daniel J Sebald <dan...@ie...> writes:
> 
> 
>>>I also disagree with the comments about
>>>/* NOTE:  The removing of plots via the ErrorHandler routine is
>>>rather
>>>   tricky.  The error events can happen at any time during execution of
>>>   the program, very similar to an interrupt.
>>
>>I think it is.  I spent a lot of time on that code trying to dream
>>up a safe way of maintaining the list. 
>>
>>
>>>It's nowhere near as bad as that. The errors can only be delivered to
>>>the program when xlib is actually reading from the socket. That can
>>>only happen either when it is waiting for a reply to a round-trip
>>>request, or when you are reading events.
>>
>>I'm not sure that implies the problem doesn't exist.  The issue is
>>the following.  The ErrorHandler is called in response to the "close
>>window" or "destroy window" (whatever it is called) that comes from
>>the system by pressing that little box with an x in it at the top
>>right corner.
> 
> 
> Well, that's true at a high level, but you have missed many important
> details.

Dave, you obviously know much more about X than I.  I mean, I looked at plenty of the documentation, fooled around with xprop, watched for messages, etc., but I think that unless a person really understands the concept of what the system core of X is doing, it's a case of addressing the problem with a programming solution as opposed to setting up the X communication appropriately.

It sounds like you are thinking that the window could be configured to have that "close button" send the window an event like any other so that the core can just simply take care of it, as opposed to that notification coming back through ErrorHandler.

If you want to look at this, go ahead.  Things don't crash so watching communication shouldn't be too bad.  (It's when it continually crashes that it is no fun.)  I could help but it would have to be in the middle of this summer some time.

Dan


> 
> When you close the window, the window manager may send the app a
> request to close the window, or it may just delete the window. That
> will trigger some events to the app to tell you it has closed. (It
> depends on whether you add a property that tells the window manager
> that you want to handle the close yourself.)
> 
> eg if I run xprop on my firefox window, I see
> 
> WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS
> 
> 
> I think that's the one that tells the window manager I want to be told
> about closes.
> 
> Ah - I see gnuplot sets the WM_DELETE_WINDOW hint too. So that means
> that the window shouldn't get closed abruptly by a compliant window
> manager.
> 
> 
> If the app ignores these events, and continues to send requests which
> mention this window (or if there were requests in transit, since the
> protocol is asynchronous), that will trigger errors to be sent to the
> application.
> 
> But the error handler is not invoked until the application reads them
> from the socket (from a getnextevent call or similar). And that should
> only happen under the control of the app.
> 
> if you put a breakpoint on the error handler, and look at the call
> stack when it is invoked, it should always be from a fn that reads the
> network.
> 
> 
> I guess the only time it could be asynchronous is if you are using a
> multi-threaded version of xlib.
> 
> 
> dd

Re: [Fwd: Re: missing top border line]

[<br...@ph...>]

Ethan Merritt wrote:
> In 3D, draw_3d_graphbox() is called at the beginning of the plot,
> but any later calls are under the control of 'set hidden3d' and
> 'set grid {front|back}'.
> 
> The setting of 'set border {front|back}' has no effect in 3D.
> I don't know if that is a bug or if it is intentional.

A mixture of both, I'd guess.  Setting aside 'hidden3d', which does its 
own ordering anyway, the 3D graph box has always been drawn in two 
parts, IIRC: the back side edges are drawn before any plot elements, by 
draw_3d_graphbox(..BACKGRID), the front elements are drawn later (... 
FRONTGRID).  In a true non-map 3D plot, drawing the entire border frame 
in front would be wrong for every use except one: if you're trying to 
create an M.C. Escher effect.

The fact that 'set border {front|back}' doesn't have an effect on the
3D graph box is explainable by two observations:

1) in 3D, the grid is in the baseplane, and has a much stronger relation 
to the graph box.  Some of the parameters for drawing the base grid may 
not even exist outside draw_3d_graphbox.  So it actually makes some 
sense that 'set grid {front|back}' affects the border drawing, too.

2) Plain oversight: 'set border {front|back}' dates 2005-04-14, whereas 
the draw_3d_graphbox() code hasn't been touched since the 4.0 release.



> Probably the 'set view map' case should follow the 2D behaviour
> rather than the current 3D behaviour.  
> 
>> If this is a case, then all border lines should consistently of the same 
>> width.
> 
> They are.  The effect you are seeing may be due to the pm3d
> rectangles not being centered with respect to the same original as 
> the line segments.
> 
>> Further, they don't respect the "front" flag.
> 
> See above.
> 

Re: Connect gnuplot_x11 to exterior application window

[Dave D. <dde...@es...>]

Daniel J Sebald <dan...@ie...> writes:

>> I also disagree with the comments about
>> /* NOTE:  The removing of plots via the ErrorHandler routine is
>> rather
>>    tricky.  The error events can happen at any time during execution of
>>    the program, very similar to an interrupt.
>
> I think it is.  I spent a lot of time on that code trying to dream
> up a safe way of maintaining the list. 
>
>> It's nowhere near as bad as that. The errors can only be delivered to
>> the program when xlib is actually reading from the socket. That can
>> only happen either when it is waiting for a reply to a round-trip
>> request, or when you are reading events.
>
> I'm not sure that implies the problem doesn't exist.  The issue is
> the following.  The ErrorHandler is called in response to the "close
> window" or "destroy window" (whatever it is called) that comes from
> the system by pressing that little box with an x in it at the top
> right corner.

Well, that's true at a high level, but you have missed many important
details.

When you close the window, the window manager may send the app a
request to close the window, or it may just delete the window. That
will trigger some events to the app to tell you it has closed. (It
depends on whether you add a property that tells the window manager
that you want to handle the close yourself.)

eg if I run xprop on my firefox window, I see

WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS


I think that's the one that tells the window manager I want to be told
about closes.

Ah - I see gnuplot sets the WM_DELETE_WINDOW hint too. So that means
that the window shouldn't get closed abruptly by a compliant window
manager.


If the app ignores these events, and continues to send requests which
mention this window (or if there were requests in transit, since the
protocol is asynchronous), that will trigger errors to be sent to the
application.

But the error handler is not invoked until the application reads them
from the socket (from a getnextevent call or similar). And that should
only happen under the control of the app.

if you put a breakpoint on the error handler, and look at the call
stack when it is invoked, it should always be from a fn that reads the
network.


I guess the only time it could be asynchronous is if you are using a
multi-threaded version of xlib.


dd
-- 
Dave Denholm              <dde...@es...>       http://www.esmertec.com

Re: [Fwd: Re: missing top border line]

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

Ethan Merritt wrote:
> On Monday 10 April 2006 10:12 am, Petr Mikulik wrote:
> 
>>Daniel Sebald wrote:
>>
>>>Yes, that is an issue.  I think it is because as far as layout, the border 
>>>lines probably come first and then other plot elements.
> 
> 
> In 2D, plot_border() is always called at the beginning of the plot,
> and is called again at the end of the plot if "set border front".
> 
> In 3D, draw_3d_graphbox() is called at the beginning of the plot,
> but any later calls are under the control of 'set hidden3d' and
> 'set grid {front|back}'.
> 
> The setting of 'set border {front|back}' has no effect in 3D.
> I don't know if that is a bug or if it is intentional.

Seeing the disagreement on various things between 2D/3D I'm inclined to think non-intential.

> Probably the 'set view map' case should follow the 2D behaviour
> rather than the current 3D behaviour.

Yes, I agree.  (You've probably read me arguing for consolidating 2D/3D layout whenever possible--a non-urgent wish, as it may not happened.  But that would be the best.)  Any fixes you can make so that 2D/3D behaviour are similar is good.

Dan

Re: [Fwd: Re: missing top border line]

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

On Monday 10 April 2006 10:12 am, Petr Mikulik wrote:
> Daniel Sebald wrote:
> > Yes, that is an issue.  I think it is because as far as layout, the border 
> > lines probably come first and then other plot elements.

In 2D, plot_border() is always called at the beginning of the plot,
and is called again at the end of the plot if "set border front".

In 3D, draw_3d_graphbox() is called at the beginning of the plot,
but any later calls are under the control of 'set hidden3d' and
'set grid {front|back}'.

The setting of 'set border {front|back}' has no effect in 3D.
I don't know if that is a bug or if it is intentional.
Probably the 'set view map' case should follow the 2D behaviour
rather than the current 3D behaviour.  

> If this is a case, then all border lines should consistently of the same 
> width.

They are.  The effect you are seeing may be due to the pm3d
rectangles not being centered with respect to the same original as 
the line segments.

> Further, they don't respect the "front" flag.

See above.

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

Re: missing top border line

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

On Monday 10 April 2006 02:22 am, Petr Mikulik wrote:
> I wonder that there is a missing top border line in the "view map" mode.
> set border front lt 2 lw 4
> set pm3d map
> splot x
> 
> Does someone have an idea what has changed?

Yes, sorry.  Stupid typo introduced last week when I wrapped the
rectangular border drawing code in a newpath()/closepath() pair.
Three sides are drawn explicitly, but the fourth was only being
drawn for terminals that implement closepath().  Fixed in cvs.

Also the path closure was wrong in PostScript for incomplete
borders.  That is fixed also.

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

Re: Connect gnuplot_x11 to exterior application window

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

Dave Denholm wrote:
> Daniel J Sebald <dan...@ie...> writes:
> 
> 
>>Dave Denholm wrote:
>>
>>
>>>Beware that the x protocol (and so xlib) is mostly
>>>asynchronous. Errors are usually sent asynchronously, like events.
>>>It is possible to handle errors, just a little messy. I forget the
>>>details, but you can use XSync() to force a round-trip to the
>>>server. This way, you can guarantee that all errors have been
>>>delivered for requests up to the sync.
> 
> 
>>I'm somewhat familiar with XSetErrorHandler.
>>
>>Not sure this is directly related to the problem though.  Could be.
>>
> 
> 
> I was replying mainly to
> 
> 
>>>Shouldn't you just get an error return from the call to XSelectInput?
> 
> 
> Just pointing out that xlib fns don't usually return errors. The error
> gets delivered later.

I hear you.  In thinking mode right now.

> 
> 
> I've just had a look at the 4.0 X code (that's the latest source tree
> I happen to have lying around)
> 
> One thing that looks a bit odd : in DrawRotated, it has
> 
>     prevErrorHandler = XSetErrorHandler(DrawRotatedErrorHandler);
> 
>     ...
> 
>     XSetErrorHandler(prevErrorHandler);
> 
> However, because errors are delivered asynchronously, but
> XSetErrorHandler is synchronous, the chances are that you are going to
> remove the error handler before the errors have been delivered. You
> probably need to either leave the error handler plumbed in
> permanently, and use sequence numbers to figure out what to do, or do
> an XSync() before removing the error handler. But this may have
> changed since 4.0

Got me on that one.  I don't know where this use of XSetErrorHandler comes from.  (Can't recall it from when I worked on that aspect of the system.)  I was referring to the other use of ErrorHandler in the code, dealing with safe removal of a plot from the list.

> 
> 
> I also disagree with the comments about
> 
> /* NOTE:  The removing of plots via the ErrorHandler routine is rather
>    tricky.  The error events can happen at any time during execution of
>    the program, very similar to an interrupt.

I think it is.  I spent a lot of time on that code trying to dream up a safe way of maintaining the list.

> 
> It's nowhere near as bad as that. The errors can only be delivered to
> the program when xlib is actually reading from the socket. That can
> only happen either when it is waiting for a reply to a round-trip
> request, or when you are reading events.

I'm not sure that implies the problem doesn't exist.  The issue is the following.  The ErrorHandler is called in response to the "close window" or "destroy window" (whatever it is called) that comes from the system by pressing that little box with an x in it at the top right corner.

The core code of gplt_x11.c has pointers to elements in the linked list of plots.  If ErrorHandler asynchronously removes a plot from the linked list and the core code uses its pointer to attempt drawing or whatnot, it's a seg fault.  I tried many simpler solutions before the "queuing" approach, but seg faults were consistently happening on occasion.

It's the maintaining of the list that is the tricky part.  The bottom line, I think, is to make it so that the core code is the one to remove plots from the linked list.  And even with that concept, it isn't simple to make sure things aren't lost or repeated in the queue.

Dan

Re: Connect gnuplot_x11 to exterior application window

[Dave D. <dde...@es...>]

Daniel J Sebald <dan...@ie...> writes:

> Dave Denholm wrote:
>
>> Beware that the x protocol (and so xlib) is mostly
>> asynchronous. Errors are usually sent asynchronously, like events.
>> It is possible to handle errors, just a little messy. I forget the
>> details, but you can use XSync() to force a round-trip to the
>> server. This way, you can guarantee that all errors have been
>> delivered for requests up to the sync.

> I'm somewhat familiar with XSetErrorHandler.
>
> Not sure this is directly related to the problem though.  Could be.
>

I was replying mainly to

>> Shouldn't you just get an error return from the call to XSelectInput?

Just pointing out that xlib fns don't usually return errors. The error
gets delivered later.


I've just had a look at the 4.0 X code (that's the latest source tree
I happen to have lying around)

One thing that looks a bit odd : in DrawRotated, it has

    prevErrorHandler = XSetErrorHandler(DrawRotatedErrorHandler);

    ...

    XSetErrorHandler(prevErrorHandler);

However, because errors are delivered asynchronously, but
XSetErrorHandler is synchronous, the chances are that you are going to
remove the error handler before the errors have been delivered. You
probably need to either leave the error handler plumbed in
permanently, and use sequence numbers to figure out what to do, or do
an XSync() before removing the error handler. But this may have
changed since 4.0


I also disagree with the comments about

/* NOTE:  The removing of plots via the ErrorHandler routine is rather
   tricky.  The error events can happen at any time during execution of
   the program, very similar to an interrupt.

It's nowhere near as bad as that. The errors can only be delivered to
the program when xlib is actually reading from the socket. That can
only happen either when it is waiting for a reply to a round-trip
request, or when you are reading events.

( XSync() is a round-trip request, actually implemented a trivial
request that can't fail. Can't remember which one, now.)


dd
-- 
Dave Denholm              <dde...@es...>       http://www.esmertec.com

Re: Connect gnuplot_x11 to exterior application window

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

Dave Denholm wrote:

> Beware that the x protocol (and so xlib) is mostly
> asynchronous. Errors are usually sent asynchronously, like events.
> 
> It is possible to handle errors, just a little messy. I forget the
> details, but you can use XSync() to force a round-trip to the
> server. This way, you can guarantee that all errors have been
> delivered for requests up to the sync.
> 
> man XSync
> ...
>      The XSync function flushes the output buffer and then waits
>      until all requests have been received and processed by the X
>      server.  Any errors generated must be handled by the error
>      handler.  For each protocol error received by Xlib, XSync
>      calls the client application's error handling routine (see
>      section 11.8.2).  Any events generated by the server are
>      enqueued into the library's event queue.
> 
> 
> There there is some way in xlib to attach a hook for errors. You can
> check to see if it is an error you expected, and you can tolerate.
> 
> ah - yes - see XSetErrorHandler

I'm somewhat familiar with XSetErrorHandler.  We needed that to deal with asynchronous error events to properly remove plots form the linked list.  (E.g., clicking on the window border's "X" close button issues an asynchronous error that gets filtered back to the client, who may be doing something to that display at the time.  This was a bit of a problem in which closing the X window with a mouse click in the "x" box would often cause a seg fault.  That is working well now.)

Not sure this is directly related to the problem though.  Could be.

Dan

Re: [Fwd: Re: missing top border line]

[Petr M. <mi...@ph...>]

> Yes, that is an issue.  I think it is because as far as layout, the border 
> lines probably come first and then other plot elements.  The other plot 
> elements land on top of and obscure the border lines.  I've noticed this in 
> other places.  I keep thinking in the back of my mind how to deal with this 
> but other than doing the borders last, I can't think of anything.

If this is a case, then all border lines should consistently of the same 
width.

Further, they don't respect the "front" flag.

---
PM

[Fwd: Re: missing top border line]

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

Petr Mikulik wrote:
>> Oh wait.  On that PNG example it looks as the bottom and left borders 
>> are not visible.  (X11 still looks fine.)
> 
> 
> Neither x11 is OK in your case -- green bottom and left lines are thin.

Yes, that is an issue.  I think it is because as far as layout, the border lines probably come first and then other plot elements.  The other plot elements land on top of and obscure the border lines.  I've noticed this in other places.  I keep thinking in the back of my mind how to deal with this but other than doing the borders last, I can't think of anything.

Dan

Re: Connect gnuplot_x11 to exterior application window

[Dave D. <dde...@es...>]

Daniel J Sebald <dan...@ie...> writes:

> Ethan A Merritt wrote:
>> On Sunday 09 April 2006 05:14 pm, Daniel J Sebald wrote:
>>
>>>For an X11 window there can't be two clients desiring the ButtonPress
>>>event at the same times.
>>
>>> The external client that created the window may or may not have
>>> requested ButtonPress via ButtonPressMask.
>> That would clearly be a programming error.  Why open a window for
>> the purpose
>> of displaying gnuplot output, and then fail to let gnuplot have access to the
>> window events?
>
> Well, not necessarily.  Maybe someone likes the cursor position
> information but wants a button press to be interpreted by the parent
> application to load some new data and replot.  I don't know.  It
> boils down to what can accomplish.  Can't defy X11 behavior.  If
> there were no documentation about this option, it would be likely
> the programmer of the outside application might never understand the
> problem even though it may be their "error". 
>

I think another option is to create an InputOnly window over the
output window. That will probably give you first dibs at any
events. (Since it's a separate window, it can have different event
flags.)

However, if the user had a reason for denying you events, just
forcibly taking them is probably not kosher.

dd
-- 
Dave Denholm              <dde...@es...>       http://www.esmertec.com

Re: Connect gnuplot_x11 to exterior application window

[Dave D. <dde...@es...>]

Daniel J Sebald <dan...@ie...> writes:

>>> If it did and gplt_x11.c attempts to also set ButtonPressMask, the
>>> window will crash.
>> Seems unlikely.
>> Shouldn't you just get an error return from the call to XSelectInput?
>
> No, I'm fairly certain I tried this.  I wouldn't have added this "b"
> option if all that would happen is some kind of benign error value.
> The system does something bad, from what I remember.  (I can
> probably force it with an internal code change just to test out.)
> From what I remember, when two clients want the ButtonPress the plot
> would appear and then clicking in the window would cause the window
> to go away. 
>

Beware that the x protocol (and so xlib) is mostly
asynchronous. Errors are usually sent asynchronously, like events.

It is possible to handle errors, just a little messy. I forget the
details, but you can use XSync() to force a round-trip to the
server. This way, you can guarantee that all errors have been
delivered for requests up to the sync.

man XSync
...
     The XSync function flushes the output buffer and then waits
     until all requests have been received and processed by the X
     server.  Any errors generated must be handled by the error
     handler.  For each protocol error received by Xlib, XSync
     calls the client application's error handling routine (see
     section 11.8.2).  Any events generated by the server are
     enqueued into the library's event queue.


There there is some way in xlib to attach a hook for errors. You can
check to see if it is an error you expected, and you can tolerate.

ah - yes - see XSetErrorHandler

The default error handler just exits the client.



dd
-- 
Dave Denholm              <dde...@es...>       http://www.esmertec.com

missing top border line

[Petr M. <mi...@ph...>]

I wonder that there is a missing top border line in the "view map" mode.

You can see it most easily by the followng commands:

set border front lt 2 lw 4
set pm3d map
splot x

Until recently, the top border line was there.
Does someone have an idea what has changed?

---
PM