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

Alpha blending details?

[Philipp K. J. <ja...@ie...>]

What blending mode or operator does gnuplot
use for alpha blending?

According to this page, there are many possible
choices:
	http://cairographics.org/operators/

Based on some tests, possible options seem to be 
OPERATOR_OVER, OPERATOR_ADD, and OPERATOR_SATURATE.

Does anyone know?

Best,

		Ph.

Re: "Polygon not closed" warning - rounding error?

[Karl R. <ra...@un...>]

Am 28.11.2014 um 20:49 schrieb Philipp K. Janert:
> On Fri, 28 Nov 2014 20:41:06 +0100
> Karl Ratzsch <ra...@un...> wrote:
> 
>> Am 28.11.2014 um 19:38 schrieb Philipp K. Janert:
>>
>>> Am 28.11.2014 um 18:58 schrieb Philipp K. Janert:
>>
>>>> set object 1 polygon from -0.9,0.9 rto 0.8,0 rto 0,-0.8 rto -0.8,0
>>>> rto 0,0.8 set object 2 polygon from  0.1,0.9 rto 0.8,0 rto 0,-0.8
>>>> rto -0.8,0 rto 0,0.8
>>
>> Why not leave out the last step? The polygon closes itself by itself.
> 
> [snip]
> 
>>
>>> After all, using straight equality in floating
>>> point arithmetic is rarely the right thing to do.
>>
>> True. That´s why a polygon should get closed by returning to the
>> origin, not to a place that would be the origin if we had infinite
>> precision.
>>
>> So i´d say there´s nothing to be done about this, except that "set
>> object polygon" could get an additional "close it" option, that
>> suppresses the extra-vertex warning.
> 
> Well, I am questioning the purpose of the warning,
> in particular if it is implemented using straight
> floating-point equality. (I'd even argue that 
> a floating-point comparison using '==' amounts to
> a "bug".)
> 
> I think that there are in fact two options:
> - the close-it option you suggest (which would be a
>   new feature)
> - suppressing the warning if the length missing 
>   vertex is "small" compared to numerical accuracy
>   (which would be proper floating point programming)

No. Do what the example in the docs does, and don´t give five corners
for a four-corner object. Why would you want to?

If you really don´t know how many corners your object has beforehand,
you´ll have to do the math to find out, or indeed derive the precision
of the calculation. gp can´t do that for you, it doesn´t know how you
determined the coordinates.

  Karl

Re: "Polygon not closed" warning - rounding error?

[Philipp K. J. <ja...@ie...>]

On Fri, 28 Nov 2014 20:41:06 +0100
Karl Ratzsch <ra...@un...> wrote:

> Am 28.11.2014 um 19:38 schrieb Philipp K. Janert:
> 
> > Am 28.11.2014 um 18:58 schrieb Philipp K. Janert:
> 
> >> set object 1 polygon from -0.9,0.9 rto 0.8,0 rto 0,-0.8 rto -0.8,0
> >> rto 0,0.8 set object 2 polygon from  0.1,0.9 rto 0.8,0 rto 0,-0.8
> >> rto -0.8,0 rto 0,0.8
> 
> Why not leave out the last step? The polygon closes itself by itself.

[snip]

> 
> > After all, using straight equality in floating
> > point arithmetic is rarely the right thing to do.
> 
> True. That´s why a polygon should get closed by returning to the
> origin, not to a place that would be the origin if we had infinite
> precision.
> 
> So i´d say there´s nothing to be done about this, except that "set
> object polygon" could get an additional "close it" option, that
> suppresses the extra-vertex warning.

Well, I am questioning the purpose of the warning,
in particular if it is implemented using straight
floating-point equality. (I'd even argue that 
a floating-point comparison using '==' amounts to
a "bug".)

I think that there are in fact two options:
- the close-it option you suggest (which would be a
  new feature)
- suppressing the warning if the length missing 
  vertex is "small" compared to numerical accuracy
  (which would be proper floating point programming)

> 
>   Karl
> 
> 
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and
> Dashboards with Interactivity, Sharing, Native Excel Exports, App
> Integration & more Get technology previously reserved for
> billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
> _______________________________________________ gnuplot-beta mailing
> list gnu...@li...
> Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: Fw: "Polygon not closed" warning - rounding error?

