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

Re: -persist command line option and the wxWidgets terminal

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

Timoth=C3=A9e Lecomte wrote:
> Hi,
>=20
> I am working on the bug #1527701, and I need some advice.
>=20
> The bug comes from the current implementation of "persist" in the wxt=20
> terminal.
>=20
> This option is used by external programs, like maxima, to control=20
> gnuplot. They send their commands through a pipe or a file or whatever,=
=20
> they let gnuplot exit at the end of the commands, but as they want the=20
> plot windows to stay open, they use "persist".

They issue the commands for a plot and then close gnuplot?  Well it shoul=
dn't be done that way.  That is not what persist is intended for.  The pr=
ogram should keep the pipe open.

Octave opens gnuplot and holds onto the pipe.  (If I recall, it uses a fo=
rk...  The person that oversees Octave is a very good and organized progr=
ammer.)

I can make a guess as to what may be going on here.  We've had this discu=
ssion many times in the past, which is the fact that gnuplot only retains=
 information about a single plot.  If there are several X windows open, s=
till it is only the information about the most recent plot that is availa=
ble.  Hence, you'll see that the mouse functions only work for the most r=
ecent X plot.

Well, I know that for Octave, John decided to open a new instance of gnup=
lot for every plot created.  That way, ever plot in Octave does have its =
information retained.  John figured that gnuplot was a rather small progr=
am so not much harm done.

Maybe Maxima people have the same philosophy to get multiple windows, onl=
y they figure why keep so many versions of gnuplot around?  It's wasting =
memory.  If Maxima had a multiple window version of the terminal (I assum=
e we're talking of Windows here, no?) then perhaps they would be willing =
to change their program.

Dan

Documentation for 4.2

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

Hi,

As Ethan said a few days ago, the remaining work for 4.2 is decreasing,=20
and the main things to care about are now the documentation and the=20
version tags.

As far as the documentation is concerned, I would like to know what=20
should be done in the "news" section of gnuplot.doc. Currently there is=20
a section entitled "What's new in 4.2" and there is also the section=20
"What's new in 4.0". It seems to me that the latter should be removed,=20
after having checked that the items are well documented in the=20
appropriate places. Does that sound good ?

As a side-note, I found the following comment (gnuplot.doc:6857):
"This was valid only for gnuplot 4.0 (now mousing is on by default as in
 the case of other screen terminals):
 X11 mouse support is turned on by default if standard input comes from a
 terminal (tty). Mouse support is turned off if standard input does not
 come from a tty, e.g. a pipe. If you want to use mouse support while=20
writing
 to gnuplot from a pipe, the mouse must be turned on *before* starting=20
the x11
 driver, e.g. immediately after startup with the explicit command `set=20
mouse`.
 Beware: on some UNIX flavours, special input devices as /dev/null might =
not
 be `select-able`; turning on the mouse when using such devices will hang
 gnuplot."

I think this paragraph should be removed entirely. Please tell me if it=20
is appropriate.

Best regards,

Timoth=C3=A9e

Re: -persist command line option and the wxWidgets terminal

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

Timoth=C3=A9e Lecomte wrote:

> So do you think the implementation for the wxWidgets terminal is=
=20
> satisfying (i.e. gnuplot's interactive command line stops, but gnup=
lot=20
> doesn't exist until all windows are closed) ?

Yes.  It's the only sensible implementation possible for a=20
single-process build of gnuplot.  wgnuplot, e.g., behaves the same wa=
y.

Re: -persist command line option and the wxWidgets terminal

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

Hans-Bernhard Br=C3=B6ker wrote:
> Timoth=C3=A9e Lecomte wrote:
>
>> So do you think the implementation for the wxWidgets terminal is=20
>> satisfying (i.e. gnuplot's interactive command line stops, but=20
>> gnuplot doesn't exist until all windows are closed) ?
>
> Yes.  It's the only sensible implementation possible for a=20
> single-process build of gnuplot.  wgnuplot, e.g., behaves the same way.
>
>
Ok, bug filed for maxima here :

   =20
http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1528658&grou=
p_id=3D4933&atid=3D104933

Timoth=C3=A9e

Re: -persist command line option and the wxWidgets terminal

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

Daniel J Sebald wrote:
> Timoth=C3=A9e Lecomte wrote:
>>
>> The bug comes from the current implementation of "persist" in the wxt=20
>> terminal.
>>
>> This option is used by external programs, like maxima, to control=20
>> gnuplot. They send their commands through a pipe or a file or=20
>> whatever, they let gnuplot exit at the end of the commands, but as=20
>> they want the plot windows to stay open, they use "persist".
>
> They issue the commands for a plot and then close gnuplot?  Well it=20
> shouldn't be done that way.  That is not what persist is intended=20
> for.  The program should keep the pipe open.
>
> Octave opens gnuplot and holds onto the pipe.  (If I recall, it uses a=20
> fork...  The person that oversees Octave is a very good and organized=20
> programmer.)

That's why I read once that for his own work he is (was?) actually not=20
using octave's plot() functions, but writes a makefile that would run a=20
gnuplot script when the data changes ;-)

>
> I can make a guess as to what may be going on here.  We've had this=20
> discussion many times in the past, which is the fact that gnuplot only=20
> retains information about a single plot.  If there are several X=20
> windows open, still it is only the information about the most recent=20
> plot that is available.  Hence, you'll see that the mouse functions=20
> only work for the most recent X plot.
And worse, with the "persist" implementation in the X11 terminal, you=20
lose all zooming capabilities once gnuplot has exited.
That's an additional argument that I forgor to mention if my maxima bug=20
report...
>
> Well, I know that for Octave, John decided to open a new instance of=20
> gnuplot for every plot created.  That way, ever plot in Octave does=20
> have its information retained.  John figured that gnuplot was a rather=20
> small program so not much harm done.
>
> Maybe Maxima people have the same philosophy to get multiple windows,=20
> only they figure why keep so many versions of gnuplot around?  It's=20
> wasting memory.
I don't really get what you mean here.
> If Maxima had a multiple window version of the terminal (I assume=20
> we're talking of Windows here, no?) then perhaps they would be willing=20
> to change their program.
We are talking about UNIX here. Under Windows, maxima does something=20
else (I think it is using the png terminal, and copy the image to their=20
home-made gui).

Timoth=C3=A9e

Re: problem building latest cvs snapshot

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

Hans-Bernhard Br=F6ker wrote:
> Dmitri A. Sergatskov wrote:
>  =20
>> make[2]: Leaving directory `/home/dima/src/gnuplot/demo'
>> Making all in tutorial
>> make[2]: Entering directory `/home/dima/src/gnuplot/tutorial'
>> Expected X11 driver: /usr/local/libexec/gnuplot/4.1/gnuplot_x11
>> Exec failed: No such file or directory
>> See 'help x11' for more details
>>    =20
>
> gnuplot_x11 isn't even supposed to be started by this run of gnuplot.
>  =20
In addition to the explanation in my previous mail, here is the patch=20
that caused this behaviour :

http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1509033&grou=
p_id=3D2055&atid=3D102055

Best regards,

Timoth=E9e

Re: -persist command line option and the wxWidgets terminal

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

Hans-Bernhard Br=C3=B6ker wrote:
> Timoth=C3=A9e Lecomte wrote:
>
>> This option is used by external programs, like maxima, to control=20
>> gnuplot. They send their commands through a pipe or a file or=20
>> whatever, they let gnuplot exit at the end of the commands, but as=20
>> they want the plot windows to stay open, they use "persist".
>
> The problem is that these programs are abusing persist.  Persist isn't
> useful for external programs that will keep on running and doing other
> things while gnuplot sits there.  They should either keep gnuplot, and=20
> their pipe to it, open, or not care about whether gnuplot terminates=20
> itself or not.
So do you think the implementation for the wxWidgets terminal is=20
satisfying (i.e. gnuplot's interactive command line stops, but gnuplot=20
doesn't exist until all windows are closed) ?

If yes, I will file a bug against maxima then.
>
>> P.S. : I tend to think that "persist" was a bad idea in the first plac=
e=20
>
> It wasn't.  But Maxima shouldn't be using it.

Ok.

Best regards,

Timoth=C3=A9e

Re: problem building latest cvs snapshot

[Dmitri A. S. <das...@gm...>]

On 7/25/06, Timoth=E9e Lecomte <tim...@en...> wrote:

>
> Can you please try the attached patch ?
>

>
> Timoth=E9e
>
>

It worked.

Thanks!

Dmitri.
--

Re: -persist command line option and the wxWidgets terminal

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

Timoth=C3=A9e Lecomte wrote:

> This option is used by external programs, like maxima, to control=
=20
> gnuplot. They send their commands through a pipe or a file or whate=
ver,=20
> they let gnuplot exit at the end of the commands, but as they want =
the=20
> plot windows to stay open, they use "persist".

The problem is that these programs are abusing persist.  Persist isn'=
t
useful for external programs that will keep on running and doing othe=
r
things while gnuplot sits there.  They should either keep gnuplot, an=
d=20
their pipe to it, open, or not care about whether gnuplot terminates=
=20
itself or not.

> P.S. : I tend to think that "persist" was a bad idea in the first p=
lace=20

It wasn't.  But Maxima shouldn't be using it.

Re: problem building latest cvs snapshot

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

Hans-Bernhard Br=F6ker wrote:
> Dmitri A. Sergatskov wrote:
>=20
>>make[2]: Leaving directory `/home/dima/src/gnuplot/demo'
>>Making all in tutorial
>>make[2]: Entering directory `/home/dima/src/gnuplot/tutorial'
>>Expected X11 driver: /usr/local/libexec/gnuplot/4.1/gnuplot_x11
>>Exec failed: No such file or directory
>>See 'help x11' for more details

Hans,

It appears that my email didn't make it through the gnuplot-beta server. =
 I'll forward...

Re: problem building latest cvs snapshot

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

Dmitri A. Sergatskov wrote:
> make[2]: Leaving directory `/home/dima/src/gnuplot/demo'
> Making all in tutorial
> make[2]: Entering directory `/home/dima/src/gnuplot/tutorial'
> Expected X11 driver: /usr/local/libexec/gnuplot/4.1/gnuplot_x11
> Exec failed: No such file or directory
> See 'help x11' for more details

gnuplot_x11 isn't even supposed to be started by this run of gnuplot. 
And it isn't -- I know, because I have no 
/usr/local/libexec/gnuplot/$version/gnuplot_x11 for the binary I've just 
tested, and it did work.  In other words, it's not the exec of 
gnuplot_x11 that failed you.  You'll have to dig deeper.

I think you'll have to either reproduce the gnuplot runs done in the 
tutorial directory inside a debugger, or do likewise with 'strace', to 
find out *which* exec() failed.

problem building latest cvs snapshot

[Dmitri A. S. <das...@gm...>]

Today's cvs on Fedora Core 5 (x86_64).
./prepare
CFLAGS="-O3 -m64 -pipe"
./configure --with-readline=gnu
make
make[2]: Leaving directory `/home/dima/src/gnuplot/demo'
Making all in tutorial
make[2]: Entering directory `/home/dima/src/gnuplot/tutorial'
Expected X11 driver: /usr/local/libexec/gnuplot/4.1/gnuplot_x11
Exec failed: No such file or directory
See 'help x11' for more details
make[2]: *** [eg1.tex] Error 141
make[2]: Leaving directory `/home/dima/src/gnuplot/tutorial'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/dima/src/gnuplot'
make: *** [all] Error 2

(Of course it worked on the computer that had an older version
installed in /usr/local ...)

Sincerely,

Dmitri.
--

-persist command line option and the wxWidgets terminal

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

Hi,

I am working on the bug #1527701, and I need some advice.

The bug comes from the current implementation of "persist" in the wxt=20
terminal.

This option is used by external programs, like maxima, to control=20
gnuplot. They send their commands through a pipe or a file or whatever,=20
they let gnuplot exit at the end of the commands, but as they want the=20
plot windows to stay open, they use "persist".

The X11 terminal lives in a separate process, so for this terminal the=20
"persist" option makes gnuplot main process to exit while the=20
gnuplot_x11 stays alive until the user closes all the windows.

However, the wxt terminal is not a separate process. It lives in gnuplot=20
main executable, so when gnuplot exits the plot windows can't but be=20
closed. That's why I implemented "persist" so that gnuplot won't exit=20
until all wxWidgets windows are closed. But obviously that's not what=20
maxima (and probably others, I have not tried octave) wants. I thought=20
about using fork() to duplicate the process, then close the parent=20
process so that maxima and friends will be happy, and let the child=20
process take care of the windows. Although it sounds nice, it is=20
actually dangerous as 1) fork() is not portable, 2) there are a bunch of=20
undetermined behaviours when using fork() in a multithreaded application=20
(the wxWidgets main loop lives in a separate thread, so gnuplot is=20
multithreaded in this context) or an application using X.

I'm stuck.

Do you have any idea to implement "persist" in this context ?

Best regards,

Timoth=C3=A9e

P.S. : I tend to think that "persist" was a bad idea in the first place=20
: why wouldn't maxima simply leave gnuplot alone and continue its work ?=20
But I don't want to break any established behaviour either...

Re: gnuplot.doc suggestions

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

Bastian Maerkisch wrote:
> Hi,
> I just came across some little things in the docs:
>
> * There's still a reference to 'if compiled with pm3d' in `help epslate=
x`
>  =20
I removed that one.
> * There's a reference to `set ticscale`, which is deprecated in favour =
of `set tics scale`, in `help epslatex`.
>  =20
Fixed too.
> * The list of terminals which support pm3d is incomplete (wxt is missin=
g)
>  =20
I've added wxt in this list (and in other lists where it is making sense).
> * I suggest a similar list for `enhanced text`.
>  =20
wxt added too (the list is in the "News" section at the beginning)
I guess
> * The `enhanced text` section is labeled `enhanced postscript` (at leas=
t on Windows and OS/2).
>    That's a bit misleading nowadays, I think.
>  =20
And I must add that the corresponding help text lives in term/post.trm,=20
not in docs/gnuplot.doc. Should probably be moved, but that's not critica=
l.
As per the `enhanced postscript` name, it is only one of several working=20
ways to call it (among `enhanced` and `enhanced text` for example).=20
There is only one reference to `enhanced postscript` in the doc, which=20
seems to be refering to the Postscript terminal precisely. I will look=20
into that.

The doc definitely needs some attention, in particular the whole "What's=20
new" section. I can do my best using what is described in the NEWS file,=20
but if I can be pointed out the changes that are not mentioned in that=20
file, that would help.

Thanks for the report.

Best regards,

Timoth=E9e

Re: Version 4.2 - ringing the bell that signals the final lap

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

> So in my judgment we are essentially ready for a code freeze and the start
> of a 4.2 branch on CVS from which to build a candidate release package.

OK, while in stasis, perhaps keep a list of patches that are ready to go right after 4.2.  (To help avoid updating patches after having embarked on any major new changes.)  Here are a few (listed in application order):

[ gnuplot-Patches-1523316 ] improved CLIPBOARD and PRIMARY per X conventions
[ gnuplot-Patches-1523744 ] cleanup and cruft removal, apply soon after version 4.2
[ gnuplot-Bugs-1488168 ] z_floor and z_ceiling based on xyplane.absolute
[ gnuplot-Bugs-1004754 ] Tics and grid slightly outside border
[ gnuplot-Bugs-1525665 ] help has problems with
[ gnuplot-Patches-1508316 ] Allow multiple strings to signify "missing"

As for the clipboard patch.  I think the problem with Klipper and elsewhere may have been the fact that MULTIPLE is not a properly handled target, which is supposedly mandatory in the ICCCM.


If this is going to involve talking to the original copyright holders again, I recall searching the web for Colin Kelly a year or so ago.  Perhaps this is the person:

http://investor.callwave.com/phoenix.zhtml?c=180005&p=irol-govBio&ID=117109

The person's technical background might possibly fit but maybe a few years too young.  Does Villanova U ring a bell for anyone who may have corresponded with him at the time?

Dan

Re: Copy to clipboard for Linux

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

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

Re: Copy to clipboard for Linux

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

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

Re: Copy to clipboard for Linux

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

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

Re: Copy to clipboard for Linux

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

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

Re: Copy to clipboard for Linux

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

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

Version 4.2 - ringing the bell that signals the final lap

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

I am now tracking a grand total of two patches that I'd like to see go
into version 4.2 :
  #1526204  Make x11 and wxt terminals agree on the {no}ctrlq option syntax
            (pretty trivial patch, but I'll leave it for you have a look at
             before putting it in cvs on my way out of town)
  #1519215  Waiting for final round of updates to Japanese docs from Shige

And there is one "bug" (more of a feature request)
  #1515069  "set term pm" doesn't allow specifying a default font
            (some OS2 afficianado could probably fix this in no time, but
             it's not critical anyway) 

So in my judgment we are essentially ready for a code freeze and the start
of a 4.2 branch on CVS from which to build a candidate release package.

Conveniently for me, I'm leaving town for a week and expect little useful
net access.  What a great thing it would be if I return to find that you
guys have taken care of the versioning tags, code branch, and final
updates to the docs while I'm gone :-)

	Ethan

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

gnuplot.doc suggestions

[Bastian M. <bma...@we...>]

Hi,
I just came across some little things in the docs:

* There's still a reference to 'if compiled with pm3d' in `help epslatex`
* There's a reference to `set ticscale`, which is deprecated in favour of `set tics scale`, in `help epslatex`.
* The list of terminals which support pm3d is incomplete (wxt is missing)
* I suggest a similar list for `enhanced text`.
* The `enhanced text` section is labeled `enhanced postscript` (at least on Windows and OS/2).
   That's a bit misleading nowadays, I think.

Bastian

Re: Copy to clipboard for Linux

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

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

Re: Need Makefile help Re: GNUPLOT_PS_DIR

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

Petr Mikulik wrote:
> It is only gnuplot.gih which can contain docs for only the compiled-in 
> features.

Not quite.  Same goes for the Windows and OS/2 help files (gnuplot.rtf 
--> wgnuplot.hlp, gnuplot.ipf --> gnuplot.???)

Re: Copy to clipboard for Linux

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

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