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

Re: Copy to clipboard for Linux

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

>> this new file into the OO document. This is not quite as convenient
>> as the Windows implementation, but once I get the hot key binding
>> working correctly, it should be good enough.

Well, you copy a bitmap image, but ... what is it? Usually something 
uncompressed with unknown resolution. Going via png file with known 
dimension, saved to disk, cropped with an image editor, is a way to get 
what you want; and much smaller in size afterwards.
   Or, is there an option in office apps to compress all images? I remember 
some versions claimed to have it, but I don't which soft.

---
PM

Re: Copy to clipboard for Linux

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

Ethan Merritt wrote:
> On Friday 14 July 2006 10:56 am, Bob Fletcher wrote:
> 
>>Shoot! Well, I tried all of the obvious things - except KDE and
>>klipper. (I am having enough 'fun' trying to learn GNOME.) The
>>cut/paste operation is very erratic and usually will not work. As
>>suggested by others, I tried entering "e" for replot with no results.
>>I guess I am having the same sort of flaky performance described by
>>Dmitri.
> 
> 
> Part of the confusion in an earlier post is the expectation that you
> can "copy" once, and "paste" multiple times from it.  This is not
> true for gnuplot+X11 by default.  An pixel image placed on the
> clipboard can be pasted elsewhere, but then it's not on the clipboard
> any more.

I'm not an X-pert (the usual disclaimer), but I believe there is indeed some confusion here, and I think it is with the phrase "clipboard".  From what I'm seeing in the code, this feature of being able to copy the X11 gnuplot image is not using the clipboard.  It is using some kind of X11 scheme of "atoms" and is more in the line of a "selection" in this case.

    XSetSelectionOwner(dpy, EXPORT_SELECTION, plot->window, CurrentTime);

I intentionally did not use the term "clipboard" above.  A "selection" I'm guessing is more like the center mouse behavior we come to think of in X, i.e., one can quickly hilight a chunk of text in one window and copy it into another window.

"clipboard" would be more like CNTR-C saves it into a cut buffer where the data sits, CNTR-V then recalls that data.

"clipboard" is more permanent, "selection" is more ephemeral.  So I think in this case the gnuplot image is "selected" inherently when the plot is done.  But after copying the image once into OpenWrite, the gnuplot image becomes "deselected" or out of scope somehow.  To verify this, after creating the image, use the center mouse button to select something else; anything.  The center mouse button no longer places the gnuplot image in OpenWRite.

OK, so first point:

1) The phrase "clipboard" shouldn't be used the way gnuplot is currently program.

2) Well, it would be nice if this behavior were more in line with typically X applications.  That is, this "selection" feature should not be driven by the plotting action, but by some kind of mouse action.  The phrase I see at:

http://tronche.com/gui/x/xlib/window-information/selection.html

is ``the last thing the user clicked on''.  So it would be nice if there were a mouse action that would cause the X11 gnuplot image to be the "selection", and when this happens the typical thing is for the object in question to be highlighted in contrast colors or XOR-ed with a blue shade or something--like what happens in a web browser.

3) This thing about being able to copy the "selected" image repeatedly...  That is a bit peculiar because with other X11 windows things that have been "selected" can be copied time and again so long as they are not deselected.  So, it seems we should be able to improve upon that part somehow and get rid of this "sometimes works, sometimes not" kind of thing.

As an example, in a web browser I've selected an image from a local newspaper's website.  I can continually copy the "selection" into OpenWrite.  First there is some text that appears with the caption and then that is replaced by the image.  I keep pressing the center button and keep getting a new image.

4) As for "clipboard".  There may be some way of actually doing that as well via X functions.  There is this thing called interclient communication functions:

http://tronche.com/gui/x/xlib/ICC/

which appears to deal with Window Managers in some way.  However...