[Karl R. <ra...@un...>]

Am 28.11.2014 um 19:38 schrieb Philipp K. Janert:

> Am 28.11.2014 um 18:58 schrieb Philipp K. Janert:

>> set object 1 polygon from -0.9,0.9 rto 0.8,0 rto 0,-0.8 rto -0.8,0
>> rto 0,0.8 set object 2 polygon from  0.1,0.9 rto 0.8,0 rto 0,-0.8 rto
>> -0.8,0 rto 0,0.8

Why not leave out the last step? The polygon closes itself by itself.

>> then gnuplot complains that the second polygon is not closed (and
>> that gnuplot is adding a vertex).
> ....
> PKJ: I disagree. If the warning is in fact due
> to round-off (which I don't know - it might be
> due to a bug in the code, for instance; I did

It´s rounding :

gnuplot> print 0.1 + 0.8 - 0.8 - 0.1
-2.77555756156289e-017

> After all, using straight equality in floating
> point arithmetic is rarely the right thing to do.

True. That´s why a polygon should get closed by returning to the origin,
not to a place that would be the origin if we had infinite precision.

So i´d say there´s nothing to be done about this, except that "set
object polygon" could get an additional "close it" option, that
suppresses the extra-vertex warning.

  Karl

Fw: "Polygon not closed" warning - rounding error?

[Philipp K. J. <ja...@ie...>]

Forwarding HBB's response to the list...

(and my response below)


Begin forwarded message:

Date: Fri, 28 Nov 2014 19:31:46 +0100
From: Hans-Bernhard Bröker <HBB...@t-...>
To: "Philipp K. Janert" <ja...@ie...>
Subject: Re: "Polygon not closed" warning - rounding error?


Am 28.11.2014 um 18:58 schrieb Philipp K. Janert:
> If I issue the following two commands (in a fresh 5.0rc3 session):

FWIW, 4.6pl6 Win32 does the same.

> set object 1 polygon from -0.9,0.9 rto 0.8,0 rto 0,-0.8 rto -0.8,0
> rto 0,0.8 set object 2 polygon from  0.1,0.9 rto 0.8,0 rto 0,-0.8 rto
> -0.8,0 rto 0,0.8

> then gnuplot complains that the second polygon is not closed (and
> that gnuplot is adding a vertex).

> Is this due to internal roundoff, so that the endpoint != startpoint
> in floating point arithmetic?

Somewhat obviously: yes.  This is a relatively clear example of

	In computing, 10 times 0.1 is hardly ever 1.0

> It did confuse me for a while (did I do something wrong?). Might it
> be possible to suppress such warnings?

Only at the cost of getting a non-closed polygon, which would be a good 
deal worse.


PKJ: I disagree. If the warning is in fact due
to round-off (which I don't know - it might be
due to a bug in the code, for instance; I did
not look at the implementation), then it would 
be possible to suppress such warnings if the 
length of the "missing vertex" is sufficiently
small (compared to the rest of the polygon?).

After all, using straight equality in floating
point arithmetic is rarely the right thing to do.

Re: Should "set ..." trigger a replot event?

[Philipp K. J. <ja...@ie...>]

On Fri, 28 Nov 2014 18:55:38 +0100
Karl Ratzsch <ra...@un...> wrote:

> Am 28.11.2014 um 18:31 schrieb Philipp K. Janert:
> > Should changing an option with "set ..." automatically
> > replot the graph?
> > 
> > Traditionally, changing an option with "set ..." does 
> > not have any immediate visible consequences - not until
> > the next plot, splot, or replot (or refresh) event do
> > the changes become visible.
> > 
> > This is a major point of confusion for new users, and
> > frequently an annoyance even for experienced users.
> > 
> > Hence, would it make sense to re-draw the graph 
> > automatically after "set"? Or (better!) have an
> > internal variable/option (eg "set autorefresh") 
> > that controls this behavior?
> > 
> > Obviously, for batch processing, autorefresh does
> > not make sense. Also, a previous plot must exist.
> > 
> > So, here is the list of conditions that I could foresee:
> > 
> > 1) IF the terminal is an interactive terminal
> > 2) and if a previous plot exist in the history
> > 3) and if autorefresh is not False
> > THEN automatically run refresh after each set.
> > 
> > Thoughts?
> 
> I could see an "autorefresh" mode would be nice to have in some cases,
> but if it was the default, I´m sure it´d annoy me on a daily basis.

