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

Re: Copy to clipboard for Linux

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

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

Re: Copy to clipboard for Linux

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

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

Re: Copy to clipboard for Linux

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

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

Re: Copy to clipboard for Linux

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

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

Re: Copy to clipboard for Linux

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

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

Re: PlotWS software

[Kim L. G. <kim...@gm...>]

A "web-based" service (you can plot gnuplot in this wiki):

http://gnuplot.flexkb.net/
http://gnuplot.flexkb.net/wc.dll?gnu~gnuPlotIssues

> [...]
> Here's another gnuplot web service:
>
> http://coda.itsc.uah.edu/service-docs/gnuplots/
> http://coda.itsc.uah.edu/service-docs/gnuplots/script.html

Re: PlotWS software

[Kim L. G. <kim...@gm...>]

Hi PM

On 7/19/06, Petr Mikulik <mi...@ph...> wrote:
> > http://www.omii.ac.uk/docs/2.3.3/managed_programme/plotws/about_plotws.htm
>
> Well, I asked for *other* web software ... but maybe someone provides it;
> currently PlotWS is the only one in its category on the "Links" gnuplot web
> page section.

Here's another gnuplot web service:

http://coda.itsc.uah.edu/service-docs/gnuplots/
http://coda.itsc.uah.edu/service-docs/gnuplots/script.html

Re: PlotWS software

[Kim L. G. <kim...@gm...>]

Hi Broker,

On 7/19/06, Hans-Bernhard Br=F6ker <br...@ph...> wrote:
> [...]
> For telling us about the program, you followed it correctly.  But that
> doesn't mean we're interested in reading about possible bugs in other
> people's programs.  Even if those programs use gnuplot.

 I apologize unreservedly for any issues caused.

> > [...]
> > btw, the plot filename won't contain blanks (ah hah, thanks, now I
> > what those quotes and back slashes were for):
>
> How can you possibly be sure about that?  For all you know, a user could
> well have set up his system such that
>
> > GraphSoapBindingImpl.java:  cmdsFile =3D File.createTempFile("gnuplot_"=
,
> > ".cmds", _tempDir);
>
> returns a pathname with a blank somewhere inside it.  Note it doesn't
> have to be in the filename part of the pathname --- it could be in
> _tempDir, though.

Thanks for the explanation.

Re: Copy to clipboard for Linux

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

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

Re: Copy to clipboard for Linux

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

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

Re: Copy to clipboard for Linux

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

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

Re: Copy to clipboard for Linux

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

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

Re: Copy to clipboard for Linux

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

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

Re: Copy to clipboard for Linux

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

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

Re: Copy to clipboard for Linux

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

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

Re: Copy to clipboard for Linux

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

Bob Fletcher wrote:
> In my original post of this thread, I explained that I did not want to
> interfere with the release of 4.2. Nevertheless, it seems that this may
> have caused a little friction on the team, which I regret.

We're a team?  Huh?

Re: Copy to clipboard for Linux

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

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

Re: Copy to clipboard for Linux

[Bob F. <rob...@kn...>]

In my original post of this thread, I explained that I did not want to
interfere with the release of 4.2. Nevertheless, it seems that this may
have caused a little friction on the team, which I regret.

I appreciate Dan's work and his latest patch but still have some
questions/problems regarding its use. However, from some of the
comments, it seems best to defer these questions until after the release
of the new version.

Bob

Re: Copy to clipboard for Linux

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

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

Re: Copy to clipboard for Linux

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

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

Re: Need Makefile help Re: GNUPLOT_PS_DIR

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

On Tuesday 18 July 2006 10:05 pm, Petr Mikulik wrote:

> > However, to build the *.tex, *.html, *.pdf documentation we
> > pass the source through the C preprocessor again to build the
> > conversion programs doc2tex and so on.  The Makefile in the .../docs
> > directory does not know about conditional compilation flags, so the
> >    #ifdef GNUPLOT_PS_DIR
> > parts of the documentation are lost.
> 
> On the other hand, gnuplot.pdf, gnuplot.dvi, gnuplot.html, ... is the 
> complete gnuplot documentation and it must contains all docs! (Notice that 
> it contains also all terminals.) 

Good point.  But that means I must add to the documentation, explaining
that some people will have only built-in prolog text while other people
have the full set of external files.


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

Re: Need Makefile help Re: GNUPLOT_PS_DIR

