Menu
▾
▴
gnuplot-beta
|
From: Hans-Bernhard B. <br...@ph...> - 2004-09-03 09:34:27
|
On Fri, 3 Sep 2004, Donald Burns wrote: > I'm not sure what is the best way to do it is. For my part I'm looking > to embed gnuplot into simple tcl/tk scripts. In that case 'set term tkcanvas' just might be more immediately useful than waiting for a modification to the X11 driver. [And please, everybody, cut down quoted material to the fragment you're actually referring to. And if remotely possible, try to follow-up *below* quoted material, so things appear in proper reading order.] -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
|
From: Donald B. <dm...@re...> - 2004-09-06 09:44:38
|
Oh dear. I've seen the patches go past for this feature but have been unable to get them to work. I downloaded the CVS gnuplot but patching broke with all sorts of offsets and fuzz. As I am not really familiar with CVS, patching, etc I wonder if somebody could help get me going? I specified the module name "gnuplot" for the CVS check-out, but autoconf died about 1000 lines into configure.in. If anybody wants to email a tarball I'd appreciate it. Thanks, Donald. |
|
From: Hans-Bernhard B. <br...@ph...> - 2004-09-06 11:14:19
|
Donald Burns wrote: > Oh dear. I've seen the patches go past for this feature but have been > unable to get them to work. I downloaded the CVS gnuplot but patching > broke with all sorts of offsets and fuzz. I haven't followed this discussion very closely, but maybe the patches weren't made against the current CVS head revision to begin with? Anyway: offsets and fuzz don't necessarily mean trouble. Only actual rejected hunks do. > As I am not really familiar > with CVS, patching, etc I wonder if somebody could help get me going? I > specified the module name "gnuplot" for the CVS check-out, but autoconf > died about 1000 lines into configure.in. How could that be? It only has 994 lines ;-) Generally, you'll need rather current versions of automake and autoconf installed to be able to work with the CVS sources. And don't forget to run ./prepare before you do anything else after the 'cvs checkout'. |
|
From: Donald B. <dm...@re...> - 2004-09-06 14:28:06
|
Hi Dan, I've got the latest CVS and your last patch, even got it to compile and run and install but I can't make it pop up in a tck/tk window. I've tried both "frames" and canvases but with no joy. gnuplot just stubornly pops up a fresh window. Have check that the correct gnuplot_x11 binary is being run and it is. I must be missing a trick here. I can get it to work using ghostview as per your instructions but oddly enough it comes up with a small window on top of the gnuplot plot. Any ideas? Donald. |
|
From: Daniel J S. <dan...@ie...> - 2004-09-06 16:49:48
|
Donald Burns wrote: >Hi Dan, > >I've got the latest CVS and your last patch, even got it to compile and >run and install but I can't make it pop up in a tck/tk window. I've >tried both "frames" and canvases but with no joy. gnuplot just stubornly >pops up a fresh window. Have check that the correct gnuplot_x11 binary >is being run and it is. I must be missing a trick here. I can get it to >work using ghostview as per your instructions but oddly enough it comes >up with a small window on top of the gnuplot plot. Any ideas? > Hi Donald, Well, that is where my X-pertise runs out. From what I see, it appears the X-window has to of a specific configuration to be compatible with gnuplot_x11 as it is currently set up. I found the same behavior as you did. I ran applications from the command line so that any errors would be reported back to the terminal window. Often what happens is when gnuplot_x11 attempts to access the supplied X window, that window dies. gnuplot_x11 must default to a simple X window in that case. (But I'm not sure, I didn't go that far into the code.) I think Dave or Ethan might have some more insight into what is going wrong. Dan |
|
From: Dave D. <dde...@es...> - 2004-09-06 17:12:24
|
Daniel J Sebald <dan...@ie...> writes: > Donald Burns wrote: > >>Hi Dan, >> >>I've got the latest CVS and your last patch, even got it to compile and >>run and install but I can't make it pop up in a tck/tk window. I've >>tried both "frames" and canvases but with no joy. gnuplot just stubornly >>pops up a fresh window. Have check that the correct gnuplot_x11 binary >>is being run and it is. I must be missing a trick here. I can get it to >>work using ghostview as per your instructions but oddly enough it comes >>up with a small window on top of the gnuplot plot. Any ideas? >> > > Hi Donald, > > Well, that is where my X-pertise runs out. From what I see, it > appears the X-window has to of a specific configuration to be > compatible with gnuplot_x11 as it is currently set up. I found the > same behavior as you did. I ran applications from the command line so > that any errors would be reported back to the terminal window. Often > what happens is when gnuplot_x11 attempts to access the supplied X > window, that window dies. gnuplot_x11 must default to a simple X > window in that case. (But I'm not sure, I didn't go that far into the > code.) I think Dave or Ethan might have some more insight into what > is going wrong. > There's a tool you can use to watch X packets. xmon I think. This would let you see raw X error packets being sent - you can never entirely trust programs to show you the actual errors. Did you go with making a new window parented by the supplied window, or drawing directly to the given window ? Do you use the existing colormap or try to impose one. One thing you can try to simplify the world is to use Xvfb or something to give yourself a limited X server. Eg if it only supports one colour depth, or only static visuals, windows can only be of a certain configuration. dd -- Dave Denholm <dde...@es...> http://www.esmertec.com |
|
From: Daniel J S. <dan...@ie...> - 2004-09-06 17:34:01
|
Dave Denholm wrote:
>There's a tool you can use to watch X packets. xmon I think. This
>would let you see raw X error packets being sent - you can never
>entirely trust programs to show you the actual errors.
>
>
>Did you go with making a new window parented by the supplied window,
>or drawing directly to the given window ?
>
I used the given window. (Furthermore, it has to be on the display that
gnuplot is on... would have to add some code to handle different
displays.) I guess it boils down to how the application plans to use
this. If gnuplot_x11 builds its own window derived from the one given,
then the application loses track of the window gnuplot_x11 is using. In
some cases that is no big deal, say gnuplot_x11 is used as a "plug-in"
for a browser and you simple want the plots to appear as usual but in a
browser window. However, if one wants to put additional stuff on the
window along with the plot, for whatever reason, then what?
The pr_window() routine in gplt_x11.c is the one that handles the X
window stuff. The code I added boils down to the following when the
plot->window variable is non-zero:
XWindowAttributes gattr;
XGetWindowAttributes(dpy, plot->window, &gattr);
plot->x = gattr.x;
plot->y = gattr.y;
plot->width = gattr.width;
plot->height = gattr.height;
/* Not exactly sure how to call some routine to compute ->gheight.
* I tried calling XResizeWindow like is done elsewhere. But that
* didn't seem to help. It would be nice if this were called after
* the mouse stuff were set up, but it is called by prepare_plot()
* before the mouse variables are initialized. Ethan, any ideas?
*/
/* Make sure that unsigned number doesn't underflow. */
if (plot->str[0] || 1) /* FORCE TRUE AS A HACK */
plot->gheight = (vchar > plot->height) ? 0 : plot->height - vchar;
else
plot->gheight = plot->height;
> Do you use the existing
>colormap or try to impose one.
>
I didn't investigate that far. But I believe it is set up to impose
one. (Whatever appears after the above code.) I know there is a bit of
a conflict there, i.e., accepting the given window then trying to impose
a colormap. But, if gnuplot doesn't provide the color map, what good is
it? The plots will make no sense.
Daniel
|
|
From: Dave D. <dde...@es...> - 2004-09-06 17:42:43
|
Daniel J Sebald <dan...@ie...> writes: > Dave Denholm wrote: > >>There's a tool you can use to watch X packets. xmon I think. This >>would let you see raw X error packets being sent - you can never >>entirely trust programs to show you the actual errors. >> >> >>Did you go with making a new window parented by the supplied window, >>or drawing directly to the given window ? >> > > I used the given window. (Furthermore, it has to be on the display > that gnuplot is on... would have to add some code to handle different > displays.) I guess it boils down to how the application plans to use > this. If gnuplot_x11 builds its own window derived from the one > given, then the application loses track of the window gnuplot_x11 is > using. In some cases that is no big deal, say gnuplot_x11 is used as > a "plug-in" for a browser and you simple want the plots to appear as > usual but in a browser window. However, if one wants to put > additional stuff on the window along with the plot, for whatever > reason, then what? > > The pr_window() routine in gplt_x11.c is the one that handles the X > window stuff. The code I added boils down to the following when the > plot->window variable is non-zero: > > XWindowAttributes gattr; > XGetWindowAttributes(dpy, plot->window, &gattr); > plot->x = gattr.x; > plot->y = gattr.y; > plot->width = gattr.width; > plot->height = gattr.height; > /* Not exactly sure how to call some routine to compute ->gheight. > * I tried calling XResizeWindow like is done elsewhere. But that > * didn't seem to help. It would be nice if this were called after > * the mouse stuff were set up, but it is called by prepare_plot() > * before the mouse variables are initialized. Ethan, any ideas? > */ > /* Make sure that unsigned number doesn't underflow. */ > if (plot->str[0] || 1) /* FORCE TRUE AS A HACK */ > plot->gheight = (vchar > plot->height) ? 0 : plot->height - vchar; > else > plot->gheight = plot->height; > >> Do you use the existing >>colormap or try to impose one. >> > > I didn't investigate that far. But I believe it is set up to impose > one. (Whatever appears after the above code.) I know there is a bit > of a conflict there, i.e., accepting the given window then trying to > impose a colormap. But, if gnuplot doesn't provide the color map, > what good is it? The plots will make no sense. But if you are reusing the window in order to allow the owning app to add it's own stuff, then that will make no sense.. It definitely gets complicated if you try to use the existing colormap. You have to mess around based on visual type : if it's static (staticGray, staticColor, TrueColor) you can just ask it to give you appropriate pixels given RGB. The server does the lookup. But if it's dynamic (pseudoColor or DirectColor) then you can't ask the X server to choose the nearest existing colour, which is a pain. You can usually treat DirectColor as TrueColor. pseudocolor is then the problem. When I was working on it, pseudocolor was pretty common, but I suspect everyone uses truecolor these days. I can't rememver if you can retrieve all the assigned pixels. But of course, since another app owns the colormap, it may reassign them randomly. dd -- Dave Denholm <dde...@es...> http://www.esmertec.com |
|
From: Daniel J S. <dan...@ie...> - 2004-09-06 17:57:35
|
Dave Denholm wrote: >Daniel J Sebald <dan...@ie...> writes: > > > >>I didn't investigate that far. But I believe it is set up to impose >>one. (Whatever appears after the above code.) I know there is a bit >>of a conflict there, i.e., accepting the given window then trying to >>impose a colormap. But, if gnuplot doesn't provide the color map, >>what good is it? The plots will make no sense. >> >> > > >But if you are reusing the window in order to allow the owning app to >add it's own stuff, then that will make no sense.. > Not necessarily. If the app and gnuplot_x11 are in synch with the attributes of the window, the app could put something else on the window. I know it is far fetched, but you can't anticipate the various things programmers want to do. Maybe they want to print a graph in the bottom half of the screen, then overlay their own stuff in the top half of the image. >It definitely gets complicated if you try to use the existing >colormap. You have to mess around based on visual type : > Yes. In some sense, you almost have to give a protocol in the documentation, or whatever, that the user must create an X window of certain specifications, and then let gnuplot_x11 impose its color map. > if it's static (staticGray, staticColor, TrueColor) you can just ask > it to give you appropriate pixels given RGB. The server does the > lookup. > > But if it's dynamic (pseudoColor or DirectColor) then you can't ask > the X server to choose the nearest existing colour, which is a > pain. You can usually treat DirectColor as TrueColor. pseudocolor is > then the problem. When I was working on it, pseudocolor was pretty > common, but I suspect everyone uses truecolor these days. > > >I can't rememver if you can retrieve all the assigned pixels. > Probably, I recall using an X routine to PutPixel for the image stuff. X seems to have "opposites" for most of their routines, e.g., GetPixel. Dan |
|
From: Dave D. <dde...@es...> - 2004-09-06 18:16:16
|
Daniel J Sebald <dan...@ie...> writes: >>I can't rememver if you can retrieve all the assigned pixels. >> > > Probably, I recall using an X routine to PutPixel for the image > stuff. X seems to have "opposites" for most of their routines, e.g., > GetPixel. > That's to get the pixel value at a given place in an image. What I meant was how to get the RGB values associated with a pixel value. XAllocColor allocates a pixel. Looks like XQueryColor is probably the chap I was after There's also XLookupColor ? dd -- Dave Denholm <dde...@es...> http://www.esmertec.com |
|
From: Daniel J S. <dan...@ie...> - 2004-09-06 20:08:31
|
Donald Burns wrote: >Hi Dan, > >I've got the latest CVS and your last patch, even got it to compile and >run and install but I can't make it pop up in a tck/tk window. I've >tried both "frames" and canvases but with no joy. gnuplot just stubornly >pops up a fresh window. Have check that the correct gnuplot_x11 binary >is being run and it is. I must be missing a trick here. I can get it to >work using ghostview as per your instructions but oddly enough it comes >up with a small window on top of the gnuplot plot. Any ideas? > > Yes, that small window (what I called the "paper") is where gv puts the interpretted PostScript. The parent window underneath is the one which will allow gnuplot_x11 to write to it. As I say, it is just a proof-of-concept that gnuplot_x11 can write to an outside window. Nothing more. I've never worked with tcl/tk, but after poking around a bit on my RedHat distribution I think I'm catching on. To launch tcl is "tcl", that's easy enough. But to get the X extensions tk interpretted is another matter. I see "tclx" and "tk" are extensions. Is the interpretter for the tk portion of all this something called "wish" or "wishx"? [There is all kinds of documentation on tcl/tk, but nothing telling you what command to start it.] So a "frame" seems like a fundamental thing in "wish", but that isn't necessarily the same thing as an X frame. My guess is that "frame" is a simple tk concept of a place to position buttons, dials, etc. Probably not the sort of thing that allows gnuplot_x11 to put a plot there. "canvas" sounds more like a versatile window in which to put graphical stuff. There is a demo as part of tk called "widgets", and in there is a demo for images. I tried hooking gnuplot_x11 to one of those windows. Unfortunately, it causes the tk demo to crash. Someone with a clearer understanding of X and the types of X windows or configuration that works with what gnuplot_x11 is attempting to do might be able to help. Dan |
|
From: Dave D. <dde...@es...> - 2004-09-06 20:50:40
|
Daniel J Sebald <dan...@ie...> writes: > Someone with a clearer understanding of X and the types of X windows > or configuration that works with what gnuplot_x11 is attempting to do > might be able to help. > There is really only one kind of X window. (Well, ignoring input-only windows, and the shape extension.) Usually, everything is a window in X. (Eg all the window manager decorations). That's why xwininfo -tree tends to show so many windows. (Motif has "gadgets" as well as "widgets". I think gadgets are where features are drawn onto a window with lines and things, rather than being layers of windows. But I digress again) Anyway... where was I... yes, windows are fundamentally very simple things. They have size and position, as you'd expect, and depth and colormap (based on concept of visual id) 'xdpyinfo' tells you about your X server, and what kind of visuals it supports. Simple servers only support one visual type, but others support more. (I recall SGI as supporting large numbers of visuals concurrently) Windows can have background pixmaps / background colours / cursors set onto them - by doing this, the X server can do as much redrawing as possible when windows get moved around, rather than having to get the client to redraw. Eg I believe gnuplot draws the plot into a pixmap then sets it as the background. So only time it needs to get involved is if the window is resized. (You may have noticed that when a gnuplot window is enlarged, you see the plot being tiled before it gets redrawn. The Xserver first fills new new area with the tiled background pixmap, then invites gnuplot to repair it.) dd -- Dave Denholm <dde...@es...> http://www.esmertec.com |
|
From: Daniel J S. <dan...@ie...> - 2004-09-06 22:13:35
|
Dave Denholm wrote: >Daniel J Sebald <dan...@ie...> writes: > > > >>Someone with a clearer understanding of X and the types of X windows >>or configuration that works with what gnuplot_x11 is attempting to do >>might be able to help. >> >> >> > > >There is really only one kind of X window. (Well, ignoring input-only >windows, and the shape extension.) Usually, everything is a window in >X. (Eg all the window manager decorations). That's why xwininfo -tree >tends to show so many windows. > > >(Motif has "gadgets" as well as "widgets". I think gadgets are where > features are drawn onto a window with lines and things, rather than > being layers of windows. But I digress again) > > >Anyway... where was I... yes, windows are fundamentally very simple >things. They have size and position, as you'd expect, and depth and >colormap (based on concept of visual id) > >'xdpyinfo' tells you about your X server, and what kind of visuals it >supports. Simple servers only support one visual type, but others >support more. (I recall SGI as supporting large numbers of visuals >concurrently) > > >Windows can have background pixmaps / background colours / cursors set >onto them - by doing this, the X server can do as much redrawing as >possible when windows get moved around, rather than having to get the >client to redraw. Eg I believe gnuplot draws the plot into a pixmap >then sets it as the background. So only time it needs to get involved >is if the window is resized. > >(You may have noticed that when a gnuplot window is enlarged, you see >the plot being tiled before it gets redrawn. The Xserver first fills >new new area with the tiled background pixmap, then invites gnuplot to >repair it.) > Yes, seen that.... I understand that X windows are fundamentally the same, but obviously something isn't right here. Perhaps it has something to do with the input/output you mention... The only extra bit of info I can provide is that the window that gnuplot_x11 connects to doesn't die until in the main loop. (That doesn't mean what was done in pr_window() isn't the cause of the failure... just that it doesn't manifest itself untill later... *perhaps*.) It is the commands XFlush() and XPending() that cause the exterior window to crash. But notice those only have the display as an input. Could it be that those commands have to do with input/output, and the exterior X window is not input/output? But that doesn't make sense, X wouldn't be set up to be so fragile. Dan |
|
From: Dave D. <dde...@es...> - 2004-09-06 22:25:42
|
Daniel J Sebald <dan...@ie...> writes: > Yes, seen that.... I understand that X windows are fundamentally the > same, but obviously something isn't right here. Perhaps it has > something to do with the input/output you mention... The only extra > bit of info I can provide is that the window that gnuplot_x11 connects > to doesn't die until in the main loop. (That doesn't mean what was > done in pr_window() isn't the cause of the failure... just that it > doesn't manifest itself untill later... *perhaps*.) It is the > commands XFlush() and XPending() that cause the exterior window to > crash. But notice those only have the display as an input. Could it > be that those commands have to do with input/output, and the exterior > X window is not input/output? But that doesn't make sense, X wouldn't > be set up to be so fragile. > Ah - bear in mind that Xlib tends to buffer everything up until XFlush(). So it is only when you XFlush() that *all* the other activity happens ! There is a mode you can set to make xlib synchronous. XSynchronize(dpy, 1); what that does is that after every xlib call, it does an XSync() to force a round-trip request. Any errors caused by the request (or other side effects such as crashing other client !) are gauranteed to happen before the xlib call completes. dd -- Dave Denholm <dde...@es...> http://www.esmertec.com |
|
From: Daniel J S. <dan...@ie...> - 2004-09-06 22:37:51
|
Dave Denholm wrote:
>Daniel J Sebald <dan...@ie...> writes:
>
>
>
>>Yes, seen that.... I understand that X windows are fundamentally the
>>same, but obviously something isn't right here. Perhaps it has
>>something to do with the input/output you mention... The only extra
>>bit of info I can provide is that the window that gnuplot_x11 connects
>>to doesn't die until in the main loop. (That doesn't mean what was
>>done in pr_window() isn't the cause of the failure... just that it
>>doesn't manifest itself untill later... *perhaps*.) It is the
>>commands XFlush() and XPending() that cause the exterior window to
>>crash. But notice those only have the display as an input. Could it
>>be that those commands have to do with input/output, and the exterior
>>X window is not input/output? But that doesn't make sense, X wouldn't
>>be set up to be so fragile.
>>
>>
>>
>
>Ah - bear in mind that Xlib tends to buffer everything up until
>XFlush(). So it is only when you XFlush() that *all* the other
>activity happens !
>
>There is a mode you can set to make xlib synchronous.
>
>XSynchronize(dpy, 1);
>
>what that does is that after every xlib call, it does an XSync() to
>force a round-trip request. Any errors caused by the request (or other
>side effects such as crashing other client !) are gauranteed to happen
>before the xlib call completes.
>
Getting close here, Dave. I commented out the ProcessEvents() function
in pr_window(), which contains
static void
ProcessEvents(Window win)
{
XSelectInput(dpy, win, KeyPressMask | KeyReleaseMask
| StructureNotifyMask | PointerMotionMask | PointerMotionHintMask
| ButtonPressMask | ButtonReleaseMask | ExposureMask |
EnterWindowMask);
XSync(dpy, 0);
}
After that, plotting to X windows is fine; but of course without this
the mouse and resizing don't work. So right now I'm reading the man
XSelectInput to find out what the conflict is.
Dan
|
|
From: Daniel J S. <dan...@ie...> - 2004-09-07 02:35:46
|
Daniel J Sebald wrote:
> Getting close here, Dave. I commented out the ProcessEvents()=20
> function in pr_window(), which contains
>
> static void
> ProcessEvents(Window win)
> {
> XSelectInput(dpy, win, KeyPressMask | KeyReleaseMask
> | StructureNotifyMask | PointerMotionMask | PointerMotionHintMa=
sk
> | ButtonPressMask | ButtonReleaseMask | ExposureMask |=20
> EnterWindowMask);
> XSync(dpy, 0);
> }
>
> After that, plotting to X windows is fine; but of course without this=20
> the mouse and resizing don't work. So right now I'm reading the man=20
> XSelectInput to find out what the conflict is.
It's ButtonPressMask.
=B7 Only one client at a time can select a ButtonPress
event, which is associated with the event mask
ButtonPressMask.
[Don't ask me why.] I'm assuming then, those few examples I found a few=20
days ago didn't have ButtonPress event selected.
In the new patch, which I'll send to Dave, Ethan, and Donald separately,=20
the default is for gnuplot_x11 to not grab ahold of the mouse button.=20
But if you add an 'm' after the XID within the string, it will grab=20
ahold of the mouse. E.g.,
set term x11 window '220001e m'
Dan
PS: Added documentation for the new feature (change syntax if desired):
The `x11` terminal can connect to external X windows created by an outsi=
de
application via the option `window` followed by a string containing the
X ID for the window in hexadecimal format. By default, gnuplot assumes
the exterior window is not mouseable because two clients for the same X
window cannot both map a button press event. For situations where the
exterior application has not mapped the button press event, there is the
option to make gnuplot map the button press event by following the X ID
with the letter `m` within the string, e.g.,
set term x11 window "220001e m"
|
|
From: Daniel J S. <dan...@ie...> - 2004-09-07 02:37:31
Attachments:
xwindow_6sep2004.patch.gz
|
Give this version of the patch a whirl. (patch -p1 < xwindow_6sep2004.patch) Dan |
|
From: Daniel J S. <dan...@ie...> - 2004-09-07 07:30:41
|
Oops, didn't mean to send the patch to the list... Anyway, I see that the frames created by tcl/tk have a background that interferes with the drawn plot. That is, the plot draws fine, but then if you move the window, the background is drawn and covers up the plot. Here is a trick to get rid of the background: % set colour "" % . configure -background $colour % frame .myframe -background $colour Then run gnuplot, "set term x11 window" etc. and everything is hunky dory. Can someone offer up a simple little tcl/tk demo to illustrate the use of this? Say, a program that looks in /demo subdirectory and generates a selection box containing all the files ending in ".dem". On one side is the widget for selecting the demo. Right next to that is the plot window showing the results for the demo. Oh, and a button underneath the selection box saying "next" which is the equivalent of return so one could step through the plots in the demo. Something like that? If it sounds like more work than an hour or so, forget it. Just looking at the tk8.3 demos (cool stuff!), image2.tcl comes pretty close except the image would be replaced by a window hooked up to gnuplot. I'm impressed by the tk8.3 demo for a canvas. The objects can be moved around... And now I know what the "tkcanvas" terminal is. Dan |
|
From: Donald B. <dm...@re...> - 2004-09-09 11:27:08
Attachments:
gnuplot-demo
|
Hi all, Here's a simple demo of gnuplot under tck/tk. You'll need to modify some paths for your system. Donald. |
|
From: Daniel J S. <dan...@ie...> - 2004-09-13 06:23:13
|
I've put the patch that allows connecting gnuplot_x11 to an external X window up on SourceForge. In there I've updated Donald's demo with some of the tk8.3 demos. There is a screen capture at http://acer-access.com/~ds...@ac.../gnuplot/gpdemos.png The demo is a Tcl/Tk script I placed in the /demo subdirectory called "gpdemos.tcl". It is self-explanatory. It turned out fairly well, but there are a couple problems with the demo. Some of the demo scripts hang and can't be broken from. I think it has something to do with the pipe/flush communication between the Tcl/Tk program and gnuplot. (What else is new?) I suspect that because before I implemented a clean exit, often when it would hang and I'd quit all the queued up demos would first execute in gnuplot/gnuplot_x11 and then that would exit. The other thing is I can't figure out a way in Tcl/Tk to generate a frame that does not grab ahold of the mouse button. Hence, the mouse action can't be handed over to gnuplot_x11. Dan |
|
From: Donald B. <dm...@re...> - 2004-09-13 14:53:47
|
Hi Dan, Liked the patch and demo a lot and am only sorry I didn't have more time to spend on the demo myself. Do you think your patch will make it into the mainstream gnuplot release? Donald. |
|
From: Daniel J S. <dan...@ie...> - 2004-09-13 17:03:17
|
Donald Burns wrote: >Do you think your patch will make it into >the mainstream gnuplot release? > > It needs to be tested by others for syntax and behavior. Plus this is one of those things where I'd like to confirm that non-numbered windows are properly cleaned up if the outside app closes the window. (So far, it seems to do so.) For developers' sake, the change isn't too drastic. The one conceptual change is that I moved the code that keeps track of the "most recent plot number" to inside gnuplot_x11.c instead of x11.trm. (You see, if x11.trm keeps setting the number every time it does a plot, then the non-numbered plots lose the "current_plot" status. I see no reason for x11 to change "current_plot" except during a "set term x11" command... unless of course gnuplot_x11 stops and needs to be restarted, but I've not seen that happen for a while. Anyway, some control logic could be put inside x11.trm in addition. It's just that I think it isn't necessary.) Dan |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-09-13 17:18:04
|
On Monday 13 September 2004 10:21 am, Daniel J Sebald wrote: > > For developers' sake, the change isn't too drastic. The one conceptual > change is that I moved the code that keeps track of the "most recent > plot number" to inside gnuplot_x11.c instead of x11.trm. (You see, if > x11.trm keeps setting the number every time it does a plot, then the > non-numbered plots lose the "current_plot" status. What is a "non-numbered plot"? Surely if x11 is processing a "replot" command, this needs to go to the last window that x11.trm itself knew about. What else could it mean? I don't see how gnuplot_x11 can know this better than x11.trm itself. > I see no reason for > x11 to change "current_plot" except during a "set term x11" command... I don't see "current_plot" anywhere in x11.trm. Could you please mention specific lines of code, or give the actual variable name? -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Daniel J S. <dan...@ie...> - 2004-09-13 17:56:52
|
Ethan Merritt wrote:
>On Monday 13 September 2004 10:21 am, Daniel J Sebald wrote:
>
>
>>For developers' sake, the change isn't too drastic. The one conceptual
>>change is that I moved the code that keeps track of the "most recent
>>plot number" to inside gnuplot_x11.c instead of x11.trm. (You see, if
>>x11.trm keeps setting the number every time it does a plot, then the
>>non-numbered plots lose the "current_plot" status.
>>
>>
>
>What is a "non-numbered plot"?
>
A non-numbered plot is one for which the command
> set term x11 window <XID>
is given. When the feature come to the list, I raised the question of
whether the XID should be associated with a numbered plot. Dave
suggested it didn't have to be. I agreed and programmed it that way.
There are two things in a plot array in gplt_x11.c, the plot number and
the window ID. The list of plots can be searched for either element.
So conceptually, one should think of two "banks of plots"--those with
numbers, those with window IDs.
>Surely if x11 is processing a "replot" command, this needs to go to
>the last window that x11.trm itself knew about. What else could it mean?
>I don't see how gnuplot_x11 can know this better than x11.trm itself.
>
It is the same difference, so long as the link between the two isn't broken.
>>I see no reason for
>>x11 to change "current_plot" except during a "set term x11" command...
>>
"current_plot" is a variable inside gplt_x11.c. The equivalent inside
x11.trm is "X11_plot_number".
But the current CVS does just what you say it shouldn't. Inside
X11_graphics(), which I believe is called for all plots, is
PRINT2("G%d %lu\n", X11_plot_number, windowid);
which changes the plot in the case where I had just issued, say,
> set term x11 window '200002e'
First, I altered the PRINT2() above so that the plot number isn't part
of the G command. And one's response would be, so that should be
enough. Yes, but when I did this I thought "why shouldn't gnuplot_x11
be keeping track of the most recent plot number in the case where it
can't find the current plot number in the linked-list (because it was
deleted) and it must create a new plot?" Before gnuplot_x11 would just
create a plot with number zero.
In other words, the addition of a "most_recent_plot_number" is a small
addition to gplt_x11.c, and I think it takes care of the problem. Look
at it another way. If what you are saying above is true, that x11
should change the plot number only when there is a "set term x11 #"
command, why should x11.trm keep track of the plot number?
If the case arises that some more sophisticated organization is needed.
Say, gnuplot keeps track of the plot commands for every open window and
can switch back and forth between them, then x11 can certainly override
gnuplot_x11.c.
Dan
|
|
From: Daniel J S. <dan...@ie...> - 2004-09-13 20:22:14
|
-------- Original Message -------- Subject: Re: Run in an X window - Feature request. Date: Mon, 13 Sep 2004 15:46:17 -0500 From: Daniel J Sebald <dan...@ie...> To: merritt@u.washington.edu References: <109...@rg...> <200409131017.55301.merritt@u.washington.edu> <414...@ie...> <200409131151.28968.merritt@u.washington.edu> Ethan Merritt wrote: >Sorry, I don't understand this at all, but I don't have time to look >into it any further right now. Why should the plot not have an id number >just because it went into a specified X window? I don't see what >the two things have to do with each other. Well, that is the question I raised. How should this behave? I certainly could have programmed it either way. I wasn't certain which way would be better at the time, but now I'm feeling that not attaching the XID to a plot number is better. (Still not completely sure of that, however.) I guess this boils down to the following: Should there be multiple ways to access the same plot window, i.e., either via # or via XID? Or, should there be only one way to access a window? My gut tells me the latter is better. I could be convinced otherwise. Dan |