That's why I think it's important to be able to
turn it on or off.

> 
> Btw., you can always end your "set .." command with ";rep" ;-)

Obviously. But whenever I "always" have to tell a 
computer to do a thing - shouldn't I be able to tell 
it ONCE? ;-)

> 
> (What the heck is the ambiguous "re" supposed to do? It´s neither
> "replot" or "refresh", nor "reset". Is it "reread"?)
> 
>   Karl
> 
> 
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and
> Dashboards with Interactivity, Sharing, Native Excel Exports, App
> Integration & more Get technology previously reserved for
> billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
> _______________________________________________ gnuplot-beta mailing
> list gnu...@li...
> Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

"Polygon not closed" warning - rounding error?

[Philipp K. J. <ja...@ie...>]

If I issue the following two commands (in a fresh
5.0rc3 session):

set object 1 polygon from -0.9,0.9 rto 0.8,0 rto 0,-0.8 rto -0.8,0 rto
0,0.8

set object 2 polygon from  0.1,0.9 rto 0.8,0 rto 0,-0.8 rto -0.8,0 rto
0,0.8

then gnuplot complains that the second polygon is
not closed (and that gnuplot is adding a vertex).

Which is funny, because the relative displacements
are exactly the same for both polygons, only the
origin is different. (They also look the same.)

What causes this warning? Is this due to internal
roundoff, so that the endpoint != startpoint in
floating point arithmetic?

It did confuse me for a while (did I do something
wrong?). Might it be possible to suppress such 
warnings?

Best,

		Ph.

Re: Should "set ..." trigger a replot event?

[Karl R. <ra...@un...>]

Am 28.11.2014 um 18:31 schrieb Philipp K. Janert:
> Should changing an option with "set ..." automatically
> replot the graph?
> 
> Traditionally, changing an option with "set ..." does 
> not have any immediate visible consequences - not until
> the next plot, splot, or replot (or refresh) event do
> the changes become visible.
> 
> This is a major point of confusion for new users, and
> frequently an annoyance even for experienced users.
> 
> Hence, would it make sense to re-draw the graph 
> automatically after "set"? Or (better!) have an
> internal variable/option (eg "set autorefresh") 
> that controls this behavior?
> 
> Obviously, for batch processing, autorefresh does
> not make sense. Also, a previous plot must exist.
> 
> So, here is the list of conditions that I could foresee:
> 
> 1) IF the terminal is an interactive terminal
> 2) and if a previous plot exist in the history
> 3) and if autorefresh is not False
> THEN automatically run refresh after each set.
> 
> Thoughts?

I could see an "autorefresh" mode would be nice to have in some cases,
but if it was the default, I´m sure it´d annoy me on a daily basis.

Btw., you can always end your "set .." command with ";rep" ;-)

(What the heck is the ambiguous "re" supposed to do? It´s neither
"replot" or "refresh", nor "reset". Is it "reread"?)

  Karl

Should "set ..." trigger a replot event?

[Philipp K. J. <ja...@ie...>]

Question/Suggestion for the group mind: 

Should changing an option with "set ..." automatically
replot the graph?

Traditionally, changing an option with "set ..." does 
not have any immediate visible consequences - not until
the next plot, splot, or replot (or refresh) event do
the changes become visible.

This is a major point of confusion for new users, and
frequently an annoyance even for experienced users.

Hence, would it make sense to re-draw the graph 
automatically after "set"? Or (better!) have an
internal variable/option (eg "set autorefresh") 
that controls this behavior?

Obviously, for batch processing, autorefresh does
not make sense. Also, a previous plot must exist.

So, here is the list of conditions that I could foresee:

1) IF the terminal is an interactive terminal
2) and if a previous plot exist in the history
3) and if autorefresh is not False
THEN automatically run refresh after each set.

Thoughts?

Best,

		Ph.

Re: export button/comparing output of cairo terminals

[Ethan A M. <sf...@us...>]