[Petr M. <mi...@ph...>]

> I have added this to post.trm, but I notice a problem.
> I made the documentation conditional on GNUPLOT_PS_DIR being
> defined at compile-time. Otherwise we'd be documenting a feature
> that wasn't compiled in.  This works fine for generating gnuplot.gih.
>
> However, to build the *.tex, *.html, *.pdf documentation we
> pass the source through the C preprocessor again to build the
> conversion programs doc2tex and so on.  The Makefile in the .../docs
> directory does not know about conditional compilation flags, so the
>    #ifdef GNUPLOT_PS_DIR
> parts of the documentation are lost.
>
> What is the proper fix?

It is only gnuplot.gih which can contain docs for only the compiled-in 
features.

On the other hand, gnuplot.pdf, gnuplot.dvi, gnuplot.html, ... is the 
complete gnuplot documentation and it must contains all docs! (Notice that 
it contains also all terminals.) Thus, there must be both sections of what 
is happening with and without GNUPLOT_PS_DIR. Please make sure this is 
realized.

---
PM

Re: Need Makefile help Re: GNUPLOT_PS_DIR

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

Ethan Merritt wrote:
> On Tuesday 18 July 2006 06:14 pm, Timoth=C3=A9e Lecomte wrote:
>  =20
>>> The Makefile in the
>>> .../docs directory does not know about conditional compilation
>>> flags, so the #ifdef GNUPLOT_PS_DIR
>>> parts of the documentation are lost.
>>>
>>> What is the proper fix?
>>> Should Makefile.in contain lines like those in .../src/Makefile.am
>>>      =20
>> The attached patch does the trick (for the 'make pdf' target at
>> least, I have not tested the others).
>>    =20
>
> OK, thanks.
>
> Do we have to worry about this breaking if someone deliberately wants
> to compile without GNUPLOT_PS_DIR?
>  =20
How could someone do that ? If it's by using a custom makefile instead=20
of the ./configure... procedure, then he won't use docs/Makefile.in anywa=
y.

Timoth=C3=A9e

Re: Need Makefile help Re: GNUPLOT_PS_DIR

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

On Tuesday 18 July 2006 06:14 pm, Timoth=C3=A9e Lecomte wrote:
> > The Makefile in the
> > .../docs directory does not know about conditional compilation
> > flags, so the #ifdef GNUPLOT_PS_DIR
> > parts of the documentation are lost.
> >
> > What is the proper fix?
> > Should Makefile.in contain lines like those in .../src/Makefile.am
>
> The attached patch does the trick (for the 'make pdf' target at
> least, I have not tested the others).

OK, thanks.

Do we have to worry about this breaking if someone deliberately wants
to compile without GNUPLOT_PS_DIR?

=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: Need Makefile help Re: GNUPLOT_PS_DIR

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

Ethan Merritt wrote:
> On Tuesday 18 July 2006 01:48 am, Bastian Maerkisch wrote:
>  =20
>> before I forget about it (again ;): right now the environment
>> variable GNUPLOT_PS_DIR is not yet documented in gnuplot.doc.
>>    =20
>
> I have added this to post.trm, but I notice a problem.
> I made the documentation conditional on GNUPLOT_PS_DIR being
> defined at compile-time. Otherwise we'd be documenting a feature
> that wasn't compiled in.  This works fine for generating gnuplot.gih.
>
> However, to build the *.tex, *.html, *.pdf documentation we
> pass the source through the C preprocessor again to build the
> conversion programs doc2tex and so on.  The Makefile in the .../docs
> directory does not know about conditional compilation flags, so the
>     #ifdef GNUPLOT_PS_DIR
> parts of the documentation are lost.
>
> What is the proper fix?
> Should Makefile.in contain lines like those in .../src/Makefile.am
>
>   GNUPLOT_PS_DIR=3D$(pkgdatadir)/$(VERSION_MAJOR)/PostScript
>   AM_CPPFLAGS =3D  -DGNUPLOT_PS_DIR=3D\"$(GNUPLOT_PS_DIR)\"
>
> (except I suppose it would be CPPFLAGS because it isn't coming
> from a Makefile.am -=20
The attached patch does the trick (for the 'make pdf' target at least, I=20
have not tested the others).
> when does one need the extra step am->in ??)
>  =20
Here it's a step Makefile.in->Makefile, because automake is not used,=20
but the output of the configure script is.

Timoth=E9e