Menu
▾
▴
gnuplot-beta
|
From: Daniel J S. <dan...@ie...> - 2006-07-21 09:46:25
|
Dave Denholm wrote: > 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. Could be. > I don't think you can treat propery as an array of atoms. D'oh!!! Dumb mistake. Dan |
|
From: Daniel J S. <dan...@ie...> - 2006-07-21 14:49:29
|
Daniel J Sebald wrote: > Dave Denholm wrote: > >> 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. > > > Could be. > > >> I don't think you can treat propery as an array of atoms. > > > D'oh!!! Dumb mistake. Please hold off on testing that patch. I have this MULTIPLE working I believe, but need to weed out some lines. Later this evening. Dan |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-07-19 18:11:54
|
On Wednesday 19 July 2006 09:22 am, Daniel J Sebald wrote: > > See, for example, this rant about incompatible clipboard handling > > under various versions of KDE. > > > > http://www.kdedevelopers.org/taxonomy/term/44?from=20 > > 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. Well, that's one use. It has a lot of other uses, too. I use it all the time. > That has nothing to do with Gnuplot. It has everything to do with gnuplot. It was precisely the change in klipper design that broke gnuplot use under KDE 3.4 and required the previous round of changes by Timothee. The point is that gnuplot has to run under the common desktop environments that people actually use. If those environments arguably do not follow the X11 standard - too bad, we still have to accommodate them. EAM > > 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 -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |
|
From: Dave D. <dde...@es...> - 2006-07-20 08:39:55
|
Ethan Merritt <merritt@u.washington.edu> writes: > > The point is that gnuplot has to run under the common desktop > environments that people actually use. If those environments > arguably do not follow the X11 standard - too bad, we still have > to accommodate them. > If there are multiple incompatible protocols being used, then it may be better (well, more efficient) to write one standalone utility which can convert between the protocols, rather than insisting that every app can speak all the different protocols. Anyway, that's what Citrix was trying to do with the xcapture thing I mentioned the other day. The only interesting app at the time was xv, which had it's own proprietry way of doing cut/paste, so the external helper could translate between that and gnuplot/ica-client dd -- Dave Denholm <dde...@es...> http://www.esmertec.com |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-07-20 17:18:55
|
On Thursday 20 July 2006 01:39 am, Dave Denholm wrote: > Ethan Merritt <merritt@u.washington.edu> writes: > > The point is that gnuplot has to run under the common desktop > > environments that people actually use. > > If there are multiple incompatible protocols being used, then it may > be better (well, more efficient) to write one standalone utility > which can convert between the protocols, rather than insisting that > every app can speak all the different protocols. [tongue in cheek] Well, the main players are KDE and Gnome. Here's what my clouded crystal ball expects will happen: KDE === The distros that push KDE will tweak gnuplot's clipboard code to play nicely with klipper. They will provide a wrapper with configuration menus for all selectable X Resources and program options, providing a state-full save and restore environment for individual users. The resulting package will be called "knuplot". Gnome ===== The distros that push Gnome will tweak gnuplot's clipboard to play nicely with Gnome's clipboard manager. They will configure in some randomly chosen set of program options, and remove the documentation on how to change them. The resulting package will helpfully be named something like "graphity". -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |
|
From: Daniel J S. <dan...@ie...> - 2006-07-20 17:27:20
|
Ethan Merritt wrote: > [tongue in cheek] > KDE > === > The resulting package will be called "knuplot". Sounds about right. > Gnome > ===== > The resulting package will helpfully be named > something like "graphity". I think they will choose gngnuplot (ga-na-ga-nu-plot). Dan |
|
From: <tim...@en...> - 2006-07-20 17:47:29
|
Ethan Merritt wrote: > On Thursday 20 July 2006 01:39 am, Dave Denholm wrote: > =20 >> Ethan Merritt <merritt@u.washington.edu> writes: >> =20 >>> The point is that gnuplot has to run under the common desktop >>> environments that people actually use. >>> =20 >> If there are multiple incompatible protocols being used, then it may >> be better (well, more efficient) to write one standalone utility >> which can convert between the protocols, rather than insisting that >> every app can speak all the different protocols. >> =20 I think the truth should be restored : there is no protocol issue. In february this year, Ethan and I have patched gplt_x11.c to fix=20 klipper, the KDE clipboard utility, that was polling gnuplot for its=20 pixmap every second. Ethan wrote the patch to make gnuplot only respond=20 once to klipper. I wrote a patch to make gnuplot provide the TIMESTAMP=20 atom, because klipper would poll it instead of the pixmap and see that=20 the pixmap has not changed. TIMESTAMP is part of the ICCCM, so the=20 protocol is respected here. It's just that we were a little loosy=20 regarding TIMESTAMP, whereas klipper is expecting it to work properly. I=20 think Ethan's patch may be reverted without making the bug reappear if=20 it is too annoying to prevent multiple pastes of the same pixmap. Then, there is this problem that Daniel has pointed out (*sometimes*=20 nothing is pasted), and again I don't think it is because of protocol=20 differences. It is probably a bug hidden somewhere in the timestamps=20 provided to the Xlib functions, or something like that. And finally, as Daniel pointed out too, the X11 terminal only exports in=20 a "pixmap" form, and that's restrictive. Few apps can use it. But that's=20 not a bug, that's an improvement. That's two bugs and one feature request. The first one is already=20 solved, the second one is not critical for 4.2 but can probably be=20 solved nicely, and as far as the last one is concerned, I am sure Daniel=20 is on the right path. Nothing to worry about. As a side note : > > Gnome > =3D=3D=3D=3D=3D > The distros that push Gnome will tweak gnuplot's clipboard to play > nicely with Gnome's clipboard manager. They will configure in some > randomly chosen set of program options, and remove the documentation > on how to change them. The resulting package will helpfully be named > something like "graphity". > =20 What a nice name !! I love it ! Best regards, Timoth=E9e |
|
From: Daniel J S. <dan...@ie...> - 2006-07-21 04:54:32
|
Timoth=E9e Lecomte wrote: > Ethan Merritt wrote: >=20 >> On Thursday 20 July 2006 01:39 am, Dave Denholm wrote: >> =20 >> >>> Ethan Merritt <merritt@u.washington.edu> writes: >>> =20 >>> >>>> The point is that gnuplot has to run under the common desktop >>>> environments that people actually use. >>>> =20 >>> >>> If there are multiple incompatible protocols being used, then it may >>> be better (well, more efficient) to write one standalone utility >>> which can convert between the protocols, rather than insisting that >>> every app can speak all the different protocols. >>> =20 >=20 > I think the truth should be restored : there is no protocol issue. >=20 > In february this year, Ethan and I have patched gplt_x11.c to fix=20 > klipper, the KDE clipboard utility, that was polling gnuplot for its=20 > pixmap every second. Ethan wrote the patch to make gnuplot only respond= =20 > once to klipper. Oh, OK. So that might explain why the PIXMAP request comes over to gnupl= ot twice in a row from the OpenWrite application. I bet the PIXMAP reque= st fails for some reason and OpenWrite (or X) tries a second time then de= cides after the second time that that is it, and to not try again. On the other hand, Klipper probably has a policy to keep trying until eit= her a success or a "None" for the return property. > I wrote a patch to make gnuplot provide the TIMESTAMP=20 > atom, because klipper would poll it instead of the pixmap and see that=20 > the pixmap has not changed. TIMESTAMP is part of the ICCCM, so the=20 > protocol is respected here. It's always difficult to know exactly what the problem is. Perhaps the T= IMESTAMP was tied in with the failure of PIXMAP request. Well, it seems = to me that the failure of PIXMAP is at issue because that is what Klipper= keeps sending and O.W. appears to send twice. >> Gnome >> =3D=3D=3D=3D=3D >> The distros that push Gnome will tweak gnuplot's clipboard to play >> nicely with Gnome's clipboard manager. They will configure in some >> randomly chosen set of program options, and remove the documentation >> on how to change them. The resulting package will helpfully be named >> something like "graphity". >> =20 >=20 > What a nice name !! I love it ! It is sort of a good one. Dan |
|
From: <tim...@en...> - 2006-07-21 06:41:03
|
Daniel J Sebald wrote: > Timoth=E9e Lecomte wrote: >> >> In february this year, Ethan and I have patched gplt_x11.c to fix=20 >> klipper, the KDE clipboard utility, that was polling gnuplot for its=20 >> pixmap every second. Ethan wrote the patch to make gnuplot only=20 >> respond once to klipper. > > Oh, OK. So that might explain why the PIXMAP request comes over to=20 > gnuplot twice in a row from the OpenWrite application.=20 Hmm, I'm not sure I get it. > I bet the PIXMAP request fails for some reason and OpenWrite (or X)=20 > tries a second time then decides after the second time that that is=20 > it, and to not try again. It should have worked the first time anyway. > > On the other hand, Klipper probably has a policy to keep trying until=20 > either a success or a "None" for the return property. That's unrelated. Klipper does not keep trying because of any failure.=20 Read below. > > >> I wrote a patch to make gnuplot provide the TIMESTAMP atom, because=20 >> klipper would poll it instead of the pixmap and see that the pixmap=20 >> has not changed. TIMESTAMP is part of the ICCCM, so the protocol is=20 >> respected here. > > It's always difficult to know exactly what the problem is. Perhaps=20 > the TIMESTAMP was tied in with the failure of PIXMAP request. Well,=20 > it seems to me that the failure of PIXMAP is at issue because that is=20 > what Klipper keeps sending and O.W. appears to send twice. Again, klipper is not polling because of any failure per se. Let me=20 explain : Klipper is a clipboard manager. It keeps track of the=20 clipboard/selection by retrieving its content as soon as an application=20 puts something in it. When an application has something to offer as a=20 selection, it calls XSetSelectionOwner. Klipper detects that event, and=20 retrieve what the application has to offer. Then, if the application has something *new* to offer, Klipper has to=20 retrieve the clipboard's content *again*. How does Klipper know that the=20 clipboard contains something new ? It polls the application for the=20 TIMESTAMP atom, which is supposed to contain the age of the application=20 data, and retrieves the clipboard's content each time TIMESTAMP has=20 changed. If the application does not answer to TIMESTAMP, then Klipper=20 chooses to poll directly the clipboard's content each second, and you=20 could see klipper history getting filled by identical plot images. Ethan's approach was pretty straightforward : if Klipper is polling each=20 second, let's simply stop it as soon as it got it once. We realized later the TIMESTAMP thing from the blog of a klipper=20 developper. It wasn't implemented at all in gnuplot. As far as OpenWriter is concerned, it am pretty sure it does not even=20 call the TIMESTAMP atom, why would it ? However, it should succeed at retrieving the pixmap at the first try. If=20 it doesn't, then there's definitely a bug. I am sorry for the confusion, but it's worth noting that there are two=20 "timestamps" in the X11 context : the one I am talking about above is=20 the atom that application should answer to to satisfy klipper. The other one that Dave was talking about is the argument that you need=20 to pass to most Xlib calls. It should be the time of the event that=20 triggered the call, but as gnuplot is not completely event-driven (at=20 least the events are on the command-line, not managed by X), we don't=20 have any relevant time to provide here, so CurrentTime has been used,=20 which tells the server to use the time when it receives the call. I hope it is clearer. Best regards, Timoth=E9e |
|
From: Daniel J S. <dan...@ie...> - 2007-02-07 14:05:38
|
On the topic of key bindings, I've updated clipboard patch #1523316. Dan |
|
From: Dave D. <dde...@es...> - 2006-07-20 08:42:34
|
Daniel J Sebald <dan...@ie...> writes: > > According to the present code, if everyone is accomodated then > XA_PRIMARY is the solution. But how is it that supporting both > XA_PRIMARY and XA_CLIPBOARD with a possible term option to map > things so that both are one way or another doesn't accomodate all > environments? What I'm suggesting doesn't take away the XA_PRIMARY > route. > Hmm - just agreeing to use a particular selection isn't really enough. We have to agree on what format the data is sent. Sending a PIXMAP id isn't really the obvious format - granted that these days, most people use truecolor, but not so long ago, pseudocolor was common, and just a pixmap on its own is not enough, since you also need a palette. dd -- Dave Denholm <dde...@es...> http://www.esmertec.com |
|
From: Daniel J S. <dan...@ie...> - 2006-07-20 17:11:20
|
Dave Denholm wrote:
> Daniel J Sebald <dan...@ie...> writes:
>
>
>>According to the present code, if everyone is accomodated then
>>XA_PRIMARY is the solution. But how is it that supporting both
>>XA_PRIMARY and XA_CLIPBOARD with a possible term option to map
>>things so that both are one way or another doesn't accomodate all
>>environments? What I'm suggesting doesn't take away the XA_PRIMARY
>>route.
>>
>
>
> Hmm - just agreeing to use a particular selection isn't really
> enough. We have to agree on what format the data is sent. Sending a
> PIXMAP id isn't really the obvious format - granted that these days,
> most people use truecolor, but not so long ago, pseudocolor was
> common, and just a pixmap on its own is not enough, since you also
> need a palette.
I have said this. I have added the format image/x-xpixmap to the the SourceForge patch if the XPM library is linked in with the software:
#ifdef USE_X11_XPM
if (image_x_xpixmap == 0)
image_x_xpixmap = XInternAtom(dpy, "image/x-xpixmap", False);
#endif
so that Abiword now works. It was fairly easy to do. Simply put what would have gone to a file in a memory buffer and pass back to the client the address of that buffer and the number of characters.
I also propose that we can increase the targets to all the MIME categories (image/x-xpixmap is a MIME name) and move small portions of this code into the core of gnuplot, as opposed to the gnuplot_x11 program, so that we may have in addition a truely versatile clipboard inside the core that support PNG, JPEG, etc. It would be a simple matter of redirecting what gets dumped to the standard out to a memory buffer.
Dan
|
|
From: Daniel J S. <dan...@ie...> - 2006-07-19 20:22:08
|
Ethan Merritt wrote: > That way, after you close your >>program, stuff will still be available in a clipboard somewhere. > > > Well, that's one use. It has a lot of other uses, too. > I use it all the time. Sure, but Gnuplot's world stops at the XA_PRIMARY selection currently. >>That has nothing to do with Gnuplot. > > > It has everything to do with gnuplot. > It was precisely the change in klipper design that broke gnuplot > use under KDE 3.4 and required the previous round of changes by > Timothee. I will search the archive and look for what the change was. > The point is that gnuplot has to run under the common desktop > environments that people actually use. If those environments > arguably do not follow the X11 standard - too bad, we still have > to accommodate them. According to the present code, if everyone is accomodated then XA_PRIMARY is the solution. But how is it that supporting both XA_PRIMARY and XA_CLIPBOARD with a possible term option to map things so that both are one way or another doesn't accomodate all environments? What I'm suggesting doesn't take away the XA_PRIMARY route. Dan |
|
From: Daniel J S. <dan...@ie...> - 2006-07-21 08:51:56
|
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 ha=
ndled. And properly addressing that (if only partially) seems to have fi=
xed the "sometimes copies, sometimes doesn't" bug.
} 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++) {
if (atom[2*i] =3D=3D XA_PRIMARY || atom[2*i] =3D=3D XA_CLIPBOARD)
/* Not completely sure what to do with these requests.
* Swap a buffer, perhaps? Or maybe it is a request
* to go to a global client for copying.
*/
{}
else
/* Setting to None means did not convert target */
atom[2*i] =3D None;
/* Not exactly sure when to end either. */
if (atom[2*i] =3D=3D None || !atom[2*i + 1])
break;
}
}
} else {
(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 thin=
k 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!) Is it an address of an existing buffer on the request=
or's window? Does it want the handler to DELETE the PRIMARY buffer? Is =
it so obvious I can't see what it is?
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?
/* 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 var=
iable? My feeling is the mouse/key press route is more X11 convention. =
Also, if we want something like selection when plotting, a "set output cl=
ipboard" could take its place.
Dan
|