On Tuesday, 25 November, 2014 10:39:11 Karl Ratzsch wrote:
> Hi,
> 
> the dash patterns and pointsizes in the pdfcairo terminal are much
> denser, respectively larger than those in wxt or pngcairo. Also pdfcairo
> uses somewhat bigger font sizes (test script below). While there could
> be (are, imo) good reason to have different defaults for print (pdf) and
> on-screen (bitmap) display, this is a bit impractical with regard to the
> new pdf export button in the wxt terminal.

These terminals all use the same code internally, where "same" 
literally means that all of the cairo terminals including wxt share a 
single set of drawing routines.

The only differences from gnuplot's end are the canvas size, which
you are free to change, and in wxt the oversampling factor.
Any differences beyond this are due to the underlying pango/cairo libraries.

There is one additional parameter that you can tweak, fontscale, that
can partially correct for differences in canvas size.  I.e., if you want to
double the physical size of the output but keep the visual effect the same,
you would probably want to set both the fontscale and the linewidth to 2.0
at the same time you increased the x and y size by a factor of two.

	Ethan

> 
> (That set aside, if find the default sizes in pdfcairo somewhat mismatched?)
> 
> Should there perhaps be a "compatible" flag for terminals, that makes
> sizes, margins etc. match a common standard?
> 
> And it´d be great if wxt (like pngcairo) accepted sizes in cm/inches, so
> the paper size of an exported pdf can be easily controlled.
> 
>   Karl
> 
> 
> $test << EOD
> 1 1
> 2 3
> 3 2
> 4 4
> EOD
> 
> set xr [0:5];set yr [0:6]
> 
> set term wxt
> 
> plot $test w p ps 2, $test us 1:($2+1) w l lw 2 dt 2
> 
> set term pdfcairo
> set out "test.pdf"
> replot
> 
> set term pngcairo
> set out "test.png"
> replot
> set out
> 
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

export button/comparing output of cairo terminals

[Karl R. <ra...@un...>]

Hi,

the dash patterns and pointsizes in the pdfcairo terminal are much
denser, respectively larger than those in wxt or pngcairo. Also pdfcairo
uses somewhat bigger font sizes (test script below). While there could
be (are, imo) good reason to have different defaults for print (pdf) and
on-screen (bitmap) display, this is a bit impractical with regard to the
new pdf export button in the wxt terminal.

(That set aside, if find the default sizes in pdfcairo somewhat mismatched?)

Should there perhaps be a "compatible" flag for terminals, that makes
sizes, margins etc. match a common standard?

And it´d be great if wxt (like pngcairo) accepted sizes in cm/inches, so
the paper size of an exported pdf can be easily controlled.

  Karl


$test << EOD
1 1
2 3
3 2
4 4
EOD

set xr [0:5];set yr [0:6]

set term wxt

plot $test w p ps 2, $test us 1:($2+1) w l lw 2 dt 2

set term pdfcairo
set out "test.pdf"
replot

set term pngcairo
set out "test.png"
replot
set out

Re: paxis and parallel

[Jun T. <tak...@kb...>]

2014/11/23 20:4, Jun T. <tak...@kb...> wrote:

> With the latest CVS, make check core dumps at pm3d.dem on my Mac.

Sorry, I was just fixed in the CVS.

Re: paxis and parallel

[Jun T. <tak...@kb...>]

With the latest CVS, make check core dumps at pm3d.dem on my Mac.
This is due to the following change:

