Menu
▾
▴
gnuplot-beta
|
From: <tim...@en...> - 2006-07-18 19:23:12
|
Daniel J Sebald wrote:
> Timoth=E9e Lecomte wrote:
> =20
>> 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 i=
f=20
>> the user doesn't click on the window this timestamp may have a useless=
=20
>> value.
>> =20
>
> Could have been a problem. But I eventually whittled things down to th=
e 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 th=
at was an issue (that X could resolve with the XA_TIMESTAMP property requ=
est), and now has gone away.
> =20
Well, X itself does not call XA_TIMESTAMP, but other applications that=20
check for the content of the clipboard/selection like klipper. Without=20
XA_TIMESTAMP, klipper would infinitely retrieve the pixmap provided by=20
gnuplot, even if it did not change.
But that's not the race condition you're talking about, right ? I must=20
admit that I am a little lost in this thread. Can you repeat what you're=20
trying to solve/achieve ?
I think that Dave was probably talking about this=20
(gplot_x11.c:5924:export_graph):
XSetSelectionOwner(dpy, EXPORT_SELECTION, plot->window, CurrentTime);
where we indeed use CurrentTime which is definitely not the time when=20
the event was triggered. Could be interesting to change CurrentTime to=20
plot->time, or rather :
(!plot || !(plot->time)) ? CurrentTime : plot->time
Best regards,
Timoth=E9e
|
|
From: Daniel J S. <dan...@ie...> - 2006-07-18 19:44:57
|
Timoth=E9e Lecomte wrote: > Daniel J Sebald wrote: >=20 >> Timoth=E9e Lecomte wrote: >> =20 >> >>> 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 gnuplo= t >>>> 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=20 >>> timestamp. I took the time as plot->time. I realise now that this=20 >>> time is only updated at a button release event, and put to 0 at each=20 >>> "record", so if the user doesn't click on the window this timestamp=20 >>> may have a useless value. >>> =20 >> >> >> Could have been a problem. But I eventually whittled things down to=20 >> the one problem Dave is keen to. I did notice that the client used to= =20 >> call a XA_TIMESTAMP selector request. But now it no longer does. =20 >> Perhaps that was an issue (that X could resolve with the XA_TIMESTAMP=20 >> property request), and now has gone away. >> =20 >=20 > Well, X itself does not call XA_TIMESTAMP, but other applications that=20 > check for the content of the clipboard/selection like klipper. Without=20 > XA_TIMESTAMP, klipper would infinitely retrieve the pixmap provided by=20 > gnuplot, even if it did not change. >=20 > But that's not the race condition you're talking about, right ? Correct. I think the important thing we are try to address is the race c= ondition Ethan describes. One in which the Pixmap doesn't seem to succes= sfully make it over to the application (client) requesting it. We were h= andling the request, but sometimes the trasfer was unsuccessful. > I must=20 > admit that I am a little lost in this thread. Can you repeat what you'r= e=20 > trying to solve/achieve ? >=20 > I think that Dave was probably talking about this=20 > (gplot_x11.c:5924:export_graph): >=20 > XSetSelectionOwner(dpy, EXPORT_SELECTION, plot->window, CurrentTime)= ; Well, that is an issue Dave raised. But I think he basically answered th= at question himself by stating that time stamp is used to resolve conflic= ts in who gets control of the selection. For example, if two X windows r= equest control at very near the same time and both of them request Curren= tTime, I'm guessing that X has no recourse but to make a random choice. >=20 > where we indeed use CurrentTime which is definitely not the time when=20 > the event was triggered. Could be interesting to change CurrentTime to=20 > plot->time, or rather : >=20 > (!plot || !(plot->time)) ? CurrentTime : plot->time Ehhhh. Not sure. Don't think that will achieve anything. The plot coul= d have been created an hour ago and we'd be saying we want to take contro= l of the PRIMARY selection or CLIPBOARD at a time one hour ago. (I think= X would realize that something is not right about that and deal with it.= ) Unless we want to be very accurate about when the button or key is pre= ssed that activates Selection, CurrentTime is probably best choice. But, at the same time, there is the related issue that if the other clien= t asks for a XA_TIMESTAMP we should be able to provide, again, definetly = not the time of the plot, but we shouldn't then say CurrentTime. We shou= ld be saying the time the button was pressed. Keep a record of that some= how. (I can fix this up later.) But still, since OpenWrite didn't seem to be asking me for XA_TIMESTAMP, = I don't think the reason for unsuccessful transfer was the time stamp iss= ue. It is the XFlush(). Dan |
|
From: <tim...@en...> - 2006-07-18 20:08:04
|
Daniel J Sebald wrote: > Timoth=E9e Lecomte wrote: >> Daniel J Sebald wrote: >> >>> Timoth=E9e Lecomte wrote: >>> =20 >>> >>>> 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 gnupl= ot >>>>> doesn't have such an event. IIRC, we use "currenttime" for that, bu= t >>>>> that isn't a real time. >>>>> =20 >>>> >>>> Hmm. I wrote the code just a few months ago to provide this=20 >>>> timestamp. I took the time as plot->time. I realise now that this=20 >>>> time is only updated at a button release event, and put to 0 at=20 >>>> each "record", so if the user doesn't click on the window this=20 >>>> timestamp may have a useless value. >>>> =20 >>> >>> >>> Could have been a problem. But I eventually whittled things down to=20 >>> the one problem Dave is keen to. I did notice that the client used=20 >>> to call a XA_TIMESTAMP selector request. But now it no longer=20 >>> does. Perhaps that was an issue (that X could resolve with the=20 >>> XA_TIMESTAMP property request), and now has gone away. >>> =20 >> >> Well, X itself does not call XA_TIMESTAMP, but other applications=20 >> that check for the content of the clipboard/selection like klipper.=20 >> Without XA_TIMESTAMP, klipper would infinitely retrieve the pixmap=20 >> provided by gnuplot, even if it did not change. >> >> But that's not the race condition you're talking about, right ? > > Correct. I think the important thing we are try to address is the=20 > race condition Ethan describes. One in which the Pixmap doesn't seem=20 > to successfully make it over to the application (client) requesting=20 > it. We were handling the request, but sometimes the trasfer was=20 > unsuccessful. Ok, I'm a little late in this thread, but in what conditions did the=20 transfer failed ? How can I reproduce it ? > >> I must admit that I am a little lost in this thread. Can you repeat=20 >> what you're trying to solve/achieve ? >> >> I think that Dave was probably talking about this=20 >> (gplot_x11.c:5924:export_graph): >> >> XSetSelectionOwner(dpy, EXPORT_SELECTION, plot->window, CurrentTime= ); > > Well, that is an issue Dave raised. But I think he basically answered=20 > that question himself by stating that time stamp is used to resolve=20 > conflicts in who gets control of the selection. For example, if two X=20 > windows request control at very near the same time and both of them=20 > request CurrentTime, I'm guessing that X has no recourse but to make a=20 > random choice. Agreed, so it may not be the origin of the unsuccessful transfer, but=20 it's worth trying. > >> >> where we indeed use CurrentTime which is definitely not the time when=20 >> the event was triggered. Could be interesting to change CurrentTime=20 >> to plot->time, or rather : >> >> (!plot || !(plot->time)) ? CurrentTime : plot->time > > Ehhhh. Not sure. Don't think that will achieve anything. The plot=20 > could have been created an hour ago and we'd be saying we want to take=20 > control of the PRIMARY selection or CLIPBOARD at a time one hour ago. =20 > (I think X would realize that something is not right about that and=20 > deal with it.) Unless we want to be very accurate about when the=20 > button or key is pressed that activates Selection, CurrentTime is=20 > probably best choice. Well, you acquire the selection once, when it's ready, not one hour=20 later. That's why this XSetSelectionOwner() call is made in record() and=20 display() but that's all. You don't call it later, that's useless. However, when it's called, it should be provided the right timestamp.=20 CurrentTime probably means "use the current time when the server=20 processes the XSetSelectionOwner call", which is a little later. > > But, at the same time, there is the related issue that if the other=20 > client asks for a XA_TIMESTAMP we should be able to provide, again,=20 > definetly not the time of the plot, but we shouldn't then say=20 > CurrentTime. We should be saying the time the button was pressed. =20 > Keep a record of that somehow. (I can fix this up later.) > > But still, since OpenWrite didn't seem to be asking me for=20 > XA_TIMESTAMP, I don't think the reason for unsuccessful transfer was=20 > the time stamp issue. It is the XFlush(). XA_TIMESTAMP and the unsuccessful transfer are two unrelated issues. I=20 am sorry I talked about that, it seems it made you confused. Best regards, Timoth=E9e |
|
From: Daniel J S. <dan...@ie...> - 2006-07-18 20:52:24
|
Timoth=E9e Lecomte wrote: >>Correct. I think the important thing we are try to address is the=20 >>race condition Ethan describes. One in which the Pixmap doesn't seem=20 >>to successfully make it over to the application (client) requesting=20 >>it. We were handling the request, but sometimes the trasfer was=20 >>unsuccessful. >=20 > Ok, I'm a little late in this thread, but in what conditions did the=20 > transfer failed ? How can I reproduce it ? Without adding some code to verify gnuplot_x11.c is getting requests but = the plot is not appearing, I guess just try selecting (i.e., clipboarding= ) a plot Pixmap and attempting to paste in OpenWrite. Check if there is = a feeling of inconsistency, i.e., that the Pixmap doesn't appear to trans= fer even though you believe you've pressed the button. >=20 >>>I must admit that I am a little lost in this thread. Can you repeat=20 >>>what you're trying to solve/achieve ? >>> >>>I think that Dave was probably talking about this=20 >>>(gplot_x11.c:5924:export_graph): >>> >>> XSetSelectionOwner(dpy, EXPORT_SELECTION, plot->window, CurrentTime= ); >> >>Well, that is an issue Dave raised. But I think he basically answered=20 >>that question himself by stating that time stamp is used to resolve=20 >>conflicts in who gets control of the selection. For example, if two X=20 >>windows request control at very near the same time and both of them=20 >>request CurrentTime, I'm guessing that X has no recourse but to make a=20 >>random choice. >=20 > Agreed, so it may not be the origin of the unsuccessful transfer, but=20 > it's worth trying. Sure, but I think moving that XFlush() command to before sending an event= to the requesting client puts us in the realm of reasonable understandin= g (Dave hasn't disagreed with that yet, I think) and at the same time app= ears to fix the problem. Perhaps someone else could test and verify the = code. >=20 >>>where we indeed use CurrentTime which is definitely not the time when=20 >>>the event was triggered. Could be interesting to change CurrentTime=20 >>>to plot->time, or rather : >>> >>> (!plot || !(plot->time)) ? CurrentTime : plot->time >> >>Ehhhh. Not sure. Don't think that will achieve anything. The plot=20 >>could have been created an hour ago and we'd be saying we want to take=20 >>control of the PRIMARY selection or CLIPBOARD at a time one hour ago. =20 >>(I think X would realize that something is not right about that and=20 >>deal with it.) Unless we want to be very accurate about when the=20 >>button or key is pressed that activates Selection, CurrentTime is=20 >>probably best choice. >=20 > Well, you acquire the selection once, when it's ready, not one hour=20 > later. But that is the issue I'm making. I keep wondering why we should program= gnuplot to behave significantly different from usual X behavior. Is it = nice to have gnuplot automatically saving to the clipboard without being = initiated to do so? Obviously not; that is the reason for adding the abi= lity to turn off "export plot". Otherwise users will not like that their= clipboard is being overwritten. I guess I was thinking along the lines of the mouse click or key press or= "set output clipboard; plot x" activating the Selection, where the plot = time and selection time could be different. I see what you were thinking= though. > That's why this XSetSelectionOwner() call is made in record() and=20 > display() but that's all. You don't call it later, that's useless. As it is program, useless yes. But not in the conventional X method. > However, when it's called, it should be provided the right timestamp.=20 > CurrentTime probably means "use the current time when the server=20 > processes the XSetSelectionOwner call", which is a little later. It's clear I've rearranged the concept, but I think I'm trying to move mo= re along the lines of X expected behavior. Dan |
|
From: Dave D. <dde...@es...> - 2006-07-19 11:04:22
|
Daniel J Sebald <dan...@ie...> writes: > Sure, but I think moving that XFlush() command to before sending an > event to the requesting client puts us in the realm of reasonable > understanding (Dave hasn't disagreed with that yet, I think) If adding an XFlush() changes the behaviour, then IMHO there's a real bug elsewhere in the code that's being masked. So I'd say that fact that the flush changes things means we do not understand what is happening. The whole X thing was designed to be correct and deterministic in the face of different clients with different latencies, etc (one client can be on the LAN, and another can be on the other side of the world). So if one has to resort to forcing flushing of packets, there's a problem somewhere else. > and at > the same time [XFlush] appears to fix the problem. I don't believe it can fix the problem. I agree that it can drive the symptom underground, but IMHO it's better to find and fix the real bug. If someone can summarise the problem, and simple steps to reproduce, I can try to find some time to investigate. (Ideally, the steps would not require KDE or gnome or such, since I generally just use fvwm.) dd -- Dave Denholm <dde...@es...> http://www.esmertec.com |
|
From: Daniel J S. <dan...@ie...> - 2006-07-19 11:37:16
Attachments:
illustrate_mouse_prob.patch
|
Dave Denholm wrote: > If someone can summarise the problem, and simple steps to reproduce, I > can try to find some time to investigate. (Ideally, the steps would > not require KDE or gnome or such, since I generally just use fvwm.) Problem: Using the center mouse button doesn't always transfer a plot. Patch: Attached Method: 1) Apply patch. 2) Goto demo directory after compile. 3) Load 'image.dem'. 4) After every plot, use center mouse button to transfer image to some other app. I find in OpenWriter that I often see the message printed out but no Pixmap showing up. Unfortunately, in the current CVS moving the XFlush() doesn't seem to help matters. Perhaps I changed something in addition to the XFlush(). Dan |
|
From: Dave D. <dde...@es...> - 2006-07-19 18:04:24
|
Daniel J Sebald <dan...@ie...> writes: > Dave Denholm wrote: > >> If someone can summarise the problem, and simple steps to reproduce, I >> can try to find some time to investigate. (Ideally, the steps would >> not require KDE or gnome or such, since I generally just use fvwm.) > > Problem: Using the center mouse button doesn't always transfer a plot. > > Patch: Attached > > Method: > 1) Apply patch. didn't bother with this bit - see below. > 2) Goto demo directory after compile. > 3) Load 'image.dem'. I actually used all.dem > 4) After every plot, use center mouse button to transfer image to some other app. > > I find in OpenWriter that I often see the message printed out but no Pixmap showing up. > I can reproduce using open office - step through all.dem, and try to paste each into an ooffice document. Sometimes it doesn't paste. I connected both gnuplot and ooffice through xmon to an X server (actually, a cygwin X server - I am reduced these days to using a windows box as an X server, with all useful work done on a remote linux box.) So I can watch all the requests and events that both sides are making. What I saw was that ooffice asked for the PIXMAP, and gnuplot appeared to reply correctly. But the times when the paste failed, I saw that ooffice was making no attempt to do a GetImage on the pixmap. So it seems to be a problem at that end, not at gnuplot's end. But of course that still doesn't explain why the extra XFlush at the gnuplot end should change the behaviour. Incidentally, ISTR someone mentioning that you should be able to repeatedly paste the same image. It seems that ooffice explicitly steals selection ownership after the paste. But maybe that's just the way I was doing things. So you can only paste into ooffice once. I can try abiword - there doesn't seem to be a debian package around for OpenWriter ? - Ah - it's part of gnome-office ? Oh - on the speculation that the pixmap was somehow not ready when the client tried to read it... IIRC, there is only one pixmap in use : gnuplot_x11 renders the plot to that pixmap, and then sets it as the background pixmap for the window. So if you can see the plot on screen, the pixmap is ready. But as always, things may have changed, since it's a long time since I've been actively involved. dd -- Dave Denholm <dde...@es...> http://www.esmertec.com |
|
From: Daniel J S. <dan...@ie...> - 2006-07-19 20:06:45
|
Dave Denholm wrote: > Daniel J Sebald <dan...@ie...> writes: > > >>Dave Denholm wrote: >> >> >>>If someone can summarise the problem, and simple steps to reproduce, I >>>can try to find some time to investigate. (Ideally, the steps would >>>not require KDE or gnome or such, since I generally just use fvwm.) >> >>Problem: Using the center mouse button doesn't always transfer a plot. >> >>Patch: Attached >> >>Method: >>1) Apply patch. > > > didn't bother with this bit - see below. > > > >>2) Goto demo directory after compile. >>3) Load 'image.dem'. > > > I actually used all.dem > > >>4) After every plot, use center mouse button to transfer image to some other app. >> >>I find in OpenWriter that I often see the message printed out but no Pixmap showing up. >> > > > I can reproduce using open office - step through all.dem, and try to > paste each into an ooffice document. Sometimes it doesn't paste. > > > I connected both gnuplot and ooffice through xmon to an X server > (actually, a cygwin X server - I am reduced these days to using a > windows box as an X server, with all useful work done on a remote > linux box.) So I can watch all the requests and events that both sides > are making. > > > What I saw was that ooffice asked for the PIXMAP, and gnuplot appeared > to reply correctly. But the times when the paste failed, I saw that ooffice was > making no attempt to do a GetImage on the pixmap. So it seems to be a > problem at that end, not at gnuplot's end. > > But of course that still doesn't explain why the extra XFlush at the > gnuplot end should change the behaviour. It doesn't. I said that it doesn't seem to fix things in the case of CVS. I may have changed something or have been mistaken. > > Incidentally, ISTR someone mentioning that you should be able to > repeatedly paste the same image. It seems that ooffice explicitly > steals selection ownership after the paste. But maybe that's just the > way I was doing things. So you can only paste into ooffice once. I said that. But if you go to the patch I created, you can use 'c' to select the CLIPBOARD so that CNTRL-V will paste multiple copies. The current CVS has been forced so that only once will a PIXMAP be respondible without having to do a replot. > > > I can try abiword - there doesn't seem to be a debian package around > for OpenWriter ? - Ah - it's part of gnome-office ? > > > > Oh - on the speculation that the pixmap was somehow not ready when the > client tried to read it... IIRC, there is only one pixmap in use : > gnuplot_x11 renders the plot to that pixmap, and then sets it as the > background pixmap for the window. So if you can see the plot on > screen, the pixmap is ready. But as always, things may have changed, > since it's a long time since I've been actively involved. Um, probably not too much different. Just a guess. But thanks Dave. Sounds like we are confirming a bug... Not 4.2 critical, but somewhat important. Dan |
|
From: Daniel J S. <dan...@ie...> - 2006-07-19 20:29:28
|
Daniel J Sebald wrote: > I said that. But if you go to the patch I created, you can use 'c' to select the CLIPBOARD so that CNTRL-V will paste multiple copies. I'm being a little ambiguous and absent minded. I mean the patch on SourceForge, not the patch I sent you. Dan |
|
From: Daniel J S. <dan...@ie...> - 2006-07-18 18:01:03
|
Dave Denholm wrote:
> 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.
Yes, I'm not fluent in the terminology, but I understand.
>>>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.
There is discussion in the documentation about large data transfers. Can't say I totally understand it, but that is where we seemed to consistently have the problem.
>
>
>>>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.
That did concern me, because we don't handle that gracefully. But I can't imagine how that could cause a problem.
Hold on, let me say there is more that I added, and maybe it is more crucial to the problem than I would think. Now, I changed things slightly in the sense that I want the client to have a copy of the pixmap that doesn't have the mouse coordinates along the bottom of the Pixmap. To do that, in the midst of this handling of the selection request I've added:
/* Want only the graph portion of Pixmap */
if (requested_pixmap == &selected_pixmap && *requested_pixmap != None) {
[snip]
if (storage_pixmap != None)
XFreePixmap(dpy, storage_pixmap);
[snip]
storage_pixmap = XCreatePixmap(dpy, root, plot->width, GRAPH_HEIGHT(plot), dep);
if (storage_pixmap != None) {
/* Composited for highlight, undo that before copying. */
CompositeWindow(plot, 0);
XCopyArea(dpy, plot->pixmap, storage_pixmap, *current_gc, 0, 0, plot->width, GRAPH_HEIGHT(plot), 0, 0);
CompositeWindow(plot, 1);
}
[snip]
(The CompositeWindow() stuff is to turn off and back on the inverse video effect. I seemed to have little issue with those... as you say, those seemed to happen contiguously with no problems.)
The above lines of code did seem to add to the bad behavior.
I'm almost certain I read somewhere that things don't happen in X necessarily when you think they will. So even though things happen contiguously, could it be they happen later than one might think? That is, without the XFlush, all the above stuff I added, which admittedly is a lot of processing from X's perspective is deferred and not finished before the client window, the requestor, gets its event to proceed?
And here is a bit more information. The XCopyArea(), here and in other locations, appears to return with a non-Success value, it returns BadRequest, a value of 1. I always thought Odd, that seems to work fine. However, maybe that non-Success indication simply means X can't do all that right now so it is deferring the operation until a little later in its refresh cycle (or whatever terminology).
So maybe we should be checking for that BadRequest value and if we find it, *then* we need to XFlush(). (Or, we just always XFlush.) Again, things are contiguous for our window, so that BadRequest is no problem for gnuplot_x11, but it is for any outside client.
Dan
|
|
From: Dave D. <dde...@es...> - 2006-07-17 11:56:36
|
Daniel J Sebald <dan...@ie...> writes: > 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: [snip] > 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. > I used to be an expert in this ICCCM stuff, but it was a while ago. Within an app such as gnuplot, there is no particular difference between PRIMARY and CLIPBOARD selection. However, there is typically another client on the system which wants to permanently own the CLIPBOARD selection (eg xclipboard). So as soon as an app such as gnuplot asserts ownership, that other client immediately asks the app for the data, and then reasserts ownership of the selection, and serves the data to anyone who asks for it. So there *is* a client asking for the data, just not one that the user explicitly triggered. That's what makes the data persistent. The extra utility is not required : if there is no clipboard utility running, other clients can ask for the data in the CLIPBOARD selection and it will be served by the original owner transparently. But then the data dies when the original app dies. My knowledge in this predates gnome / gtk etc. I assume they provide the helpers that do the clipboard stuff. Incidentally, one way to monitor activity is to run xcutsel. I often run two instances, one with -selection PRIMARY and one with -selection CLIPBOARD. Then I can get text to move between them. You can also use xclipboard to move data between them. xcutsel shows you when it owns the selection. If you have xclipboard running, then as soon as you "copy 0 to clipboard" in xcutsel, it immediately loses the selection again. But if you "copy 0 to primary" it will remain highlighted until someone else takes the primary selection. Eg if you have the xcutsel's owning both primary and clipboard (assuming your window manager doesn't keep stealing clipboard). In firefox, highlight some text - it should steal the primary selection. Then choose copy from the menu - it should then also steal the clipboard selection. dd -- Dave Denholm <dde...@es...> http://www.esmertec.com |
|
From: Dave D. <dde...@es...> - 2006-07-18 10:11:16
|
Daniel J Sebald <dan...@ie...> writes: > Daniel J Sebald wrote: > >> SO, the idea is to force the requestor window to clear all pending updates before sending the event. Here's the additional command: >> [snip] > > + /* Make sure things are ready on the requestor window. */ > + XFlush(dpy); > + > XSendEvent(dpy, reply.xselection.requestor, False, 0L, &reply); > - /* we never block on XNextEvent(), so must flush manually > - * (took me *ages* to find this out !) > - */ > > - XFlush(dpy); > > The flush should be before sending the event. (That comment may be a red herring.) > With no flush afterwards..? This really concerns me : you are basically relying on a delay to make things work. There will be a flush soon anyway, All the flush is doing is forcing them to be written to the socket fd. You have no guarantee that it has actually been written over the network. So the send event may still actually get transmitted in the same buffer. The only way to gaurantee that it has actually been processed by the X server is to use XSync() rather than XFlush. I believe that X is deterministic, and so if you have to solve it this way, you've missed the real problem somewhere. dd -- Dave Denholm <dde...@es...> http://www.esmertec.com |
|
From: Daniel J S. <dan...@ie...> - 2006-07-18 10:23:17
|
Dave Denholm wrote:
> Daniel J Sebald <dan...@ie...> writes:
>
>
>>Daniel J Sebald wrote:
>>
>>
>>>SO, the idea is to force the requestor window to clear all pending updates before sending the event. Here's the additional command:
>>>
>
>
> [snip]
>
>
>>
>>+ /* Make sure things are ready on the requestor window. */
>>+ XFlush(dpy);
>>+
>> XSendEvent(dpy, reply.xselection.requestor, False, 0L, &reply);
>>- /* we never block on XNextEvent(), so must flush manually
>>- * (took me *ages* to find this out !)
>>- */
>>
>>- XFlush(dpy);
>>
>>The flush should be before sending the event. (That comment may be a red herring.)
>>
>
>
> With no flush afterwards..?
>
> This really concerns me : you are basically relying on a delay to make
> things work. There will be a flush soon anyway,
>
> All the flush is doing is forcing them to be written to the socket
> fd. You have no guarantee that it has actually been written over
> the network. So the send event may still actually get transmitted in
> the same buffer. The only way to gaurantee that it has actually been
> processed by the X server is to use XSync() rather than XFlush.
>
> I believe that X is deterministic, and so if you have to
> solve it this way, you've missed the real problem somewhere.
Works much better for me; that's all I know. You may be correct about the Flush, but it could be that there is a Flush in the loop of gplt_x11.c... Sure, here it is:
while (1) {
/* XNextEvent does an XFlush() before waiting. But here.
* we must ensure that the queue is flushed, since we
* dont call XNextEvent until an event arrives. (I have
* twice wasted quite some time over this issue, so now
* I am making sure of it !
*/
XFlush(dpy);
FD_ZERO(&tset);
FD_SET(cn, &tset);
After the event is processed, the loop comes back and flushes before waiting. So, that XFlush I removed was extraneous.
Dan
|
|
From: James R. V. Z. <jr...@co...> - 2006-07-15 02:35:55
|
Bob Fletcher <rob...@kn...> wrote:
> 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"
>
> 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.
I import a *lot* of gnuplot figures into MSOffice documents. For
each figure, I create a gnuplot script that creates whatever file I
will later want to import, then plots to a window:
set label "az" at graph 1,1.015 right font "times,6"
set term cgm
set output "az.cgm"
splot 'az.dat' title 'beamsize' with lines, \
sin(u),cos(u),0 ti 'horizon', \
sin(u/4), 0, cos(u/4) ti 'elscan'
set output
set term emf; set output "az.emf"; replot; set output
set term `if [ "$DISPLAY" = "" ]; then echo linux; else echo x11; fi;`
replot
The window display is last so it's interactive.
I only use vector formats for importing (usually cgm, sometimes emf,
never png) because they're smaller, they scale, and they look better.
I save the gnuplot script so I can tweak the input data and easily
re-create the figure. Usually I automate this with a Makefile with
lots of sections like this:
az.cgm az.ps: az.dem az.dat
gnuplot $<
The only part that isn't automated is updating the figures in the
MSOffice document. Maybe I should be "linking" instead of "embedding"
the figures. I assume OpenOffice has something of that sort too.
- Jim Van Zandt
|
|
From: Daniel J S. <dan...@ie...> - 2006-07-15 14:00:05
|
Bob Fletcher wrote: > 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've placed a patch on SourceForge that moves more toward conventional X11 "selection" options, i.e., paste to clipboard than can be had using CNTRL-V in other apps as well as the variety of "selection" where the center mouse button will copy into another app. The copy to clipboard is a static pixel map, i.e., even if you replot in that window the clipboard will remain as before until one types 'c' again. So the variations are <double click> - "select" mouse coords 't' - "clipboard" some sample text 's' - "select" the pixel map 'c' - "clipboard" the pixel map. This is *proof of concept*. Bindings can all be redone. Behavior can be used to force something automatically on plot or splot. One thing to consider is removing the "export_selection" variable option. That seems like unnecessary twiddling if we get a good set of selection options. (Unless that option is meant to be "automatic paste" or something, I don't know.) Dan |
|
From: Daniel J S. <dan...@ie...> - 2006-07-18 09:59:21
|
Daniel J Sebald wrote: > 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); No, make that XFlush, not XClearWindow. (Write concept, wrong function.) So here's the critical replacement: + /* Make sure things are ready on the requestor window. */ + XFlush(dpy); + XSendEvent(dpy, reply.xselection.requestor, False, 0L, &reply); - /* we never block on XNextEvent(), so must flush manually - * (took me *ages* to find this out !) - */ - XFlush(dpy); The flush should be before sending the event. (That comment may be a red herring.) I've updated the patch on SourceForge for those who want to give it a try. It is very X-like now. Highlights image when selected. (Prints SELECTED in the window text when either a Pixmap or some text is selected.) Can copy to clipboard. I've also added a #define option for XPM support. (The library -lXpm has to be added to the list of libraries in the Makefile.) gnuplot_x11 will then support image/x-xpixmap requests so that Abiword now works as well as OpenWriter. In fact, Abiword seems to behave a little more nicely. The XPM support was simple. We could easily create a clipboard buffer for the core of gnuplot if other formats like image/png and so on work as easily as that one did. Dan |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-07-18 20:18:55
|
On Tuesday 18 July 2006 03:06 pm, Timoth=E9e Lecomte wrote: > > > > Correct. I think the important thing we are try to address is the > > race condition Ethan describes. One in which the Pixmap doesn't > > seem to successfully make it over to the application (client) > > requesting it. We were handling the request, but sometimes the > > trasfer was unsuccessful. Who, me? I didn't say anything about a race condition. What is the problem you are trying to solve? So far as I know the clipboard stuff is currently working as well, or better, than it did before. My only contribution to this thread was to point out that we discovered during the last go-round that different versions of KDE (in particular different versions of klipper) and different versions of OpenOffice all play fast-and-loose with the supposedly "standard" protocol for the X clipboard. Following the standard doesn't help if the apps you are trying to work with do not themselves follow it. All of these issues with timestamps and selection requests were involved, and it seemed at the time that only an empirical fix was possible. Certainly no "fix" can be accepted if it doesn't work with the whole range of window managers that are likely to be used. Please see previous thread for details. =2D-=20 Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |
|
From: Daniel J S. <dan...@ie...> - 2006-07-18 20:35:43
|
Ethan Merritt wrote: > On Tuesday 18 July 2006 03:06 pm, Timoth=E9e Lecomte wrote: >=20 >>>Correct. I think the important thing we are try to address is the >>>race condition Ethan describes. One in which the Pixmap doesn't >>>seem to successfully make it over to the application (client) >>>requesting it. We were handling the request, but sometimes the >>>trasfer was unsuccessful. >=20 >=20 > Who, me? > I didn't say anything about a race condition. You're right. Sorry. Your comment was: "If you allow the selection to remain active (multiple pastes) then some window managers spin endlessly, using 100% of CPU." > What is the problem you are trying to solve? > So far as I know the clipboard stuff is currently working as well, > or better, than it did before. I'm not sure it does. Someone indicated that the pasting of the image in= OpenWriter took two or three presses of the mouse... I printed out the= Atoms that gnuplot_x11.c was receiving, and yes it was receiving the ato= ms and responding but some times the plot would not appear. >=20 > My only contribution to this thread was to point out that we > discovered during the last go-round that different versions of KDE > (in particular different versions of klipper) and different versions > of OpenOffice all play fast-and-loose with the supposedly "standard" > protocol for the X clipboard. Following the standard doesn't help > if the apps you are trying to work with do not themselves follow it. >=20 > All of these issues with timestamps and selection requests were > involved, and it seemed at the time that only an empirical fix > was possible. Certainly no "fix" can be accepted if it doesn't > work with the whole range of window managers that are likely to > be used. Well, give the patch I made a try. As far as I see it, there is now a wa= y to put things in the PRIMARY and CLIPBOARD. If there is a version of X= that doesn't use one of those mechanisms (which are called out in the X = documentation) then that is its problem. It may be that in KDE one must use one or the other. But again, we can a= lways provide a term option to configure the behavior. Why aim for the l= owest common denominator? Dan |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-07-18 20:41:14
|
On Tuesday 18 July 2006 01:44 pm, Daniel J Sebald wrote: > Well, give the patch I made a try. I am NOT going to look at this before 4.2 It would be insane to start fiddling with a major interface like X11 just before a release. > As far as I see it, there is now > a way to put things in the PRIMARY and CLIPBOARD. If there is a > version of X that doesn't use one of those mechanisms (which are > called out in the X documentation) then that is its problem. Please read the previous thread. The issue is not what X11 wants. The issue is that major user environments like KDE, and major apps like OpenOffice, ignore this and do something else. And then they change it from version to version. Any argument from the standard or the X11 docs is pointless. This has to work on real machines for real users. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |
|
From: Daniel J S. <dan...@ie...> - 2006-07-18 21:03:22
|
Ethan Merritt wrote: > On Tuesday 18 July 2006 01:44 pm, Daniel J Sebald wrote: > >>Well, give the patch I made a try. > > > I am NOT going to look at this before 4.2 > It would be insane to start fiddling with a major interface like > X11 just before a release. I'm thinking along the lines that 4.2 is pretty much set accept for any bugs someone asks me to fix. (Just about got a bug fix ready here.) As for someone who could look at this, I mean the people with interest and who asked about the clipboard initially. >>As far as I see it, there is now >>a way to put things in the PRIMARY and CLIPBOARD. If there is a >>version of X that doesn't use one of those mechanisms (which are >>called out in the X documentation) then that is its problem. > > > Please read the previous thread. The issue is not what X11 wants. > The issue is that major user environments like KDE, and major apps > like OpenOffice, ignore this and do something else. Do you mean OpenOffice in KDE? Because the patch provides both PRIMARY and CLIPBOARD for OpenOffice in Gnome and it works as expected. > And then they > change it from version to version. > > Any argument from the standard or the X11 docs is pointless. > This has to work on real machines for real users. I don't think it is pointless. If KDE or some other environment reacts to just PRIMARY or just CLIPBOARD, then they still have a form of getting the Pixmap. Dan |
|
From: Daniel J S. <dan...@ie...> - 2006-07-18 21:06:43
|
Daniel J Sebald wrote: >>I am NOT going to look at this before 4.2 >>It would be insane to start fiddling with a major interface like >>X11 just before a release. > > > I'm thinking along the lines that 4.2 is pretty much set accept for any bugs someone asks me to fix. (Just about got a bug fix ready here.) If there is anything here that should be looked at before 4.2, maybe it is that one line change of moving XFLush() to before sending an event. Perhaps we should investigate that. Dan |
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-07-19 15:36:23
|
On Wednesday 19 July 2006 04:46 am, Daniel J Sebald wrote: > > > If someone can summarise the problem, and simple steps to reproduce, I > > can try to find some time to investigate. (Ideally, the steps would > > not require KDE or gnome or such, since I generally just use fvwm.) Problem: Commonly used desktops do radically different things with the X clipboard. See, for example, this rant about incompatible clipboard handling under various versions of KDE. http://www.kdedevelopers.org/taxonomy/term/44?from=20 I read a similar rant somewhere about incompatible clipboard handling by OpenOffice, but can't find it again at the moment. This is not a problem we can solve in gnuplot, and I really don't think it's worth a lot of time spent on the attempt. To convince yourself of this, I suggest you try out cut-and-paste operations between other applications besides gnuplot. I am pretty sure you will find they all suffer the same issues. I can tell you from sad experience that it is frustrating to the point of unusability to clip graphics from Acrobat and paste into Gimp or Powerpoint(via Wine). It works, sometimes, or doesn't work, more often, depending on which machine I'm on, what versions of the various programs and desktop environments are there, and the phase of the moon. The Windows and Mac crowds can justifiably snicker; this aspect of X desktop environments is seriously broken. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Dave D. <dde...@es...> - 2006-07-19 15:57:14
|
Ethan A Merritt <merritt@u.washington.edu> writes: > On Wednesday 19 July 2006 04:46 am, Daniel J Sebald wrote: >> >> > If someone can summarise the problem, and simple steps to reproduce, I >> > can try to find some time to investigate. (Ideally, the steps would >> > not require KDE or gnome or such, since I generally just use fvwm.) > > Problem: > > Commonly used desktops do radically different things with the X clipboard. > I understand that. I'm really just interested (and more as an academic interest) in the assertion that we send all the correct X requests, in the correct order, to the X server, yet the client that requested the selection sometimes fails to get the data. It breaks my internal model of how X works, and that troubles me. An extra XFlush simply should not change the behaviour like this. > See, for example, this rant about incompatible clipboard handling under > various versions of KDE. > > http://www.kdedevelopers.org/taxonomy/term/44?from=20 > > I read a similar rant somewhere about incompatible clipboard handling by > OpenOffice, but can't find it again at the moment. > > This is not a problem we can solve in gnuplot, and I really don't > think it's worth a lot of time spent on the attempt. To convince yourself > of this, I suggest you try out cut-and-paste operations between other > applications besides gnuplot. I am pretty sure you will find they all > suffer the same issues. I can tell you from sad experience that it is > frustrating to the point of unusability to clip graphics from Acrobat and > paste into Gimp or Powerpoint(via Wine). Sure. While I was working at Citrix, we came up with (yet another) helper app that was intended to iron out some of the difficulties. Back then, hardly any X apps could do any kind of graphics cut/paste - it's nice to hear that things are starting to change. (It looks like the helper is still bundled with the unix ica client, which is free for download, in case anyone's interested...) dd -- Dave Denholm <dde...@es...> http://www.esmertec.com |
|
From: Daniel J S. <dan...@ie...> - 2006-07-19 16:13:25
|
Ethan A Merritt wrote: > On Wednesday 19 July 2006 04:46 am, Daniel J Sebald wrote: > >>>If someone can summarise the problem, and simple steps to reproduce, I >>>can try to find some time to investigate. (Ideally, the steps would >>>not require KDE or gnome or such, since I generally just use fvwm.) > > > Problem: > > Commonly used desktops do radically different things with the X clipboard. > > See, for example, this rant about incompatible clipboard handling under > various versions of KDE. > > http://www.kdedevelopers.org/taxonomy/term/44?from=20 > > I read a similar rant somewhere about incompatible clipboard handling by > OpenOffice, but can't find it again at the moment. Rant is good characterization, as there is little regarding X other than to describe pretty much what the documentation calls out. The person is saying there is no actual saving to a clipboard. Right. (Hence having to write the handle_event routine.) There are two of them. Right. TIMESTAMP? In the X documentation. Any complaints about the CLIPBOARD/PRIMARY X selection scheme seem more along that of having to program things one's self. It isn't until discussing the clipboard client where the person starts talking about bugs. A clipboard client is something that keeps a history of things sent to an actual clipboard, that the ranter so desires apparently. That way, after you close your program, stuff will still be available in a clipboard somewhere. That has nothing to do with Gnuplot. I assume any clipboard client still needs to use CLIPBOARD/PRIMARY mechanisms, otherwise it is rewriting the X standard and we'd have to compile under something else or use different libraries or something. > > This is not a problem we can solve in gnuplot, and I really don't > think it's worth a lot of time spent on the attempt. To convince yourself > of this, I suggest you try out cut-and-paste operations between other > applications besides gnuplot. I am pretty sure you will find they all > suffer the same issues. I can tell you from sad experience that it is > frustrating to the point of unusability to clip graphics from Acrobat and > paste into Gimp or Powerpoint(via Wine). It works, sometimes, or doesn't > work, more often, depending on which machine I'm on, what versions of > the various programs and desktop environments are there, and the phase of > the moon. The Windows and Mac crowds can justifiably snicker; this > aspect of X desktop environments is seriously broken. That's not my experience. I've worked on HPs and Suns and PCs running X. I've consistently been able to select stuff and copy it with a center mouse click to other locations. I see now that GIMP appears to be an acception. Dan |
|
From: Dave D. <dde...@es...> - 2006-07-21 09:27:35
|
Daniel J Sebald <dan...@ie...> writes:
> Good news. I believe I have solved the "sometimes transfers, sometimes d=
oesn't" bug.
>
> I've come back to my original concern, which was the MULTIPLE target. Cu=
rrent CVS gnuplot doesn't address that. It returns None for the property. =
However, documentation says that like TIMESTAMP, MULTIPLE should be handle=
d. And properly addressing that (if only partially) seems to have fixed th=
e "sometimes copies, sometimes doesn't" bug.
>
It would certainly make it more efficient, since apps seem to try
MULTIPLE even for a single target. I suspect that the Xt libraries are
doing this, rather than the apps doing it explicitly.
> } else if (reply.xselection.target =3D=3D XA_MULTIPLE) {
>
> Atom *atom =3D &reply.xselection.property;
>
> if (atom[0] =3D=3D None)
> reply.xselection.property =3D None;
> else {
> int i;
> for(i=3D0; atom[2*i] !=3D None; i++) {
>
I don't think you can treat propery as an array of atoms. You must
retrieve the current value of the property, and that returns an array
of atoms. The number of atoms is given by the length of the property.
Googling for XA_MULTIPLE found some source to demonstrate this :
http://mi.eng.cam.ac.uk/~er258/code/dist/x_clipboard/selection.cc
>
> (Technically, MULTIPLE can be anything, so really it should be outside th=
e case statement and not one of the cases... can fix later. I don't think =
many apps will stuff all their requests into a single multiple.)
>
> So, properly responding to MULTIPLE seems to help. But I don't think I h=
ave it quite yet. What concerns me is this MULTIPLE and its atom PRIMARY:
>
> selection request: TARGETS (324) for PRIMARY (1) targets 2
> selection request: MULTIPLE (325) for PRIMARY (1)
> atom PRIMARY (1) : prop 51527025
> atom PRIMARY (1) : prop 51527025
> selection request: PIXMAP (20) for PRIMARY (1)
> selection request: COLORMAP (7) for PRIMARY (1)
>
> The documentation is very sparse on what exactly this property
PRIMARY is supposed to be in the context of MULTIPLE. Anyone have
any idea? (I'd be most grateful!)
As far as I can see, this is covered in the ICCCM, which is the bible
of all things cut/paste
eg
http://tronche.com/gui/x/icccm/sec-2.html#s-2.6.2
The propery contains a list of pairs of atoms, 2*i is the selection,
and 2*i+1 is the type. It is as if the client sent n requests.
> Is it an address of an existing buffer on the requestor's window?
IIRC (it's been a long time) the propery is reused : normally, the
requestor names the property they want the value written into. With
MULTIPLE, the client prefills that property with the types they
want. So the selection owner reads the property to find what the
originator wants.
> Does it want the handler to DELETE the PRIMARY buffer? Is it so
> obvious I can't see what it is?=20
>
> Timoth=E9e, Dave and Bob. Could you please give Patches item #1523316 a =
try if you have time? I'd like your comments.
>
> Dave, are you the "drd" of this comment?
>
Almost certainly.
> /* drd : export the graph via ICCCM primary selection. well... not quite
> * ICCCM since we dont support full list of targets, but this
> * is a start. define EXPORT_SELECTION if you want this feature
> */
>
> What are your thoughts on getting rid of this EXPORT_SELECTION
> on/off variable? My feeling is the mouse/key press route is more
> X11 convention. Also, if we want something like selection when
> plotting, a "set output clipboard" could take its place.=20
>
It's entirely historical. In a sense, I misused my position of gnuplot
maintainer at the time, and only added the selection stuff to test the
corresponding paste code I was working on in my day job (Softwindows
and NTRIGUE at Insignia). So making it a compile-time conditional was
just so that my private code didn't affect other people.
The mouse click / keypress would give you an X event with a real
timestamp, which solves all the CurrentTime issues.
dd
--=20
Dave Denholm <dde...@es...> http://www.esmertec=
.com
|
