Menu
▾
▴
gnuplot-beta
|
From: Bob F. <rob...@kn...> - 2006-07-14 14:13:27
|
Sirs: I am a gnuplot (and Linux) neophyte and am very curious about a difference in the functionality of *gnuplot Version 4.1 on Windows and on Linux (Fedora Core 5). On Windows, a right-click on the title bar gives me the option to "Copy to Clipboard". I really like this feature and use it to paste figures into MS Word documents - I think as emf's. (By the way, I have never been successful with the "Print" option, but I haven't tried very hard either.) Experimenting on my Linux machine, I downloaded (via CVS) and built gnuplot Version 4.1 and successfully ran it. (You have some really nice demo plots by the way.) Here, however, I can find nothing equivalent to the "Copy to Clipboard" option offered in the Windows version. Perhaps I am just missing it somewhere, but this should be useful for pasting into Open Office documents. Maybe there is some fundamental issue here that I don't understand. I realize that you are working to release Ver 4.2, and I don't want to interfere with that. However, I did want to send this in before I forgot about it. Thanks for a nice product. Bob |
|
From: Petr M. <mi...@ph...> - 2006-07-14 14:17:44
|
> I am a gnuplot (and Linux) neophyte and am very curious about a > difference in the functionality of *gnuplot Version 4.1 on Windows and > on Linux (Fedora Core 5). > Experimenting on my Linux machine, I downloaded (via CVS) and built > gnuplot Version 4.1 and successfully ran it. (You have some really nice > demo plots by the way.) Here, however, I can find nothing equivalent to > the "Copy to Clipboard" option offered in the Windows version. Perhaps I > am just missing it somewhere, but this should be useful for pasting into > Open Office documents. Maybe there is some fundamental issue here that I > don't understand. On Unixes, "middle mouse button" just works. Thus, do plot x*x and then in OpenOffice.org, click by middle mouse button and pasted plot is there! What a magic! --- PM |
|
From: Dmitri A. S. <das...@gm...> - 2006-07-14 14:37:24
|
On 7/14/06, Petr Mikulik <mi...@ph...> wrote: > On Unixes, "middle mouse button" just works. Thus, do > plot x*x > and then in OpenOffice.org, click by middle mouse button and pasted plot > is there! What a magic! > Great! It works! But, wait. I forgot to add grid to the plot. Hit "Del" to delete the plot w/o grid from OO.org; moved mouse over to gnuplot windows; hit "g" -- grid is there now!; go back to OO.org; click the middle mouse button -- Nothing happens! Magic is gone :( > --- > PM > Sincerely, Dmitri. -- |
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-07-14 14:46:51
|
On Friday 14 July 2006 07:17 am, Petr Mikulik wrote: > > Experimenting on my Linux machine, I downloaded (via CVS) and built > > gnuplot Version 4.1 and successfully ran it. (You have some really nice > > demo plots by the way.) Here, however, I can find nothing equivalent to > > the "Copy to Clipboard" option offered in the Windows version. > > Maybe there is some fundamental issue here that I > > don't understand. X11 clipboards are messy. There are at least two of them, and they must be actively managed in order to work. This management is usually mediated by some component of your desktop / window manager. On KDE this component is called "klipper". I don't know what the equivalent might be under Gnome, but if you are not running it already, then turning it on might possibly change the clipboard behavior you see. Furthermore, the export from gnuplot to the clipboard can be turned on/off by the X11 resource gnuplot_exprotselection. To make sure you have this turned on (it should be on by default, but...) type echo "gnuplot*exportselection: on" | xrdb -merge before starting gnuplot. If this makes a difference, then you should edit your Xdefaults file to make this change permanent > > Perhaps I am just missing it somewhere, but this should be useful for > > pasting into Open Office documents. > On Unixes, "middle mouse button" just works. Thus, do > plot x*x > and then in OpenOffice.org, click by middle mouse button and pasted plot > is there! What a magic! That's the "paste from clipboard" side of it. The "copy to clipboard" should happen automatically every time you draw a plot, or click in the active plot window. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Bob F. <rob...@kn...> - 2006-07-14 15:07:14
|
On Fri, 2006-07-14 at 07:46 -0700, Ethan A Merritt wrote: > On Friday 14 July 2006 07:17 am, Petr Mikulik wrote: > > > Experimenting on my Linux machine, I downloaded (via CVS) and built > > > gnuplot Version 4.1 and successfully ran it. (You have some really nice > > > demo plots by the way.) Here, however, I can find nothing equivalent to > > > the "Copy to Clipboard" option offered in the Windows version. > > > > Maybe there is some fundamental issue here that I > > > don't understand. > > X11 clipboards are messy. There are at least two of them, and they must > be actively managed in order to work. This management is usually > mediated by some component of your desktop / window manager. > On KDE this component is called "klipper". I don't know what the > equivalent might be under Gnome, but if you are not running it already, > then turning it on might possibly change the clipboard behavior you see. > > Furthermore, the export from gnuplot to the clipboard can be turned on/off > by the X11 resource gnuplot_exprotselection. To make sure you have this > turned on (it should be on by default, but...) type > echo "gnuplot*exportselection: on" | xrdb -merge > before starting gnuplot. If this makes a difference, then you should > edit your Xdefaults file to make this change permanent > > > > Perhaps I am just missing it somewhere, but this should be useful for > > > pasting into Open Office documents. > > On Unixes, "middle mouse button" just works. Thus, do > > plot x*x > > and then in OpenOffice.org, click by middle mouse button and pasted plot > > is there! What a magic! > > That's the "paste from clipboard" side of it. > The "copy to clipboard" should happen automatically every time you > draw a plot, or click in the active plot window. Thanks to both of you for your responses. I was able to cut and paste a plot to Open Office, so the functionality is indeed available. Unfortunately, I have not been able to repeat the process. Apparently, this is a clipboard/Linux related issue, since the Edit/Past Special option is grayed out in OO. (It was available when I was first successful.) So I will try some of the things you suggested, Ethan. Thanks, Bob |
|
From: Bob F. <rob...@kn...> - 2006-07-14 17:55:48
|
On Fri, 2006-07-14 at 07:46 -0700, Ethan A Merritt wrote: snip > On KDE this component is called "klipper". I don't know what the > equivalent might be under Gnome, but if you are not running it already, > then turning it on might possibly change the clipboard behavior you see. > > Furthermore, the export from gnuplot to the clipboard can be turned on/off > by the X11 resource gnuplot_exprotselection. To make sure you have this > turned on (it should be on by default, but...) type > echo "gnuplot*exportselection: on" | xrdb -merge > before starting gnuplot. If this makes a difference, then you should > edit your Xdefaults file to make this change permanent Shoot! Well, I tried all of the obvious things - except KDE and klipper. (I am having enough 'fun' trying to learn GNOME.) The cut/paste operation is very erratic and usually will not work. As suggested by others, I tried entering "e" for replot with no results. I guess I am having the same sort of flaky performance described by Dmitri. I did notice one interesting thing. If the mouse is activated in gnuplot and I double left click in the figure, the mouse position numbers are pasted into the OO document with the center mouse button. In other words, there is definitely some sort of clipboard/paste operations between gnuplot and OO. It is just that the figure is not getting pasted. I am curious if anyone using Fedora Core 5 with GNOME has success with this. Thanks, Bob |
|
From: Petr M. <mi...@ph...> - 2006-07-14 14:58:56
|
> But, wait. I forgot to add grid to the plot. Hit "Del" to delete the > plot w/o grid > from OO.org; moved mouse over to gnuplot windows; hit "g" -- grid is there > now!; > go back to OO.org; click the middle mouse button -- Nothing happens! > Magic is gone :( It works just after the (re)plot. You may have selected sth else in between. Hit 'e' for replot and paste should be available again. --- PM |
|
From: Dmitri A. S. <das...@gm...> - 2006-07-14 15:11:34
|
On 7/14/06, Petr Mikulik <mi...@ph...> wrote: > It works just after the (re)plot. You may have selected sth else in between. > Hit 'e' for replot and paste should be available again. > It is just flaky. Sometimes it works, sometimes it does not. I use gnome and set "Sloppy focus follows mouse" in case that matters. I also assumed that "g" does replot already, in any case hitting "g" "e" does not seems to make any difference. Zooming with mouse sometimes put new figure into clipboard, sometimes it does not. > --- > PM > Dmitri. -- |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-07-14 18:52:29
|
On Friday 14 July 2006 10:56 am, Bob Fletcher wrote: > > Shoot! Well, I tried all of the obvious things - except KDE and > klipper. (I am having enough 'fun' trying to learn GNOME.) The > cut/paste operation is very erratic and usually will not work. As > suggested by others, I tried entering "e" for replot with no results. > I guess I am having the same sort of flaky performance described by > Dmitri. Part of the confusion in an earlier post is the expectation that you can "copy" once, and "paste" multiple times from it. This is not true for gnuplot+X11 by default. An pixel image placed on the clipboard can be pasted elsewhere, but then it's not on the clipboard any more. Taking a step to the side ... As I understand it, what you want to do is import the plot into an OpenOffice doc. I would suggest to you that even if you get the X11 cut/paste working, this is a poor solution to the task at hand. You would be better off binding a hotkey to a command sequence like: "set term push; set term png; set output /tmp/plot.png; \ replot; set term pop" Then you can easily import the png image. The same could be done for "set term post eps". The image quality from either png or eps should be way better than the bitmapped X11 plot image. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |
|
From: Daniel J S. <dan...@ie...> - 2006-07-14 22:13:49
|
Ethan Merritt wrote:
> On Friday 14 July 2006 10:56 am, Bob Fletcher wrote:
>
>>Shoot! Well, I tried all of the obvious things - except KDE and
>>klipper. (I am having enough 'fun' trying to learn GNOME.) The
>>cut/paste operation is very erratic and usually will not work. As
>>suggested by others, I tried entering "e" for replot with no results.
>>I guess I am having the same sort of flaky performance described by
>>Dmitri.
>
>
> Part of the confusion in an earlier post is the expectation that you
> can "copy" once, and "paste" multiple times from it. This is not
> true for gnuplot+X11 by default. An pixel image placed on the
> clipboard can be pasted elsewhere, but then it's not on the clipboard
> any more.
I'm not an X-pert (the usual disclaimer), but I believe there is indeed some confusion here, and I think it is with the phrase "clipboard". From what I'm seeing in the code, this feature of being able to copy the X11 gnuplot image is not using the clipboard. It is using some kind of X11 scheme of "atoms" and is more in the line of a "selection" in this case.
XSetSelectionOwner(dpy, EXPORT_SELECTION, plot->window, CurrentTime);
I intentionally did not use the term "clipboard" above. A "selection" I'm guessing is more like the center mouse behavior we come to think of in X, i.e., one can quickly hilight a chunk of text in one window and copy it into another window.
"clipboard" would be more like CNTR-C saves it into a cut buffer where the data sits, CNTR-V then recalls that data.
"clipboard" is more permanent, "selection" is more ephemeral. So I think in this case the gnuplot image is "selected" inherently when the plot is done. But after copying the image once into OpenWrite, the gnuplot image becomes "deselected" or out of scope somehow. To verify this, after creating the image, use the center mouse button to select something else; anything. The center mouse button no longer places the gnuplot image in OpenWRite.
OK, so first point:
1) The phrase "clipboard" shouldn't be used the way gnuplot is currently program.
2) Well, it would be nice if this behavior were more in line with typically X applications. That is, this "selection" feature should not be driven by the plotting action, but by some kind of mouse action. The phrase I see at:
http://tronche.com/gui/x/xlib/window-information/selection.html
is ``the last thing the user clicked on''. So it would be nice if there were a mouse action that would cause the X11 gnuplot image to be the "selection", and when this happens the typical thing is for the object in question to be highlighted in contrast colors or XOR-ed with a blue shade or something--like what happens in a web browser.
3) This thing about being able to copy the "selected" image repeatedly... That is a bit peculiar because with other X11 windows things that have been "selected" can be copied time and again so long as they are not deselected. So, it seems we should be able to improve upon that part somehow and get rid of this "sometimes works, sometimes not" kind of thing.
As an example, in a web browser I've selected an image from a local newspaper's website. I can continually copy the "selection" into OpenWrite. First there is some text that appears with the caption and then that is replaced by the image. I keep pressing the center button and keep getting a new image.
4) As for "clipboard". There may be some way of actually doing that as well via X functions. There is this thing called interclient communication functions:
http://tronche.com/gui/x/xlib/ICC/
which appears to deal with Window Managers in some way. However...
Before going down that path, I'm wondering if the actual clipboard can't be made easier than that. Most of these X applications, once something is "selected", almost always seem to be "clipboard-able" by typing, in my case, CNTRL-C/CNTRL-V. So, right now supposedly Gnuplot is "selecting" the plot inherently upon "plot <foo>". Does the gnuplot X window pass the keyboard sequence down the line if it doesn't interpret the key sequence it receives? (I type 'h' right now for a list of keystroke interpretations and don't see a CNTRL-C in the list.) I'm just wondering right now why the inherently selected X11 gnuplot image can't be copied to the clipboard buffer with CNTRL-C.
> Taking a step to the side ...
There are advantages to this.
Dan
|
|
From: Petr M. <mi...@ph...> - 2006-07-14 20:19:07
|
> I did notice one interesting thing. If the mouse is activated in gnuplot > and I double left click in the figure, the mouse position numbers are > pasted into the OO document with the center mouse button. That's the default operation for doubleclick, see hotkey 'h' and 'help mouse'. --- PM |
|
From: Bob F. <rob...@kn...> - 2006-07-14 20:53:55
|
On Fri, 2006-07-14 at 22:19 +0200, Petr Mikulik wrote: > > I did notice one interesting thing. If the mouse is activated in gnuplot > > and I double left click in the figure, the mouse position numbers are > > pasted into the OO document with the center mouse button. > > That's the default operation for doubleclick, see hotkey 'h' and 'help > mouse'. > > --- > PM Oh yes, I see that now. Thanks, Bob |
|
From: Bob F. <rob...@kn...> - 2006-07-14 21:05:02
|
On Fri, 2006-07-14 at 11:52 -0700, Ethan Merritt wrote: > On Friday 14 July 2006 10:56 am, Bob Fletcher wrote: > > snip > Taking a step to the side ... > As I understand it, what you want to do is import the plot into > an OpenOffice doc. I would suggest to you that even if you get > the X11 cut/paste working, this is a poor solution to the task > at hand. You would be better off binding a hotkey to a command > sequence like: > > "set term push; set term png; set output /tmp/plot.png; \ > replot; set term pop" > > Then you can easily import the png image. > The same could be done for "set term post eps". > > The image quality from either png or eps should be way better > than the bitmapped X11 plot image. > OK, thanks Ethan. I still haven't been able to get the hot key binding to work properly, but I can enter the commands on the command line and create the .png (or .emf) file. As you said, I can then drag this new file into the OO document. This is not quite as convenient as the Windows implementation, but once I get the hot key binding working correctly, it should be good enough. Thanks again, Bob |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-07-14 22:07:46
|
On Friday 14 July 2006 02:06 pm, Bob Fletcher wrote: > On Fri, 2006-07-14 at 11:52 -0700, Ethan Merritt wrote: > > I still haven't been able to get the hot key binding to work properly, That sounds like an entirely different problem. Please provide a detailed description. > but I can enter the commands on the command > line and create the .png (or .emf) file. As you said, I can then drag > this new file into the OO document. This is not quite as convenient > as the Windows implementation, but once I get the hot key binding > working correctly, it should be good enough. The suggestion was not intended to maximize convenience, but rather the resulting plot and document quality. I would recommend the same for Windows. In fact, if anything the Windows bitmap image is worse than that for x11 (certainly it's worse than for the new wxt terminal), and you would see correspondingly more gain from using png/emf/eps -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |
|
From: Petr M. <mi...@ph...> - 2006-07-14 22:20:10
|
>> this new file into the OO document. This is not quite as convenient >> as the Windows implementation, but once I get the hot key binding >> working correctly, it should be good enough. Well, you copy a bitmap image, but ... what is it? Usually something uncompressed with unknown resolution. Going via png file with known dimension, saved to disk, cropped with an image editor, is a way to get what you want; and much smaller in size afterwards. Or, is there an option in office apps to compress all images? I remember some versions claimed to have it, but I don't which soft. --- PM |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-07-14 22:35:28
|
On Friday 14 July 2006 03:23 pm, Daniel J Sebald wrote:
>
> I'm not an X-pert (the usual disclaimer), but I believe there is
> indeed some confusion here, and I think it is with the phrase
> "clipboard". From what I'm seeing in the code, this feature of being
> able to copy the X11 gnuplot image is not using the clipboard.
It is.
See for example
http://www.jwz.org/doc/x-cut-and-paste.html
See also the X11 documentation. The X clipboard is exactly what we use.
See also extensive discussion here a few months ago,
when we were trying to get gnuplot to play nicely with both
KDE3 and KDE4 clipboard handling.
--
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA
|
|
From: Daniel J S. <dan...@ie...> - 2006-07-14 22:46:13
|
Ethan Merritt wrote: > On Friday 14 July 2006 03:23 pm, Daniel J Sebald wrote: > >>I'm not an X-pert (the usual disclaimer), but I believe there is >>indeed some confusion here, and I think it is with the phrase >>"clipboard". From what I'm seeing in the code, this feature of being >>able to copy the X11 gnuplot image is not using the clipboard. > > > It is. > > See for example > http://www.jwz.org/doc/x-cut-and-paste.html This seems to read almost exactly like what I explained previously, e.g., : "But what about the middle mouse button? It happens that X11 programs have a second way of copying and pasting text that is orthogonal to the Edit/Copy way described above. This causes confusion, because some people mix the two up. Here's how the other way works: * Select the text to copy. This causes the text to become the Primary Selection. * In another window, click the middle mouse button. This causes the current value of the Primary selection to be inserted. " Dan |
|
From: Daniel J S. <dan...@ie...> - 2006-07-15 04:15:29
|
Ethan Merritt wrote:
> On Friday 14 July 2006 03:23 pm, Daniel J Sebald wrote:
>
>>I'm not an X-pert (the usual disclaimer), but I believe there is
>>indeed some confusion here, and I think it is with the phrase
>>"clipboard". From what I'm seeing in the code, this feature of being
>>able to copy the X11 gnuplot image is not using the clipboard.
>
>
> It is.
Not according to the little tests I've done here... OK, same scenario, generating X11 plots in gnuplot, wanting to get those images over to OpenWriter.
To dump stuff into the clipboard, instead of
export_graph(struct plot_struct *plot)
inside gplt_x11.c attempting to become owner of PRIMARY, I instructed it to attempt becoming owner of CLIPBOARD:
static void
export_graph(struct plot_struct *plot)
{
static Atom XA_CLIPBOARD = (Atom) 0;
if (XA_CLIPBOARD == 0)
XA_CLIPBOARD = XInternAtom(dpy, "CLIPBOARD", False);
XSetSelectionOwner(dpy, XA_CLIPBOARD, plot->window, CurrentTime);
}
And, as per documentation which indicated to be ready as soon as sending that command to get back an event, I've seen the event come without any outside client requesting.
CLIPBOARD = 368
Hit return to continueselection request target: TARGETS (324)
And there is a lot of these. Whenever I click in an editing type of applications, X immediately issues:
selection request target: TARGETS (324)
I then go over to OpenWriter and I can CNTRL-V paste the image into the application as often as I like:
<PASTE #1>
selection request target: MULTIPLE (325)
atom (null) 1852402734 : 1631860837
atom (null) 1936025715 : 0
selection request target: PIXMAP (20)
selection request target: COLORMAP (7)
<PASTE #2>
selection request target: TARGETS (324)
selection request target: MULTIPLE (325)
atom (null) 1852402734 : 1631860837
atom (null) 1936025715 : 0
selection request target: PIXMAP (20)
selection request target: COLORMAP (7)
<PASTE #3>
selection request target: TARGETS (324)
selection request target: MULTIPLE (325)
atom (null) 1852402734 : 1631860837
atom (null) 1936025715 : 0
selection request target: PIXMAP (20)
selection request target: COLORMAP (7)
I point out that once I exit gnuplot and the X11 window goes away, CNTRL-V pasting will no longer work. However, the CNTRL-V still works in clipboard fashion if I go to some other app and use the center mouse button to highlight text.
To me, that is proper clipboard operation. So, gnuplot is currently using Primary selection, not Clipboard.
Ethan, I think we can fix this to be more like conventional X applications. Should we give it a try before 4.2?
I'd propose to the list that there be a Primary selection, via mouse and CNTRL sequences, for both the gnuplot image and the text feature that Petr mentioned currently exists. The CUT/PASTE should then be enabled as well. When the image becomes the primary selection, we should contrast it in blue somehow, the way other apps do.
Thoughts?
Dan
|
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-07-15 04:22:57
|
On Friday 14 July 2006 09:24 pm, you wrote: > Ethan, I think we can fix this to be more like conventional X applications. > Should we give it a try before 4.2? No way! This is some of the most fragile code we've got. From past experience, "fixing" it for one environment is likely to break it for twp others. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Daniel J S. <dan...@ie...> - 2006-07-18 06:47:01
|
I believe I have the selection features worked out for the X11 clipboard. As far as the race condition, I think I have it now so that rarely does selecting and clicking not work. Tell me if this logic and part of the solution makes sense. Here are the basic commands in handling that event (before the change I made): XChangeProperty(dpy, reply.xselection.requestor, reply.xselection.property, reply.xselection.target, 32, PropModeReplace, (unsigned char *) requested_pixmap, 1); XSendEvent(dpy, reply.xselection.requestor, False, 0L, &reply); XFlush(dpy); So the idea is to set some property and send an event to the requestor saying the information it requested is *ready to go*. (Emphasis for later... point is, no it isn't ready.) That is, XChangeProperty is changing some property on the *client* window. There is this Pixmap sitting in X land and it puts the location of the Pixmap atom on that Window. I think, however, that things don't necessarily happen contiguously in X that way. So, it could well be that the Property Change is not actually complete before the time the sent event reaches the window. The client on its end gets the message, goes to look for the property on its window and realizes it doesn't find the information gplt_x11 said was there, on occassion. SO, the idea is to force the requestor window to clear all pending updates before sending the event. Here's the additional command: XChangeProperty(dpy, reply.xselection.requestor, reply.xselection.property, reply.xselection.target, 32, PropModeReplace, (unsigned char *) requested_pixmap, 1); XClearWindow(dpy, reply.xselection.requestor); XSendEvent(dpy, reply.xselection.requestor, False, 0L, &reply); XFlush(dpy); Note that this ClearWindow goes to the requestor. We're basically then waiting for the information we sent to the requestor window to get there before we send the event. Dan |
|
From: Dave D. <dde...@es...> - 2006-07-18 09:29:10
|
Daniel J Sebald <dan...@ie...> writes: > I believe I have the selection features worked out for the X11 > clipboard. As far as the race condition, I think I have it now so > that rarely does selecting and clicking not work. Tell me if this > logic and part of the solution makes sense. > Incidentally, ethereal (or whatever it's called now) can decode X protocol. So if you capture all network traffic on port 6000 you should be able to decode the sequence of events afterwards. Or use xmon (but that may change timings). > Here are the basic commands in handling that event (before the change I made): > > XChangeProperty(dpy, reply.xselection.requestor, > reply.xselection.property, reply.xselection.target, > 32, PropModeReplace, (unsigned char *) requested_pixmap, 1); > > XSendEvent(dpy, reply.xselection.requestor, False, 0L, &reply); > > XFlush(dpy); > > So the idea is to set some property and send an event to the > requestor saying the information it requested is *ready to go*. > (Emphasis for later... point is, no it isn't ready.) > Are you saying that you know that gnuplot has not yet written it, or that you suspect it is getting done out-of-order by the X server ? > That is, XChangeProperty is changing some property on the *client* > window. There is this Pixmap sitting in X land and it puts the > location of the Pixmap atom on that Window. > I think it's just the pixmap id - there's no atom for a pixmap. > I think, however, that things don't necessarily happen contiguously > in X that way. X is quite strict about the sequence of events. It does provide gaurantees about ordering, and promises not to start on one request until the previous one is finished. This is necessary so that error reporting can provide the correct sequence numbers, etc. > So, it could well be that the Property Change is not > actually complete before the time the sent event reaches the > window. > I'm sceptical about that. And all that arrives on the other client is an event that the property has changed. The client still has another round-trip to get hold of the value you've written. So the X server has a lot of time to finish its work, even if it was doing things out of order. > The client on its end gets the message, goes to look for the > property on its window and realizes it doesn't find the information > gplt_x11 said was there, on occassion. > > SO, the idea is to force the requestor window to clear all pending > updates before sending the event. Here's the additional command: > > XChangeProperty(dpy, reply.xselection.requestor, > reply.xselection.property, reply.xselection.target, > 32, PropModeReplace, (unsigned char *) requested_pixmap, 1); > > XClearWindow(dpy, reply.xselection.requestor); > > XSendEvent(dpy, reply.xselection.requestor, False, 0L, &reply); > > XFlush(dpy); > What are you expecting the ClearWindow to do. All it will do is send one or more expose events to the client, asking it to repaint the window. The client is not required to discard any updates, or anything like that. The thing are are doing is (probably) forcing that client to do some extra work before it recents the selection event. So you are changing the timing, But it doesn't seem the right way to go about it. A simpler way to change the timing would be to do an XFlush between the ChangeProperty and the SendEvent. dd -- Dave Denholm <dde...@es...> http://www.esmertec.com |
|
From: Daniel J S. <dan...@ie...> - 2006-07-18 10:18:16
|
Dave Denholm wrote: > Daniel J Sebald <dan...@ie...> writes: > > >>I believe I have the selection features worked out for the X11 >>clipboard. As far as the race condition, I think I have it now so >>that rarely does selecting and clicking not work. Tell me if this >>logic and part of the solution makes sense. >> > > > Incidentally, ethereal (or whatever it's called now) can decode X > protocol. So if you capture all network traffic on port 6000 you > should be able to decode the sequence of events afterwards. Or use > xmon (but that may change timings). > > > >>Here are the basic commands in handling that event (before the change I made): >> >> XChangeProperty(dpy, reply.xselection.requestor, >> reply.xselection.property, reply.xselection.target, >> 32, PropModeReplace, (unsigned char *) requested_pixmap, 1); >> >> XSendEvent(dpy, reply.xselection.requestor, False, 0L, &reply); >> >> XFlush(dpy); >> >>So the idea is to set some property and send an event to the >>requestor saying the information it requested is *ready to go*. >>(Emphasis for later... point is, no it isn't ready.) >> > > > Are you saying that you know that gnuplot has not yet written it, or > that you suspect it is getting done out-of-order by the X server ? Out of order. I messed with XCreatePixmap and such to see if that had any bearing on things. That doesn't seem to be a problem. Perhaps on other versions of X it might, but not what I'm running. > > >>That is, XChangeProperty is changing some property on the *client* >>window. There is this Pixmap sitting in X land and it puts the >>location of the Pixmap atom on that Window. >> > > > I think it's just the pixmap id - there's no atom for a pixmap. Pixmap ID appears to be called an atom as well in some documentation. > > >>I think, however, that things don't necessarily happen contiguously >>in X that way. > > > X is quite strict about the sequence of events. It does provide > gaurantees about ordering, and promises not to start on one request > until the previous one is finished. This is necessary so that error > reporting can provide the correct sequence numbers, etc. Well, something is slightly off. Allow me to live in ignorance and be happy. > >> So, it could well be that the Property Change is not >>actually complete before the time the sent event reaches the >>window. >> > > > I'm sceptical about that. And all that arrives on the other client is > an event that the property has changed. The client still has another > round-trip to get hold of the value you've written. So the X server > has a lot of time to finish its work, even if it was doing things out > of order. Unless perhaps it is a fairly huge Pixmap in X's world where sparsity rules. > >>The client on its end gets the message, goes to look for the >>property on its window and realizes it doesn't find the information >>gplt_x11 said was there, on occassion. >> >>SO, the idea is to force the requestor window to clear all pending >>updates before sending the event. Here's the additional command: >> >> XChangeProperty(dpy, reply.xselection.requestor, >> reply.xselection.property, reply.xselection.target, >> 32, PropModeReplace, (unsigned char *) requested_pixmap, 1); >> >> XClearWindow(dpy, reply.xselection.requestor); >> >> XSendEvent(dpy, reply.xselection.requestor, False, 0L, &reply); >> >> XFlush(dpy); >> > > > What are you expecting the ClearWindow to do. All it will do is send > one or more expose events to the client, asking it to repaint the > window. The client is not required to discard any updates, or anything > like that. Right. > The thing are are doing is (probably) forcing that client to do some > extra work before it recents the selection event. So you are changing > the timing, But it doesn't seem the right way to go about it. Right. > A simpler way to change the timing would be to do an XFlush between > the ChangeProperty and the SendEvent. And I believe that is right. (It finally dawned on me.) Dan |
|
From: Dave D. <dde...@es...> - 2006-07-18 10:44:58
|
Daniel J Sebald <dan...@ie...> writes: > Dave Denholm wrote: >> Daniel J Sebald <dan...@ie...> writes: >> >> >>>I believe I have the selection features worked out for the X11 >>>clipboard. As far as the race condition, I think I have it now so >>>that rarely does selecting and clicking not work. Tell me if this >>>logic and part of the solution makes sense. >>> >> >> >> Incidentally, ethereal (or whatever it's called now) can decode X >> protocol. So if you capture all network traffic on port 6000 you >> should be able to decode the sequence of events afterwards. Or use >> xmon (but that may change timings). >> >> >> >>>Here are the basic commands in handling that event (before the change I made): >>> >>> XChangeProperty(dpy, reply.xselection.requestor, >>> reply.xselection.property, reply.xselection.target, >>> 32, PropModeReplace, (unsigned char *) requested_pixmap, 1); >>> >>> XSendEvent(dpy, reply.xselection.requestor, False, 0L, &reply); >>> >>> XFlush(dpy); >>> >>>So the idea is to set some property and send an event to the >>>requestor saying the information it requested is *ready to go*. >>>(Emphasis for later... point is, no it isn't ready.) >>> >> >> >> Are you saying that you know that gnuplot has not yet written it, or >> that you suspect it is getting done out-of-order by the X server ? > > Out of order. I messed with XCreatePixmap and such to see if that had any bearing on things. That doesn't seem to be a problem. Perhaps on other versions of X it might, but not what I'm running. > >> >> >>>That is, XChangeProperty is changing some property on the *client* >>>window. There is this Pixmap sitting in X land and it puts the >>>location of the Pixmap atom on that Window. >>> >> >> >> I think it's just the pixmap id - there's no atom for a pixmap. > > Pixmap ID appears to be called an atom as well in some documentation. > There is a predefined atom for the string "PIXMAP", which is used to identify the type of the property. $ xlsatoms | grep PIXMAP 20 PIXMAP Atom is a well-defined term in X, so any documentation that misuses the term is broken. >> >> >>>I think, however, that things don't necessarily happen contiguously >>>in X that way. >> >> >> X is quite strict about the sequence of events. It does provide >> gaurantees about ordering, and promises not to start on one request >> until the previous one is finished. This is necessary so that error >> reporting can provide the correct sequence numbers, etc. > > Well, something is slightly off. Allow me to live in ignorance and be happy. > > >> >>> So, it could well be that the Property Change is not >>>actually complete before the time the sent event reaches the >>>window. >>> >> >> >> I'm sceptical about that. And all that arrives on the other client is >> an event that the property has changed. The client still has another >> round-trip to get hold of the value you've written. So the X server >> has a lot of time to finish its work, even if it was doing things out >> of order. > > Unless perhaps it is a fairly huge Pixmap in X's world where sparsity rules. > Don't think so. If the X server does decide to defer some work, it will have to somehow lock the pixmap, and then when someone tries to access it, block that client until the work is done. >> A simpler way to change the timing would be to do an XFlush between >> the ChangeProperty and the SendEvent. > > And I believe that is right. (It finally dawned on me.) > I agree it's a simpler way to change the timing. But if you are relying on timing, the code is broken somewhere. Ah - tell you what - there is one thing that is timing dependent. When you acquire a selection, you're supposed to give a timestamp. That is a server time, and it usually comes from the X event that triggered the action to acquire the selection. But gnuplot doesn't have such an event. IIRC, we use "currenttime" for that, but that isn't a real time. The X server uses the timestamp to resolve if two separate clients try to acquire the same selection : the later time should win. Maybe the problem is in that part of the code. dd -- Dave Denholm <dde...@es...> http://www.esmertec.com |
|
From: <tim...@en...> - 2006-07-18 16:20:32
|
Dave Denholm wrote: > Ah - tell you what - there is one thing that is timing dependent. > > When you acquire a selection, you're supposed to give a > timestamp. That is a server time, and it usually comes from the X > event that triggered the action to acquire the selection. But gnuplot > doesn't have such an event. IIRC, we use "currenttime" for that, but > that isn't a real time. > =20 Hmm. I wrote the code just a few months ago to provide this timestamp. I=20 took the time as plot->time. I realise now that this time is only=20 updated at a button release event, and put to 0 at each "record", so if=20 the user doesn't click on the window this timestamp may have a useless=20 value. > The X server uses the timestamp to resolve if two separate clients try > to acquire the same selection : the later time should win. Maybe the > problem is in that part of the code. > > > dd > =20 Best regards, Timoth=E9e |
|
From: Daniel J S. <dan...@ie...> - 2006-07-18 18:05:46
|
Timoth=E9e Lecomte wrote: > Dave Denholm wrote: >=20 >> Ah - tell you what - there is one thing that is timing dependent. >> >> When you acquire a selection, you're supposed to give a >> timestamp. That is a server time, and it usually comes from the X >> event that triggered the action to acquire the selection. But gnuplot >> doesn't have such an event. IIRC, we use "currenttime" for that, but >> that isn't a real time. >> =20 >=20 > Hmm. I wrote the code just a few months ago to provide this timestamp. = I=20 > took the time as plot->time. I realise now that this time is only=20 > updated at a button release event, and put to 0 at each "record", so if= =20 > the user doesn't click on the window this timestamp may have a useless=20 > value. Could have been a problem. But I eventually whittled things down to the = one problem Dave is keen to. I did notice that the client used to call a= XA_TIMESTAMP selector request. But now it no longer does. Perhaps that= was an issue (that X could resolve with the XA_TIMESTAMP property reques= t), and now has gone away. Dan |