diff -u -r1.138 -r1.139
--- axis.c	11 Oct 2014 13:56:45 -0000	1.138
+++ axis.c	22 Nov 2014 00:25:17 -0000	1.139
@@ -249,7 +249,7 @@
{
    static char name[] = "p  ";
    if (axis >= PARALLEL_AXES) {
-	sprintf(name, "p%d", axis-PARALLEL_AXES+1);
+	sprintf(name, "paxis %d ", axis-PARALLEL_AXES+1);
	return name;
    }
    return (char *)axis_defaults[axis].name;


name[] is only 4 bytes long (including the trailing null),
and too short for the format "paxis %d ".

Jun

Re: paxis and parallel

[Ethan A M. <sf...@us...>]

On Thursday, 20 November, 2014 15:52:49 Petr Mikulik wrote:
> Hello,
> 
> I was trying to play with parallel axies by means of the "parallel.dem".
> 
> I wonder that:
> 
> - "show paxis" does not show anything ... why it does not show all p-axes?

Should it?   There is no "show xaxis" or "show axis" either.  

> - "show paxis 1" shows nothing

Also "show xaxis" shows nothing

> - "show paxis 1 blabla" shows nothing neither error
> - "help paxis" as well as "help set paxis" should refer to parallel, i.e.
>    there should be "See `help parallel`."
> - "show all" does not mention paxis

True.  More worrisome is that "save" does not save them.
save_range() can write them out, but it doesn't get called.
I'll fix this immediately.

> - I don't see an option to put the axis at a given horizontal position,
>    e.g. "set paxis <n> at <x>"

Good idea.

> BTW, in "show all", some items printed are not intended. I think this is
> not intended.
> 
> ---
> Petr

	Ethan

paxis and parallel

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

Hello,

I was trying to play with parallel axies by means of the "parallel.dem".

I wonder that:

- "show paxis" does not show anything ... why it does not show all p-axes?
- "show paxis 1" shows nothing
- "show paxis 1 blabla" shows nothing neither error
- "help paxis" as well as "help set paxis" should refer to parallel, i.e.
   there should be "See `help parallel`."
- "show all" does not mention paxis
- I don't see an option to put the axis at a given horizontal position,
   e.g. "set paxis <n> at <x>"

BTW, in "show all", some items printed are not intended. I think this is
not intended.

---
Petr

Re: testing -rc3 on windows

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

Am 17.11.2014 um 11:29 schrieb Karl Ratzsch:
> Hi all,
>
> is there a chance to get a windows binary for the latest 5.0-rc3 and/or
> a description of the build process, including wxt terminal? Compiling
> with mingw32 is relatively straightforward (see also
> http://sourceforge.net/p/gnuplot/support-requests/163/ ), except wxt/qt,
> where i´ve got no real clue how to even get started.

The instructions have been updated to include the qt terminal. wxWidgets 
compiles fine here, but maybe I had to tweak some header files a bit. I 
honestly don't remember but I'll check.
Any further comments to improve this HOWTO are welcome.
Also it might be a good idea to add a link to this tracker to the web site.

Also there are now binary packages of RC3 for Windows 32bit on SF.

>
> Btw., the latest 5.1 windows installers from Tatsuro (many thanks for
> providing those, btw!) still failed to set the correct path for
> additional users, see http://sourceforge.net/p/gnuplot/bugs/1415/

This is a known problem indeed. But I don't know how to solve this. 
Patches welcome.

   Bastian

>
>
>     Karl
>

Re: double-click on qt terminal

[Jun T. <tak...@kb...>]

On 2014/11/20, at 4:52, Ethan A Merritt <sf...@us...> wrote:
> and now I see that it is supposed to copy the current
> mouse coordinates to the clipboard.  (In what format?)

It uses mouseformat (it was using clipboardformat, but has changed
around half a year back; please see the thread
'Mouse position-to-clipboard UI' in this mailing list).

> Maybe we should just remove this claim from the documentaion?

Please try

gnuplot>set mouse doubleclick 2000

and click twice on a qt terminal. The interval between the two
clicks should be longer than 300ms and shorter than 2000ms = 2s.
Sometimes garbage is copied to the clipboard, but in many cases
you would get a crash with 
############### WRONG readEvent

So I feel fixing it would be much better (please try my patches)
rather than just removing from the documentation.
Or remove whole the implementation of double-click from the
source code if no one is using this feature.

Re: double-click on qt terminal

[Ethan A M. <sf...@us...>]

On Thursday, 20 November, 2014 01:20:56 Jun T. wrote:
> On my Mac, double-clicking on a qt terminal doesn't work.
> Does it work on other OSes? If not, then please try the patches
> attached below (which are tested only on Mac).

I honestly did not know until just now that double-click was supposed
to do anything at all.  Your Email caused me to search through the
documentation, and now I see that it is supposed to copy the current
mouse coordinates to the clipboard.  (In what format?)

No, it doesn't work for me under linux either.
Since version 4.something the mouse coordinates are returned in variables
MOUSE_X and MOUSE_Y, which is probably more useful that retrieving them
from the clipboard.    

Maybe we should just remove this claim from the documentaion?

	Ethan

> 
> In QtGnuplotScene::mouseReleaseEvent() (QtGnuplotScene.cpp, around
> line 843), GE_buttonrelease event is generated only if more than
> 300ms has elapsed since the last button release.
> But in event_buttonrelease() (mouse.c, line 1955 and blelow),
> term->set_clipboard() is called only if the elapsed time is less
> than (or equal to) mouse_setting.doubleclick, whose default value
> seems to be 300ms. Thus set_clipboard() will never be called...?
> 
> If I increase mouse_setting.doubleclick by, for example,
> gnuplot>set mouse doubleclick 1000
> then double-click sometimes copies garbage to the clipboard,
> and otherwise causes a crash, saying 'WRONG readEvent'.
> 
> I guess this is due to an inconsistency between qt_set_clipboard()
> (qt_term.cpp, line 912) and QtGnuplotWidget::processEvent()
> (QtGnuplotWidget.cpp, line 194 and below); the former sends
> 'char s[]' (a simple C-string) to the stream qt->out,
> while the latter reads it as a QString. But these two data types
> are serialized in different ways in the stream (QString is
> encoded in UTF-16).
> 
> If I replace line 916 of qt_term.cpp
>     qt->out << GECopyClipboard << s;
> by
>     qt->out << GECopyClipboard << QString(s);
> then correct data (mouse position) is copied to the clipboard,
> and I don't get 'WRONG readEvent' anymore
> (assuming mouse_stting.doubleclick is increased as above).
> 
> Moreover, it seems in QtGnuplotScene::mouseReleaseEvent() we need
> not filter out any mouse release event; see a patch in
> QtGnuplotScence.cpp-2.diff. With this patch, double-click 
> works without any 'set mouse doubleclick ....'.
> 

Re: Mouse position-to-clipboard UI

[Jun T. <tak...@kb...>]

2014/04/29 05:17, Dima Kogan <gn...@di...> wrote:

> OK. Here's a patch the removes that logic.

In mouse.c, lines 2520-2521, an old description for 2x<B2> still remains:

fprintf(stderr, fmt, "2x<B1>",
"print coordinates to clipboard using `clipboardformat`\n
                    (see keys '3', '4')");

double-click on qt terminal

[Jun T. <tak...@kb...>]

On my Mac, double-clicking on a qt terminal doesn't work.
Does it work on other OSes? If not, then please try the patches
attached below (which are tested only on Mac).

In QtGnuplotScene::mouseReleaseEvent() (QtGnuplotScene.cpp, around
line 843), GE_buttonrelease event is generated only if more than
300ms has elapsed since the last button release.
But in event_buttonrelease() (mouse.c, line 1955 and blelow),
term->set_clipboard() is called only if the elapsed time is less
than (or equal to) mouse_setting.doubleclick, whose default value
seems to be 300ms. Thus set_clipboard() will never be called...?

If I increase mouse_setting.doubleclick by, for example,
gnuplot>set mouse doubleclick 1000
then double-click sometimes copies garbage to the clipboard,
and otherwise causes a crash, saying 'WRONG readEvent'.

I guess this is due to an inconsistency between qt_set_clipboard()
(qt_term.cpp, line 912) and QtGnuplotWidget::processEvent()
(QtGnuplotWidget.cpp, line 194 and below); the former sends
'char s[]' (a simple C-string) to the stream qt->out,
while the latter reads it as a QString. But these two data types
are serialized in different ways in the stream (QString is
encoded in UTF-16).

If I replace line 916 of qt_term.cpp
    qt->out << GECopyClipboard << s;
by
    qt->out << GECopyClipboard << QString(s);
then correct data (mouse position) is copied to the clipboard,
and I don't get 'WRONG readEvent' anymore
(assuming mouse_stting.doubleclick is increased as above).

Moreover, it seems in QtGnuplotScene::mouseReleaseEvent() we need
not filter out any mouse release event; see a patch in
QtGnuplotScence.cpp-2.diff. With this patch, double-click 
works without any 'set mouse doubleclick ....'.

Re: Arrow keys not working on qt terminal for Mac OS X

[Jun T. <tak...@kb...>]

On 2014/11/19, at 1:33, sfeam <sf...@us...> wrote:

> Are you sure this is not a property of your keyboard rather
> than a property of your operating system?

Yes. Please look into the following Qt document:
http://qt-project.org/doc/qt-4.8/qt.html#KeyboardModifier-enum
especially, the Note section says
"The KeypadModifier value will also be set when an arrow key is
pressed as the arrow keys are considered part of the keypad."

See also the "Listing 5-4" in the following Apple document:
https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/EventOverview/HandlingKeyEvents/HandlingKeyEvents.html

> What about keyboards that have both keypad arrows and separate
> arrow keys?

I tried four keyboards, two of them have numeric keypad but
the separate arrow keys are treated as part of the keypad.

> The QtGnuplotScene.cpp.diff patch appears to be backwards
> from what you describe above.  If it detects __APPLE__ it
> removes the keypad modifier, rather than adding it.

Yes, it is the intended behavior.
When the left arrow key is pressed, the condition
    if (event->modifiers() & Qt::KeypadModifier)
is TRUE, and, before the patch, GP_KP_Left is generated.
But no action is bound to GP_KP_Left by default.
After the patch, GP_Left is generated, which is bound to
builtin_rotate_left by default (in mouse.c).

Or we can bind builtin_rotate_left to GP_KP_Left in
mouse.c (without patching QtGnuplotScene.cpp).

Re: Arrow keys not working on qt terminal for Mac OS X

[sfeam <sf...@us...>]

On Tuesday, 18 November 2014 04:48:42 PM Jun T. wrote:
> On Mac OS X, the arrow keys (Left, Right, Up, Down) do not work
> on qt terminal.

Are you sure this is not a property of your keyboard rather
than a property of your operating system?
What about keyboards that have both keypad arrows and separate
arrow keys?

> 
> The reason is simple; Apple considers the arrow keys as part of keypad.
> The Qt::KeypadModifier bit of event->modifiers() is set when I hit
> the arrow keys.
> 
> Two possible patches are attached.
> Only one of them (not both) should be applied.
> 
> If mouse.c is patched, then a user should use
> bind KP_Left ...
> to customize the binding of the Left-arrow key.
> If, on the other hand, QtGnuplotScene.cpp is patched, then
> bind Left ...
> can be used. Maybe this is more intuitive for typical Mac users?

The QtGnuplotScene.cpp.diff patch appears to be backwards
from what you describe above.  If it detects __APPLE__ it
removes the keypad modifier, rather than adding it.

Could you please check and confirm which is correct,
the patch or the description you gave above?
	
	thanks,

		Ethan

Re: Arrow keys not working on qt terminal for Mac OS X

[Jun T. <tak...@kb...>]

Sorry, throw away mouse.c.diff in the previous post; it breaks
other terminals (wxt etc.).

If we are going to patch mouse.c, then please use the patch
attached to this post. But I feel patching QtGnuplotScene.cpp
is better.

Arrow keys not working on qt terminal for Mac OS X

[Jun T. <tak...@kb...>]

On Mac OS X, the arrow keys (Left, Right, Up, Down) do not work
on qt terminal.

The reason is simple; Apple considers the arrow keys as part of keypad.
The Qt::KeypadModifier bit of event->modifiers() is set when I hit
the arrow keys.

Two possible patches are attached.
Only one of them (not both) should be applied.

If mouse.c is patched, then a user should use
bind KP_Left ...
to customize the binding of the Left-arrow key.
If, on the other hand, QtGnuplotScene.cpp is patched, then
bind Left ...
can be used. Maybe this is more intuitive for typical Mac users?

testing -rc3 on windows

[Karl R. <ra...@un...>]

Hi all,

is there a chance to get a windows binary for the latest 5.0-rc3 and/or
a description of the build process, including wxt terminal? Compiling
with mingw32 is relatively straightforward (see also
http://sourceforge.net/p/gnuplot/support-requests/163/ ), except wxt/qt,
where i´ve got no real clue how to even get started.

Btw., the latest 5.1 windows installers from Tatsuro (many thanks for
providing those, btw!) still failed to set the correct path for
additional users, see http://sourceforge.net/p/gnuplot/bugs/1415/


   Karl