Before going down that path, I'm wondering if the actual clipboard can't be made easier than that.  Most of these X applications, once something is "selected", almost always seem to be "clipboard-able" by typing, in my case, CNTRL-C/CNTRL-V.  So, right now supposedly Gnuplot is "selecting" the plot inherently upon "plot <foo>".  Does the gnuplot X window pass the keyboard sequence down the line if it doesn't interpret the key sequence it receives?  (I type 'h' right now for a list of keystroke interpretations and don't see a CNTRL-C in the list.)  I'm just wondering right now why the inherently selected X11 gnuplot image can't be copied to the clipboard buffer with CNTRL-C.


> Taking a step to the side ...

There are advantages to this.

Dan

Re: Copy to clipboard for Linux

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

On Friday 14 July 2006 02:06 pm, Bob Fletcher wrote:
> On Fri, 2006-07-14 at 11:52 -0700, Ethan Merritt wrote:
> 
> I still haven't been able to get the hot key binding to work properly,

That sounds like an entirely different problem.
Please provide a detailed description.

> but I can enter the commands on the command 
> line and create the .png (or .emf) file. As you said, I can then drag
> this new file into the OO document. This is not quite as convenient
> as the Windows implementation, but once I get the hot key binding
> working correctly, it should be good enough.

The suggestion was not intended to maximize convenience, but rather
the resulting plot and document quality.  I would recommend the same
for Windows.  In fact, if anything the Windows bitmap image is worse
than that for x11 (certainly it's worse than for the new wxt terminal),
and you would see correspondingly more gain from using png/emf/eps


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

Re: strange box-offset

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

Mojca Miklavec wrote:
> Hello,
>
> Can you please take a look at http://pub.mojca.org/gnuplot/bug/box-offs=
et.png?
>
> The source is available in the same folder. Some boxes have an
> additional frame offset by 1 pixel, which seems pretty strange to me.
> This only happens at some specific sizes and some specific plots.
>
> When I tried the same example with the ConTeXt terminal (might be just
> any text-based terminal) I spotted the following in the output:
>
> fill unitsquare xyscaled (2.04,32.09) shifted (52.15,18.03);
> draw (52.15,18.03)--(52.15,50.11)--(54.18,50.11)--(54.18,18.03)
> 	--(52.15,18.03)--cycle;
>
> 32.09+18.03=3D50.12, but the rectangle is filled up to 50.11
>
> There seems to be a round-off problem.
>
> Mojca
>  =20
I think I have seen the same problem when trying to make the wxWidgets=20
terminal handle fillboxes correctly. I could not make 'test' and 'load=20
"fillstyle.dem"' work correctly at the same time. I chose to make 'test'=20
not to work, i.e. give the offset as you see in your graph, but make=20
fillstyle.dem work, as the latter is the real use case. (To see it in=20
the wxWidgets terminal, you have to disable the oversampling, otherwise=20
the offset is a decimal and is negligible in the output).

Best regards,

Timoth=E9e

strange box-offset

[Mojca M. <moj...@gm...>]

Hello,

Can you please take a look at http://pub.mojca.org/gnuplot/bug/box-offset.png?

The source is available in the same folder. Some boxes have an
additional frame offset by 1 pixel, which seems pretty strange to me.
This only happens at some specific sizes and some specific plots.

When I tried the same example with the ConTeXt terminal (might be just
any text-based terminal) I spotted the following in the output:

fill unitsquare xyscaled (2.04,32.09) shifted (52.15,18.03);
draw (52.15,18.03)--(52.15,50.11)--(54.18,50.11)--(54.18,18.03)
	--(52.15,18.03)--cycle;

32.09+18.03=50.12, but the rectangle is filled up to 50.11

There seems to be a round-off problem.

Mojca

compile bug in latest CVS

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

make[1]: Entering directory `/usr/local/src/gnuplot-cutpaste/gnuplot/docs'
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../src -I../term -I/usr/X11R6/include -I/usr/local/include -I/usr/local/include -g -O2 -c doc2gih.c
In file included from ../term/post.trm:75,
                 from ../src/term.h:376,
                 from doc2x.h:72,
                 from doc2gih.c:57:
../src/variable.h:85: error: syntax error before "char"

Re: Copy to clipboard for Linux

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

On Fri, 2006-07-14 at 11:52 -0700, Ethan Merritt wrote:
> On Friday 14 July 2006 10:56 am, Bob Fletcher wrote:
> >
snip
> Taking a step to the side ...
> As I understand it, what you want to do is import the plot into
> an OpenOffice doc.  I would suggest to you that even if you get
> the X11 cut/paste working, this is a poor solution to the task
> at hand.  You would be better off binding a hotkey to a command
> sequence like:
> 
> "set term push; set term png; set output /tmp/plot.png; \
>  replot; set term pop"
> 
> Then you can easily import the png image.
> The same could be done for "set term post eps".
> 
> The image quality from either png or eps should be way better
> than the bitmapped X11 plot image.
> 

OK, thanks Ethan. I still haven't been able to get the hot key binding
to work properly, but I can enter the commands on the command line and
create the .png (or .emf) file. As you said, I can then drag this new
file into the OO document. This is not quite as convenient as the
Windows implementation, but once I get the hot key binding working
correctly, it should be good enough.
Thanks again,
Bob

Re: Copy to clipboard for Linux

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

On Fri, 2006-07-14 at 22:19 +0200, Petr Mikulik wrote:
> > I did notice one interesting thing. If the mouse is activated in gnuplot
> > and I double left click in the figure, the mouse position numbers are
> > pasted into the OO document with the center mouse button.
> 
> That's the default operation for doubleclick, see hotkey 'h' and 'help 
> mouse'.
> 
> ---
> PM

Oh yes, I see that now. Thanks,
Bob

Re: Copy to clipboard for Linux

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

> I did notice one interesting thing. If the mouse is activated in gnuplot
> and I double left click in the figure, the mouse position numbers are
> pasted into the OO document with the center mouse button.

That's the default operation for doubleclick, see hotkey 'h' and 'help 
mouse'.

---
PM

Re: Windows gnuplot 4.1 libpng problems

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

> I recently started to use gnuplot 4.0, but found I needed some features in
> 4.1.
>
> When I try the provided binaries the program crashes, when I try and use
> this simple script:
> reset
> set terminal png
> set output 'temp.png'
>
> plot(sin(x))

When it crashes?
BTW, do yo do
 	set out; set term pop
afterwards?

> Can anyone recommend how to compile the code? Or just give me a binary that
> works with PNGs... thanks
>
> BTW I'm using Visual Studio .Net 2003, on Windows XP, with the gnuplot code
> from CVS about 30minutes ago (as well as snapshots from April).

It works for me (Wine 0.9.17 under SUSE Linux).

---
PM

Windows gnuplot 4.1 libpng problems

[Andrew B. <an...@br...>]

Hi,
I recently started to use gnuplot 4.0, but found I needed some features in 
4.1.

When I try the provided binaries the program crashes, when I try and use 
this simple script:
reset
set terminal png
set output 'temp.png'

plot(sin(x))

So I figured it was a bug so I tried compiling from the latest CVS source. 
After many hours of compiling/recompiling, etc, I still have the same crash. 
However if I use a different terminal (other than png) the image is plotted 
fine. So I assume this is a problem with libpng?

I found this old posting 
http://sourceforge.net/mailarchive/forum.php?thread_id=9178285&forum_id=6027 
stating the same problem, but looking the CVS is compiling with /MT.

Can anyone recommend how to compile the code? Or just give me a binary that 
works with PNGs... thanks

BTW I'm using Visual Studio .Net 2003, on Windows XP, with the gnuplot code 
from CVS about 30minutes ago (as well as snapshots from April).

Thanks for any help
Andrew 

Re: Compiler warnings from strict ISO C90 checking

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

Timoth=E9e Lecomte wrote:
> Ethan Merritt wrote:
>  =20
>> For what it's worth, compiling with "gcc -pendantic" produces the warn=
ings below.
>> I don't know if this is a problem for any real set of c/c++ compilers =
used to
>> build gnuplot with wxt support.
>>
>> wxterminal/gp_cairo.c:198: warning: ISO C90 forbids mixed declarations=
 and code
>>  =20
>>    =20
> Thanks for the report. I fixed the warnings in CVS.
>
> By the way, I tried to do the same for wxt_gui.cpp, by compiling with=20
> CXX=3D'g++ -pedantic' but it fails because wxWidgets headers use the ty=
pe=20
> "long long". I don't know what to do to check my code without failing o=
n=20
> wxWidgets headers.
Ok, I figured out that the type "long long" has been introduced in the=20
standard C99, and compiling with CXX=3D'g++ -pedantic -Wno-long-long' is=20
enough to make wxt_gui.cpp compile, without  any warning.

Timoth=E9e

Re: Copy to clipboard for Linux

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

On Friday 14 July 2006 10:56 am, Bob Fletcher wrote:
>
> Shoot! Well, I tried all of the obvious things - except KDE and
> klipper. (I am having enough 'fun' trying to learn GNOME.) The
> cut/paste operation is very erratic and usually will not work. As
> suggested by others, I tried entering "e" for replot with no results.
> I guess I am having the same sort of flaky performance described by
> Dmitri.

Part of the confusion in an earlier post is the expectation that you
can "copy" once, and "paste" multiple times from it.  This is not
true for gnuplot+X11 by default.  An pixel image placed on the
clipboard can be pasted elsewhere, but then it's not on the clipboard
any more.

Taking a step to the side ...
As I understand it, what you want to do is import the plot into
an OpenOffice doc.  I would suggest to you that even if you get
the X11 cut/paste working, this is a poor solution to the task
at hand.  You would be better off binding a hotkey to a command
sequence like:

"set term push; set term png; set output /tmp/plot.png; \
 replot; set term pop"

Then you can easily import the png image.
The same could be done for "set term post eps".

The image quality from either png or eps should be way better
than the bitmapped X11 plot image.

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

Re: Compiler warnings from strict ISO C90 checking

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

Ethan Merritt wrote:
> For what it's worth, compiling with "gcc -pendantic" produces the warni=
ngs below.
> I don't know if this is a problem for any real set of c/c++ compilers u=
sed to
> build gnuplot with wxt support.
>
> wxterminal/gp_cairo.c:198: warning: ISO C90 forbids mixed declarations =
and code
>  =20
Thanks for the report. I fixed the warnings in CVS.

By the way, I tried to do the same for wxt_gui.cpp, by compiling with=20
CXX=3D'g++ -pedantic' but it fails because wxWidgets headers use the type=
=20
"long long". I don't know what to do to check my code without failing on=20
wxWidgets headers.

Best regards,

Timoth=E9e

Compiler warnings from strict ISO C90 checking

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

For what it's worth, compiling with "gcc -pendantic" produces the warnings below.
I don't know if this is a problem for any real set of c/c++ compilers used to
build gnuplot with wxt support.

wxterminal/gp_cairo.c:198: warning: ISO C90 forbids mixed declarations and code
wxterminal/gp_cairo.c:322: warning: ISO C90 forbids mixed declarations and code
wxterminal/gp_cairo.c:349: warning: ISO C90 forbids mixed declarations and code
wxterminal/gp_cairo.c:378: warning: ISO C90 forbids mixed declarations and code
wxterminal/gp_cairo.c:393: warning: ISO C90 forbids mixed declarations and code
wxterminal/gp_cairo.c:403: warning: ISO C90 forbids mixed declarations and code
wxterminal/gp_cairo.c:427: warning: ISO C90 forbids mixed declarations and code
wxterminal/gp_cairo.c:431: warning: ISO C90 forbids mixed declarations and code
wxterminal/gp_cairo.c:457: warning: initializer element is not computable at load time
wxterminal/gp_cairo.c:457: warning: initializer element is not computable at load time
wxterminal/gp_cairo.c:457: warning: ISO C90 forbids mixed declarations and code
wxterminal/gp_cairo.c:498: warning: ISO C90 forbids mixed declarations and code
wxterminal/gp_cairo.c:1460: warning: ISO C90 forbids mixed declarations and code
wxterminal/gp_cairo.c:1570: warning: ISO C90 forbids mixed declarations and code



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

Re: Copy to clipboard for Linux

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

On Fri, 2006-07-14 at 07:46 -0700, Ethan A Merritt wrote:

snip
> On KDE this component is called "klipper".  I don't know what the
> equivalent might be under Gnome, but if you are not running it already,
> then turning it on might possibly change the clipboard behavior you see.  
> 
> Furthermore, the export from gnuplot to the clipboard can be turned on/off
> by the X11 resource gnuplot_exprotselection.  To make sure you have this
> turned on (it should be on by default, but...) type
> 	echo "gnuplot*exportselection: on" | xrdb -merge
> before starting gnuplot.  If this makes a difference, then you should
> edit your Xdefaults file to make this change permanent

Shoot! Well, I tried all of the obvious things - except KDE and klipper.
(I am having enough 'fun' trying to learn GNOME.) The cut/paste
operation is very erratic and usually will not work. As suggested by
others, I tried entering "e" for replot with no results. I guess I am
having the same sort of flaky performance described by Dmitri.

I did notice one interesting thing. If the mouse is activated in gnuplot
and I double left click in the figure, the mouse position numbers are
pasted into the OO document with the center mouse button. In other
words, there is definitely some sort of clipboard/paste operations
between gnuplot and OO. It is just that the figure is not getting
pasted.

I am curious if anyone using Fedora Core 5 with GNOME has success with
this. 

Thanks,
Bob

Re: Bug in logarithmic minitics + suggested fix

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

Aapo Lankinen wrote:

> Yes, it is difficult to say what should be done, when the user wants,
> say 12 minitic intervals on a logarithmic plot with tic interval 100.

And don't forget that the log base may well be something else than 10...
'set log y 2; set ytics 1024; set mytics 10' anyone?

> Actually, the automatic system "set mytics default" appears to work in a
> rather sensible fashion, but unfortunately the user requested minitics
> are not honoured.  

That's not really the case. gnuplot does try to honour them --- 
otherwise the code snippets you dug up wouldn't even exist to be found, 
and it would not work for 'set ytics 10' either. The problem is that 
there's at least one bug in that (or nearby) code.

 > Also, I think that for the user requested minitics
> the arithmetic intervals would be better, because the user requested
> minitics probably aren't in "nice" places (otherwise "auto" and
> "default" would be used) and for awkward positions the arithmetic
> intervals are by far easier to read and understand.  

Tell that to the people who plot stock charts on log axes  --- they 
*insist* on getting exactly those graphically equidistant, yet 
numerically unreadable tics.

This part of the problem is that as soon as the axis scale isn't linear, 
the existing means for users to express their tic placement wishes 
become ambiguous.  This can only be resolved by adding a new feature to 
'set mxtics' & friends --- but now's really not the time to discuss, 
much less implement such a thing.  I suggest you write a Feature Request 
about this proposed extension, so it can be addressed once the dust has 
settled on the planned 4.2 release.

Re: Copy to clipboard for Linux

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

On 7/14/06, Petr Mikulik <mi...@ph...> wrote:

> It works just after the (re)plot. You may have selected sth else in between.
> Hit 'e' for replot and paste should be available again.
>

It is just flaky. Sometimes it works, sometimes it does not. I use
gnome and set "Sloppy focus
follows mouse" in case that matters. I also assumed that "g" does
replot already, in
any case hitting "g" "e" does not seems to make any difference.
Zooming with mouse sometimes put new figure into clipboard, sometimes it
does not.

> ---
> PM
>

Dmitri.
--

Re: Copy to clipboard for Linux

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

On Fri, 2006-07-14 at 07:46 -0700, Ethan A Merritt wrote:
> On Friday 14 July 2006 07:17 am, Petr Mikulik wrote:
> > > Experimenting on my Linux machine, I downloaded (via CVS) and built
> > > gnuplot Version 4.1 and successfully ran it. (You have some really nice
> > > demo plots by the way.) Here, however, I can find nothing equivalent to
> > > the "Copy to Clipboard" option offered in the Windows version. 
> 
> > > Maybe there is some fundamental issue here that I 
> > > don't understand.
> 
> X11 clipboards are messy. There are at least two of them, and they must
> be actively managed in order to work.  This management is usually 
> mediated by some component of your desktop / window manager.
> On KDE this component is called "klipper".  I don't know what the
> equivalent might be under Gnome, but if you are not running it already,
> then turning it on might possibly change the clipboard behavior you see.  
> 
> Furthermore, the export from gnuplot to the clipboard can be turned on/off
> by the X11 resource gnuplot_exprotselection.  To make sure you have this
> turned on (it should be on by default, but...) type
> 	echo "gnuplot*exportselection: on" | xrdb -merge
> before starting gnuplot.  If this makes a difference, then you should
> edit your Xdefaults file to make this change permanent
> 
> > > Perhaps I  am just missing it somewhere, but this should be useful for 
> > > pasting into Open Office documents.  
> > On Unixes, "middle mouse button" just works. Thus, do
> >  	plot x*x
> > and then in OpenOffice.org, click by middle mouse button and pasted plot 
> > is there! What a magic!
> 
> That's the "paste from clipboard" side of it.
> The "copy to clipboard" should happen automatically every time you
> draw a plot, or click in the active plot window.

Thanks to both of you for your responses. I was able to cut and paste a
plot to Open Office, so the functionality is indeed available.

Unfortunately, I have not been able to repeat the process. Apparently,
this is a clipboard/Linux related issue, since the Edit/Past Special
option is grayed out in OO. (It was available when I was first
successful.) So I will try some of the things you suggested, Ethan.

Thanks,

Bob

Re: Copy to clipboard for Linux

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

> But, wait. I forgot to add grid to the plot. Hit "Del" to delete the
> plot w/o grid
> from OO.org; moved mouse over to gnuplot windows; hit "g" -- grid is there 
> now!;
> go back to OO.org; click the middle mouse button -- Nothing happens!
> Magic is gone :(

It works just after the (re)plot. You may have selected sth else in between. 
Hit 'e' for replot and paste should be available again.

---
PM

Re: Copy to clipboard for Linux

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

On Friday 14 July 2006 07:17 am, Petr Mikulik wrote:
> > Experimenting on my Linux machine, I downloaded (via CVS) and built
> > gnuplot Version 4.1 and successfully ran it. (You have some really nice
> > demo plots by the way.) Here, however, I can find nothing equivalent to
> > the "Copy to Clipboard" option offered in the Windows version. 

> > Maybe there is some fundamental issue here that I 
> > don't understand.

X11 clipboards are messy. There are at least two of them, and they must
be actively managed in order to work.  This management is usually 
mediated by some component of your desktop / window manager.
On KDE this component is called "klipper".  I don't know what the
equivalent might be under Gnome, but if you are not running it already,
then turning it on might possibly change the clipboard behavior you see.  

Furthermore, the export from gnuplot to the clipboard can be turned on/off
by the X11 resource gnuplot_exprotselection.  To make sure you have this
turned on (it should be on by default, but...) type
	echo "gnuplot*exportselection: on" | xrdb -merge
before starting gnuplot.  If this makes a difference, then you should
edit your Xdefaults file to make this change permanent

> > Perhaps I  am just missing it somewhere, but this should be useful for 
> > pasting into Open Office documents.  
> On Unixes, "middle mouse button" just works. Thus, do
>  	plot x*x
> and then in OpenOffice.org, click by middle mouse button and pasted plot 
> is there! What a magic!

That's the "paste from clipboard" side of it.
The "copy to clipboard" should happen automatically every time you
draw a plot, or click in the active plot window.

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

Re: Copy to clipboard for Linux

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

On 7/14/06, Petr Mikulik <mi...@ph...> wrote:

> On Unixes, "middle mouse button" just works. Thus, do
>         plot x*x
> and then in OpenOffice.org, click by middle mouse button and pasted plot
> is there! What a magic!
>

Great! It works!

But, wait. I forgot to add grid to the plot. Hit "Del" to delete the
plot w/o grid
from OO.org; moved mouse over to gnuplot windows; hit "g" -- grid is there now!;
go back to OO.org; click the middle mouse button -- Nothing happens!
Magic is gone :(

> ---
> PM
>

Sincerely,

Dmitri.
--

Re: Copy to clipboard for Linux

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

> I am a gnuplot (and Linux) neophyte and am very curious about a
> difference in the functionality of *gnuplot Version 4.1 on Windows and
> on Linux (Fedora Core 5).
> Experimenting on my Linux machine, I downloaded (via CVS) and built
> gnuplot Version 4.1 and successfully ran it. (You have some really nice
> demo plots by the way.) Here, however, I can find nothing equivalent to
> the "Copy to Clipboard" option offered in the Windows version. Perhaps I
> am just missing it somewhere, but this should be useful for pasting into
> Open Office documents. Maybe there is some fundamental issue here that I
> don't understand.

On Unixes, "middle mouse button" just works. Thus, do
 	plot x*x
and then in OpenOffice.org, click by middle mouse button and pasted plot 
is there! What a magic!

---
PM

Copy to clipboard for Linux

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

Sirs:

I am a gnuplot (and Linux) neophyte and am very curious about a
difference in the functionality of *gnuplot Version 4.1 on Windows and
on Linux (Fedora Core 5).

On Windows, a right-click on the title bar gives me the option to "Copy
to Clipboard". I really like this feature and use it to paste figures
into MS Word documents - I think as emf's. (By the way, I have never
been successful with the "Print" option, but I haven't tried very hard
either.)

Experimenting on my Linux machine, I downloaded (via CVS) and built
gnuplot Version 4.1 and successfully ran it. (You have some really nice
demo plots by the way.) Here, however, I can find nothing equivalent to
the "Copy to Clipboard" option offered in the Windows version. Perhaps I
am just missing it somewhere, but this should be useful for pasting into
Open Office documents. Maybe there is some fundamental issue here that I
don't understand.

I realize that you are working to release Ver 4.2, and I don't want to
interfere with that. However, I did want to send this in before I forgot
about it.

Thanks for a nice product.

Bob

Re: Keep compilable with --disable-string-variables

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

On Thursday 13 July 2006 11:27 am, Juergen Wieferink wrote:
>
> Well, it could be done like the others:
>
>     fill_gpval_string("GPVAL_TERM", term->name);

Fine.

> I'd suggest something like:
>
> Index: eval.c
> ===================================================================
> --- eval.c	(Revision 279)
> +++ eval.c	(Arbeitskopie)
> @@ -733,8 +733,10 @@
>  	return;
>      if (v->udv_undef == FALSE && !strcmp((char*)&v->udv_value,
> value)) return;
> -    v->udv_undef = FALSE;
> -    gpfree_string(&v->udv_value);
> +    if (v->udv_undef)
> +        v->udv_undef = FALSE;
> +    else
> +        gpfree_string(&v->udv_value);
>      Gstring(&v->udv_value, gp_strdup(value));

Agreed.  Both now in cvs.

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