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

Automatically keeping "last modified" up to date

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

I just built the most recent version of gnuplot and noticed that the 
"last modified" date in the intro refers back to 2012 and is manually 
entered.  Why can't that automatically be generated?  It would be nice 
to do this so that when one builds/installs the latest version, upon 
launching the program it is immediate clear that the install process was 
successful by looking at the "last modified" date.

Here are some approaches that could be tried:

1) There is this configure.in file containing:

dnl $Id: configure.in,v 1.332 2013/07/18 23:22:17 sfeam Exp $

Is that file somehow generated by the CVS/repository to reflect the most 
recent modification of the repository?  If so, that would be great as it 
would also contain a time stamp.  Could write a script to search for 
that and define LAST_MODIFIED in some header file using the extracted 
"2013/07/18 23:22:17" string.

2) Is there some way during make to get the most recent date of all the 
pertinent files?  "make" does date checking, so perhaps there is a make 
variable/macro that reflects that.

3) Similar to #2, we could maybe write an OS script that does the same 
thing by looking for the date of the most recent file in the source tree.

4) Ethan keeps the ChangeLog up to date.  It would be easy to search for 
the most recent date near the top of the file and use that as a 
definition for LAST_MODIFIED.

Dan

confusing option name for wxWidgets configuration

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

Hello,

Background: I've been working on a side-by-side installation of
wxWidgets 2.8 and 2.9. The main problem on Mac is that wxWidgets 2.8
cannot be compiled on operating systems newer than 10.6 (released 4
years ago) and a lot of programs still don't support version 2.9. In
such a scenario wx-config cannot be in path for both 2.8 and 2.9, so
we need a way to specify which one to use.

When playing with configuration, the first thing I tried to do was
    ./configure --with-wx-config=/opt/local/lib/wx/config/osx_cocoa-unicode-2.9
until I realized that gnuplot ignored this completely. Later I
realized that --with-wx-config expects a *PATH* where an exacutable
wx-config needs to be (no other name allowed), not the link to
wx-config file itself. So I created
/opt/local/libexec/wxwidgets/2.9/wx-config with a symlink to the file
mentioned above and now
    ./configure --with-wx-config=/opt/local/libexec/wxwidgets/2.9
works fine.

While the implementation in gnuplot is already a lot better than what
the majority of software does, it's a minor inconvenience that the
option name/meaning is different from the one officially provided by
wxWidgets in the file aclocal/wxwin.m4 (see
https://github.com/wxWidgets/wxWidgets/blob/master/wxwin.m4) and that
one cannot use an executable with a different name. The "official"
options are:

AC_DEFUN([WX_CONFIG_OPTIONS],
[
    AC_ARG_WITH(wxdir,
                [  --with-wxdir=PATH       Use uninstalled version of
wxWidgets in PATH],
                [ wx_config_name="$withval/wx-config"
                  wx_config_args="--inplace"])
    AC_ARG_WITH(wx-config,
                [  --with-wx-config=CONFIG wx-config script to use (optional)],
                wx_config_name="$withval" )
    AC_ARG_WITH(wx-prefix,
                [  --with-wx-prefix=PREFIX Prefix where wxWidgets is
installed (optional)],
                wx_config_prefix="$withval", wx_config_prefix="")
    AC_ARG_WITH(wx-exec-prefix,
                [  --with-wx-exec-prefix=PREFIX
                          Exec prefix where wxWidgets is installed (optional)],
                wx_config_exec_prefix="$withval", wx_config_exec_prefix="")
])

So instead of
    ./configure --with-wx-config=/opt/local/libexec/wxwidgets/2.9
I would expect either of the following options to work:
    ./configure --with-wx-config=/opt/local/libexec/wxwidgets/2.9/wx-config
    ./configure --with-wx-config=/opt/local/lib/wx/config/osx_cocoa-unicode-2.9
    ./configure --with-wxdir=/opt/local/libexec/wxwidgets/2.9

I didn't try to research the history of this option in gnuplot. I only
know that MacPorts tried to use
--with-wx-config=/opt/local/bin/wx-config until now, but nobody
realized that it didn't work. (It picked the right wx-config, but only
because it was the first one in PATH, not because --with-wx-config
would work the way the package maintainer imagined/expected it to
work.)

My question is the following: would it be acceptable for gnuplot to either:
a) [probably best option] include the official wxwin.m4 from upstream
in its sources and call the few macros as documented in the link above
(I can help with implementation and testing)
b) change the option name and make sure that
--with-wx-config/--with-wxdir would behave approximately the same as
in upstream (as opposed to --with-wx-config behaving as upstream's
--with-wxdir)

Thank you,
    Mojca

PS: I'm not requesting this for the 4.6 branch, but the trunk already
changed the option name(s) for Qt, so I don't find it so problematic
to also change the option name(s) for wxWidgets for the naxt major
release.

Re: Using linestyle for object border

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

On Friday, July 26, 2013 03:42:14 am Christoph Bersch wrote:
> Am 25.07.2013 22:09, schrieb Ethan A Merritt:
> > On Thursday, July 25, 2013 12:35:09 pm Christoph Bersch wrote:
> >>
> >> I think, dashed object borders are not possible.
> >
> > See attached demo and output.
> 
> Ok, I see. But it does not work for 'set object', which is what I use 
> frequently. 

Thanks for the example.
I think there are 2 or 3 factors contributing to the problem.
A satisfactory fix may require changing more than one thing.
Let me summarize how things currently work:

1) When you create a new "set object ..." the linetype for drawing that
   object is set to LT_DEFAULT and the fill style is set to FS_DEFAULT.
   A previously created object can be returned to this state by saying
   "set object N default"

2) If you set an explicit fill color either at the time of creation or
   later, this has the side effect of resetting LT_DEFAULT to (-1).
   There was a reason for doing this back when only a few terminals
   supported RGB color, but I think it is no longer necessary. 
   Changing this may be part of the solution to your problem.

3) Later on when the object is actually drawn, if the object line type
   is still LT_DEFAULT this is replaced by the linetype of the current
   plot.  If the object is not part of a plot, then instead it is 
   replaced by the linetype of the fill style border.

Steps (1) and (2) are implemented in the routine set_obj().
Step (3) happens in various places during plotting;  they may not all
act identically so this is an area possible bugs or inconsistency.

I agree that the current behavior is not entirely satisfactory.
If you want to experiment with changing it, I suggest trying some
combination of

- Removing or changing step (2) above.  It is line 4052 in set.c
  this_object->lp_properties.l_type = LT_BLACK; /* Anything but LT_DEFAULT */

- Adding an explicit option  "set object ... {linetype N}"
  or even "set object ... {dashtype N}"
  This would effectively become a step (1A) in set_obj()

- Rethinking when or if the "border" property of a fill style is applied.
  For example, should it apply to fillstyle "empty"?
  This is currently treated as a special case in several places.  

- [your original proposal] re-interpreting the "border" property as a
  line type or line style rather than as a color.  One problem with this
  is that there would then be _two_ line types attached to each object,
  one in the top level structure object->lp_properties and a second in
  object->fillstyle->border_lt    (doesn't currently exist).
  Which one is used under what conditions?

I suspect any changes will have unforseen side effects, but that's life :-)

		Ethan

Re: Using linestyle for object border

[Christoph B. <us...@be...>]

Am 25.07.2013 22:09, schrieb Ethan A Merritt:
> On Thursday, July 25, 2013 12:35:09 pm Christoph Bersch wrote:
>>
>> I think, dashed object borders are not possible.
>
> See attached demo and output.

Ok, I see. But it does not work for 'set object', which is what I use 
frequently. And I cannot plot "with circles" to circumvent this, because 
the points lie on the plot border, and the circles are clipped. See the 
attached example and the result which shows my usecase. This is also 
where my last patches come into play.

http://sourceforge.net/p/gnuplot/patches/631/
http://sourceforge.net/p/gnuplot/patches/628/ (I'm improving this at the 
moment)

Christoph

Re: Using linestyle for object border

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

On Thursday, July 25, 2013 12:35:09 pm Christoph Bersch wrote:
> Hi,
> 
> Am 25.07.2013 18:44, schrieb sfeam (Ethan Merritt):
> > On Thursday, 25 July 2013, Christoph Bersch wrote:
> >>
> >> I was wondering, why using linestyles is not allowed for object borders.
> >
> > On the other hand, so far as I can think of there is a perfectly
> > adequate work-around already available - you can plot the
> > object or graph twice, once describing the fill and a second
> > time describing the outline.   Have I missed a case where this
> > is not possible?
> 
> I don't know, what you mean. In any case specifying a line style is not 
> possible for an object, right?
> 
> I think, dashed object borders are not possible.

See attached demo and output.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
set term pdfcairo dash dashlength 2
set output 'dash+fill.pdf'
set key box opaque

set title "Plain circles with dash linetype"
plot 'candlesticks.dat' using 1:2:(1) with circles lt 2

set title "Filled circles"
plot 'candlesticks.dat' using 1:2:(1) with circles fs solid fc rgb "yellow"

set title "Both at once"
plot 'candlesticks.dat' using 1:2:(1) with circles fs solid fc rgb "yellow", \
     '' using 1:2:(1) with circles lt 2
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%




	Ethan



> 
> It is not, that I urgently need dashed circles, but although I work a 
> lot with gnuplot, I continue struggling with the different handling of 
> some options. And this is one of them :-)
> 
> Christoph

Re: Using linestyle for object border

[Christoph B. <us...@be...>]

Hi,

Am 25.07.2013 18:44, schrieb sfeam (Ethan Merritt):
> On Thursday, 25 July 2013, Christoph Bersch wrote:
>>
>> I was wondering, why using linestyles is not allowed for object borders.
>
> On the other hand, so far as I can think of there is a perfectly
> adequate work-around already available - you can plot the
> object or graph twice, once describing the fill and a second
> time describing the outline.   Have I missed a case where this
> is not possible?

I don't know, what you mean. In any case specifying a line style is not 
possible for an object, right?

I think, dashed object borders are not possible.

It is not, that I urgently need dashed circles, but although I work a 
lot with gnuplot, I continue struggling with the different handling of 
some options. And this is one of them :-)

Christoph

Re: Using linestyle for object border

[sfeam (E. Merritt) <eam...@gm...>]

On Thursday, 25 July 2013, Christoph Bersch wrote:
> Hi,
> 
> I was wondering, why using linestyles is not allowed for object borders. 
> The following is not allowed:
> 
> set object circle at 0,0 radius 1 fs empty border ls 1

Insufficient imagination at the time fillstyles were implemented :-)

The relevant structure is in term_api.h
typedef struct fill_style_type {
    int fillstyle;
    int filldensity;
    int fillpattern;
    t_colorspec border_color;
} fill_style_type;

You can see the only information held for the border is a color,
not a full line type or style.

If we're ever going to change that, right now during the long
run-up to version 5 is a good time.   A quick "grep border_color *.c" 
suggests there are at least 35 sites in the code that would be affected.

On the other hand, so far as I can think of there is a perfectly
adequate work-around already available - you can plot the 
object or graph twice, once describing the fill and a second
time describing the outline.   Have I missed a case where this
is not possible?

	Ethan

> I wanted to ask before I try to come up with a patch ;-)
> 
> Christoph
> 
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Using linestyle for object border

[Christoph B. <us...@be...>]

Hi,

I was wondering, why using linestyles is not allowed for object borders. 
The following is not allowed:

set object circle at 0,0 radius 1 fs empty border ls 1

I wanted to ask before I try to come up with a patch ;-)

Christoph

Re: gnuplot on 64-bit Windows

[Allin C. <cot...@wf...>]

On Wed, 24 Jul 2013, sfeam (Ethan Merritt) wrote:

> On Wednesday, 24 July 2013, Allin Cottrell wrote:
>> On Wed, 24 Jul 2013, sfeam (Ethan Merritt) wrote:
>>
>>> On Wednesday, 24 July 2013, Allin Cottrell wrote:
>>>> I have need of a 64-bit Windows build of gnuplot and I've been
>>>> working on cross-compiling from Linux using mingw64. I see
>>>> several places in current CVS where the code generates errors
>>>> and warnings. I'm attaching a patch-set which quells the
>>>> errors and warnings, but unfortunately I'm not able to test on
>>>> win64 at present.
>>>
>>> I can't help with evaluation of the full patch, but one set of
>>> changes strikes me as being wrong on the face of it:
>>>
>>> %%%%%%%%%%%%%%
>>> +#ifdef _WIN64
>>> +INT_PTR CALLBACK PrintDlgProc(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam);
>>> +#else
>>> BOOL CALLBACK PrintDlgProc(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam);
>>> +#endif
>>> %%%%%%%%%%%%%%
>>>
>>> There's no way it can be correct to label a Boolean value  as a pointer.
>>>
>>> The equivalent substitution occurs several places in your patch.
>>> I didn't check each one, but the routine PrintDlgProc really does return
>>> TRUE or FALSE, so I think at least in this case, if not all of them,
>>> the original code was correct.
>>
>> It's strange, I agree, but the original code throws a warning.
>> The caller, in all cases, is CreateDialogParam() and the
>> callback is the fourth argument, of type DLGPROC, in relation
>> to which the msdn doc points us to "DialogProc callback
>> function"
>>
>> http://msdn.microsoft.com/en-us/library/windows/desktop/ms645469%28v=vs.85%29.aspx
>>
>> where we find:
>>
>> <quote>
>> Return value
>>
>> Type: INT_PTR
>>
>> Typically, the dialog box procedure should return TRUE if it
>> processed the message, and FALSE if it did not. If the dialog
>> box procedure returns FALSE, the dialog manager performs the
>> default dialog operation in response to the message.
>> </quote>
>
> [shudder]

Yes, indeed.

> Nevertheless, wouldn't your change just shift the site of the
> error/warning message?  Now the prototype says it returns
> INT_PTR but the function itself still says it returns BOOL.
> So there is still a mismatch in types.

My patches also change the return type of the relevant 
callback functions to INT_PTR for win64. However, given how 
broken the MS design is, I'd be happy to leave things as they 
were (in respect of CreateDialogParam) and put up with the 
warnings from gcc. If it might be useful I can submit an 
alternative version of the patch-set.

Allin Cottrell

Re: gnuplot on 64-bit Windows

[sfeam (E. Merritt) <eam...@gm...>]

On Wednesday, 24 July 2013, Allin Cottrell wrote:
> On Wed, 24 Jul 2013, sfeam (Ethan Merritt) wrote:
> 
> > On Wednesday, 24 July 2013, Allin Cottrell wrote:
> >> I have need of a 64-bit Windows build of gnuplot and I've been
> >> working on cross-compiling from Linux using mingw64. I see
> >> several places in current CVS where the code generates errors
> >> and warnings. I'm attaching a patch-set which quells the
> >> errors and warnings, but unfortunately I'm not able to test on
> >> win64 at present.
> >
> > I can't help with evaluation of the full patch, but one set of
> > changes strikes me as being wrong on the face of it:
> >
> > %%%%%%%%%%%%%%
> > +#ifdef _WIN64
> > +INT_PTR CALLBACK PrintDlgProc(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam);
> > +#else
> > BOOL CALLBACK PrintDlgProc(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam);
> > +#endif
> > %%%%%%%%%%%%%%
> >
> > There's no way it can be correct to label a Boolean value  as a pointer.
> >
> > The equivalent substitution occurs several places in your patch.
> > I didn't check each one, but the routine PrintDlgProc really does return
> > TRUE or FALSE, so I think at least in this case, if not all of them,
> > the original code was correct.
> 
> It's strange, I agree, but the original code throws a warning. 
> The caller, in all cases, is CreateDialogParam() and the 
> callback is the fourth argument, of type DLGPROC, in relation 
> to which the msdn doc points us to "DialogProc callback 
> function"
> 
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms645469%28v=vs.85%29.aspx
> 
> where we find:
> 
> <quote>
> Return value
> 
> Type: INT_PTR
> 
> Typically, the dialog box procedure should return TRUE if it 
> processed the message, and FALSE if it did not. If the dialog 
> box procedure returns FALSE, the dialog manager performs the 
> default dialog operation in response to the message.
> </quote>

[shudder]
Nevertheless, wouldn't your change just shift the site of the
error/warning message?  Now the prototype says it returns
INT_PTR but the function itself still says it returns BOOL.
So there is still a mismatch in types.

I found a hideous example on that Microsoft site you linked to:
http://msdn.microsoft.com/en-us/library/windows/desktop/ff728900(v=vs.85).aspx

It declares a callback function
   INT_PTR CALLBACK OpenUrlDialogProc(HWND hDlg, UINT message, 
                                                                     WPARAM wParam, LPARAM lParam)
which exits with
   return (INT_PTR)FALSE;

I guess it's a matter of "choose your poison".

	Ethan



> It's probably OK to leave the code as is and ignore the 
> warning, but here it is:
> 
> ../src/win/wgraph.c: In function 'LineStyle':
> ../src/win/wgraph.c:3607:2: warning: passing argument 4 of 
> 'DialogBoxParamA' from incompatible pointer type [enabled by 
> default]
> /opt/win64/lib/gcc/x86_64-w64-mingw32/4.6.4/../../../../x86_64-w64-mingw32/include/winuser.h:2104:29: 
> note: expected 'DLGPROC' but argument is of type 'BOOL 
> (*)(struct HWND__ *, UINT,  WPARAM,  LPARAM)'
> 
> Allin Cottrell
> 

Re: gnuplot on 64-bit Windows

[Allin C. <cot...@wf...>]

On Wed, 24 Jul 2013, sfeam (Ethan Merritt) wrote:

> On Wednesday, 24 July 2013, Allin Cottrell wrote:
>> I have need of a 64-bit Windows build of gnuplot and I've been
>> working on cross-compiling from Linux using mingw64. I see
>> several places in current CVS where the code generates errors
>> and warnings. I'm attaching a patch-set which quells the
>> errors and warnings, but unfortunately I'm not able to test on
>> win64 at present.
>
> I can't help with evaluation of the full patch, but one set of
> changes strikes me as being wrong on the face of it:
>
> %%%%%%%%%%%%%%
> +#ifdef _WIN64
> +INT_PTR CALLBACK PrintDlgProc(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam);
> +#else
> BOOL CALLBACK PrintDlgProc(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam);
> +#endif
> %%%%%%%%%%%%%%
>
> There's no way it can be correct to label a Boolean value  as a pointer.
>
> The equivalent substitution occurs several places in your patch.
> I didn't check each one, but the routine PrintDlgProc really does return
> TRUE or FALSE, so I think at least in this case, if not all of them,
> the original code was correct.

It's strange, I agree, but the original code throws a warning. 
The caller, in all cases, is CreateDialogParam() and the 
callback is the fourth argument, of type DLGPROC, in relation 
to which the msdn doc points us to "DialogProc callback 
function"

http://msdn.microsoft.com/en-us/library/windows/desktop/ms645469%28v=vs.85%29.aspx

where we find:

<quote>
Return value

Type: INT_PTR

Typically, the dialog box procedure should return TRUE if it 
processed the message, and FALSE if it did not. If the dialog 
box procedure returns FALSE, the dialog manager performs the 
default dialog operation in response to the message.
</quote>

It's probably OK to leave the code as is and ignore the 
warning, but here it is:

../src/win/wgraph.c: In function 'LineStyle':
../src/win/wgraph.c:3607:2: warning: passing argument 4 of 
'DialogBoxParamA' from incompatible pointer type [enabled by 
default]
/opt/win64/lib/gcc/x86_64-w64-mingw32/4.6.4/../../../../x86_64-w64-mingw32/include/winuser.h:2104:29: 
note: expected 'DLGPROC' but argument is of type 'BOOL 
(*)(struct HWND__ *, UINT,  WPARAM,  LPARAM)'

Allin Cottrell

Re: gnuplot on 64-bit Windows

[sfeam (E. Merritt) <eam...@gm...>]

On Wednesday, 24 July 2013, Allin Cottrell wrote:
> I have need of a 64-bit Windows build of gnuplot and I've been 
> working on cross-compiling from Linux using mingw64. I see 
> several places in current CVS where the code generates errors 
> and warnings. I'm attaching a patch-set which quells the 
> errors and warnings, but unfortunately I'm not able to test on 
> win64 at present.

I can't help with evaluation of the full patch, but one set of 
changes strikes me as being wrong on the face of it:

%%%%%%%%%%%%%%
+#ifdef _WIN64
+INT_PTR CALLBACK PrintDlgProc(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam);
+#else
 BOOL CALLBACK PrintDlgProc(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam);
+#endif
%%%%%%%%%%%%%%

There's no way it can be correct to label a Boolean value  as a pointer.

The equivalent substitution occurs several places in your patch.
I didn't check each one, but the routine PrintDlgProc really does return
TRUE or FALSE, so I think at least in this case, if not all of them, 
the original code was correct.

	Ethan

> 
> If I'm understanding the code correctly there's one place that 
> I haven't patched which may be a problem, namely the 
> definition of struct tagLS in win/wgraph.c. The first member 
> of this struct is an int ("widtype"). I believe it should be 
> redefined for win64 as LONG_PTR, since it is assigned to via
> the function GetWindowLong(), which maps to GetWindowLongPtr() 
> on win64, and the latter returns a 64-bit pointer.
> 
> Some of the changes I've made are actually OK for win32, from 
> Windows 2000 onward. But I guess gnuplot aims to support older 
> Windows versions than that; I've therefore bracketed all my 
> changes with "#ifdef _WIN64" so as to leave the 32-bit code 
> unaffected.
> 
> --
> Allin Cottrell
> Department of Economics
> Wake Forest University, NC

gnuplot on 64-bit Windows

[Allin C. <cot...@wf...>]

I have need of a 64-bit Windows build of gnuplot and I've been 
working on cross-compiling from Linux using mingw64. I see 
several places in current CVS where the code generates errors 
and warnings. I'm attaching a patch-set which quells the 
errors and warnings, but unfortunately I'm not able to test on 
win64 at present.

If I'm understanding the code correctly there's one place that 
I haven't patched which may be a problem, namely the 
definition of struct tagLS in win/wgraph.c. The first member 
of this struct is an int ("widtype"). I believe it should be 
redefined for win64 as LONG_PTR, since it is assigned to via
the function GetWindowLong(), which maps to GetWindowLongPtr() 
on win64, and the latter returns a 64-bit pointer.

Some of the changes I've made are actually OK for win32, from 
Windows 2000 onward. But I guess gnuplot aims to support older 
Windows versions than that; I've therefore bracketed all my 
changes with "#ifdef _WIN64" so as to leave the 32-bit code 
unaffected.

--
Allin Cottrell
Department of Economics
Wake Forest University, NC

Re: Bookmark support in pdfcairo?

[Achim G. <Str...@ne...>]

sfeam (Ethan Merritt) writes:
> I don't understand that description.  Are you saying that your pdf output
> from gnuplot consists of several hundred plots and you want each one to
> have an associated "bookmark" (anchor?).

Yes.  Typically there is one plot per page and all pages are entered
into a hierarchical bookmark tree to ease navigation.

> The sequence gnuplot->postscript output->ps2pdf should produce
> a pdf document containing a PDFMark.  But that's one mark per file,
> not one mark per plot.  Does that help any?

We already do this, piping the postscript output into GhostScript and
then feeding the bookmark information inbetween the pages so that the
metadata in the PDF gets built correctly.  However pdfcairo is much
faster, so I'm looking for a way to have cairo build the bookmark tree.

Alternatively, a program that mixes the PDF produced by pdfcairo with
the bookmark information would work.  I've tried pdfjam, but it's even
slower than our current solution.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: Testing Qt5 on Mac

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

On Wed, Jul 17, 2013 at 7:25 PM, Ethan A Merritt wrote:
> On Wednesday, July 17, 2013 01:48:03 am Mojca Miklavec wrote:
>> Hi,
>>
>> just a few observations about testing Gnuplot with Qt5 on Mac:
>> - Printing now works (it didn't work with Qt4)
>
> So can we close bug 1079?

It's up to you and whether you consider Qt4 support obsolete or not.

MacPorts still doesn't package Qt4 and it's unlikely that it will do
any time soon (there are still a lot compile errors).

I'm afraid that this printing problem is only a manifestation of a
deeper problem with forking, but I don't know enough. Qt5 apparently
changed the whole model of how applications work, so it solved this
particular manifestation, but there are other "problems" now (empty
program icon that cannot be hidden, crash on exit on linux)

> On linux, gnuplot+Qt5 works smoothly right up until the time you exit
> the program.  Then the Qt5 exit handlers somehow get tangled up and cause
> a core dump even though the program is trying to exit cleanly.
> I haven't figured out how to disable or bypass the Qt5 exit handlers,
> or otherwise persuade them to not produce a core dump.
> Any ideas?

I don't know enough and this is a pure speculation, but I suspect that
a lot of problems would disappear if gnuplot could avoid forking.

Mojca

Re: Bookmark support in pdfcairo?

[sfeam (E. Merritt) <eam...@gm...>]

On Wednesday, 17 July 2013, Achim Gratz wrote:
> 
> Is there a possibility to add bookmark navigation to files produced from
> pdfcairo?  My reading is that cairo _might_ allow to inject that data
> into the PDF output, but I have no idea how to do that from Gnuplot.

There is a cairo function to attach arbitrary "user data" to a surface
(which is what cairo calls the thing you are in the process of drawing).
However cairo doesn't do anything with this data, and attaching it
while drawing does not change the output file in any way that I can
see.  So I think the answer is "no".

> I'd really like to replace our current solution, which consists of
> piping the data from Gnuplot into GhostScript and merging it with the
> bookmarks definition with pdfcairo since it is many times faster, but
> these PDF routinely get several hundred pages long and not having
> bookmarks to navigate the final document isn't really an option.  I'm
> also open to suggestions that involve postprocessing the PDF produced by
> Gnuplot; the tools I've tried so far (based on pdflatex) are too slow to
> really make it worthwhile however.

I don't understand that description.  Are you saying that your pdf output
from gnuplot consists of several hundred plots and you want each one to
have an associated "bookmark" (anchor?).  Or are you saying that you
want to embed one or more gnuplot-generated plots into a hundred
page text document?  Something else?

The sequence gnuplot->postscript output->ps2pdf should produce
a pdf document containing a PDFMark.  But that's one mark per file,
not one mark per plot.  Does that help any?

	Ethan

 
> 
> Regards,
> Achim.
> 

Bookmark support in pdfcairo?

[Achim G. <Str...@ne...>]

Is there a possibility to add bookmark navigation to files produced from
pdfcairo?  My reading is that cairo _might_ allow to inject that data
into the PDF output, but I have no idea how to do that from Gnuplot.

I'd really like to replace our current solution, which consists of
piping the data from Gnuplot into GhostScript and merging it with the
bookmarks definition with pdfcairo since it is many times faster, but
these PDF routinely get several hundred pages long and not having
bookmarks to navigate the final document isn't really an option.  I'm
also open to suggestions that involve postprocessing the PDF produced by
Gnuplot; the tools I've tried so far (based on pdflatex) are too slow to
really make it worthwhile however.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

Re: Testing Qt5 on Mac

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

On Wednesday, July 17, 2013 01:48:03 am Mojca Miklavec wrote:
> Hi,
> 
> just a few observations about testing Gnuplot with Qt5 on Mac:
> - Printing now works (it didn't work with Qt4)

So can we close bug 1079?

> - There are now two windows in the Dock (gnuplot and gnuplot_qt) and I
> don't know how to close the one called "gnuplot" (the old trick and
> the sole reason why qt_term_mac.c exists doesn't work any more)
> - Setting the application icon doesn't work any more
> - I get the following warnings when saving files:
>   QFileSystemWatcher::removePaths: list is empty
> but I have no clue what they mean.
> 
> None of the mentioned is any serious issue though - I'm surprised that
> it works smoothly, particularly the printing that was broken before.

That's good to hear, and somewhat better than the state of affairs on linux.
On linux, gnuplot+Qt5 works smoothly right up until the time you exit
the program.  Then the Qt5 exit handlers somehow get tangled up and cause
a core dump even though the program is trying to exit cleanly.
I haven't figured out how to disable or bypass the Qt5 exit handlers,
or otherwise persuade them to not produce a core dump.
Any ideas?

	Ethan

Testing Qt5 on Mac

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

Hi,

just a few observations about testing Gnuplot with Qt5 on Mac:
- Printing now works (it didn't work with Qt4)
- There are now two windows in the Dock (gnuplot and gnuplot_qt) and I
don't know how to close the one called "gnuplot" (the old trick and
the sole reason why qt_term_mac.c exists doesn't work any more)
- Setting the application icon doesn't work any more
- I get the following warnings when saving files:
  QFileSystemWatcher::removePaths: list is empty
but I have no clue what they mean.

(I wasn't able to compile it before I removed Qt4 completely. When Qt4
was present, some headers from Qt4 were used instead of those from
Qt5.)

None of the mentioned is any serious issue though - I'm surprised that
it works smoothly, particularly the printing that was broken before.

Mojca

Automake warnings

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

Hi,

I wanted to test the latest gnuplot, but automake (1.14) keeps complaining:

 ./prepare
aclocal: warning: autoconf input should be named 'configure.ac', not
'configure.in'
make: `Makefile.am' is up to date.
make: `Makefile.am' is up to date.
make: `Makefile.am' is up to date.
make: `Makefile.am' is up to date.
make: `Makefile.am' is up to date.
automake: warning: autoconf input should be named 'configure.ac', not
'configure.in'
automake: warning: autoconf input should be named 'configure.ac', not
'configure.in'
src/Makefile.am:93: warning: source file 'wxterminal/wxt_gui.cpp' is
in a subdirectory,
src/Makefile.am:93: but option 'subdir-objects' is disabled
automake: warning: possible forward-incompatibility.
automake: At least a source file is in a subdirectory, but the 'subdir-objects'
automake: automake option hasn't been enabled.  For now, the
corresponding output
automake: object file(s) will be placed in the top-level directory.  However,
automake: this behaviour will change in future Automake versions: they will
automake: unconditionally cause object files to be placed in the same
subdirectory
automake: of the corresponding sources.
automake: You are advised to start using 'subdir-objects' option throughout your
automake: project, to avoid future incompatibilities.
src/Makefile.am:97: warning: source file 'wxterminal/gp_cairo.c' is in
a subdirectory,
src/Makefile.am:97: but option 'subdir-objects' is disabled
src/Makefile.am:97: warning: source file
'wxterminal/gp_cairo_helpers.c' is in a subdirectory,
src/Makefile.am:97: but option 'subdir-objects' is disabled
src/Makefile.am:146: warning: source file 'qtterminal/qt_term.cpp' is
in a subdirectory,
src/Makefile.am:146: but option 'subdir-objects' is disabled
src/Makefile.am:149: warning: source file 'qtterminal/qt_term_mac.m'
is in a subdirectory,
src/Makefile.am:149: but option 'subdir-objects' is disabled
src/Makefile.am:160: warning: source file 'qtterminal/gnuplot_qt.cpp'
is in a subdirectory,
src/Makefile.am:160: but option 'subdir-objects' is disabled
src/Makefile.am:160: warning: source file
'qtterminal/QtGnuplotWindow.cpp' is in a subdirectory,
src/Makefile.am:160: but option 'subdir-objects' is disabled
src/Makefile.am:160: warning: source file
'qtterminal/QtGnuplotApplication.cpp' is in a subdirectory,
src/Makefile.am:160: but option 'subdir-objects' is disabled
src/Makefile.am:160: warning: source file
'qtterminal/QtGnuplotWidget.cpp' is in a subdirectory,
src/Makefile.am:160: but option 'subdir-objects' is disabled
src/Makefile.am:160: warning: source file
'qtterminal/QtGnuplotScene.cpp' is in a subdirectory,
src/Makefile.am:160: but option 'subdir-objects' is disabled
src/Makefile.am:160: warning: source file
'qtterminal/QtGnuplotItems.cpp' is in a subdirectory,
src/Makefile.am:160: but option 'subdir-objects' is disabled
src/Makefile.am:160: warning: source file
'qtterminal/QtGnuplotEvent.cpp' is in a subdirectory,
src/Makefile.am:160: but option 'subdir-objects' is disabled

It nevertheless works, but it would be great to fix these problems (I
know that I can probably downgrade autotools, but ...).

Mojca

Re: 4.6.3 bug: tic labels disappear on minor tics

[Juhász P. <pet...@gm...>]

On Fri, 2013-06-28 at 11:12 -0700, Ethan Merritt wrote:
> On Friday, 28 June 2013, Juhász Péter wrote:
[...]
> 
> Another option is to relax the restriction that tic levels can only be 
> "major" (level 0) and "minor" (level 1).  The code already tracks tic level
> as an integer but ignores requests for tic level 2 or 3 etc.  It should be
> easy to modify the code that so that you can add labels using
>       set xtics add ("Level 2" 2 2)
> I'm not sure what length tic (if any) to assign at higher levels.

I think the goal is to have minor tics that nevertheless could have
labels.

> 
> > Allow the third number (the tic level) in the "set tics" specification
> > to be a real number instead of an integer. There would still be two tic
> > length settings, one for major, the other for minor tics, and the actual
> > length of a tic would be calculated by interpolating between the two
> > pre-set lengths (tic_len = tic_level * (minor - major) + major).
> 
> Sounds too complicated.
> 
> > Any tic level that is not 1 could have labels.
> 
> Yes - this.   Want to send a patch?

I'll try, but of course it's more complicated than it first appeared.
The xtick2d_... etc. callback functions test the text pointer being null
to distinguish between minor and major tics. To break this coupling,
they need to get the tic level as a separate parameter. I'll do it
tomorrow.

Peter

> 
> 	Ethan

Re: 4.6.3 bug: tic labels disappear on minor tics

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

On Friday, 28 June 2013, Juhász Péter wrote:
> On Thu, 2013-06-27 at 16:13 -0700, Jonathan Thornburg wrote:
> [snip]
> >  the label disappears for level 1
> > (minor) tics.  For example,
> >   set xtics (1, 2 1, "" 3 1, "" 4 1, 5 1, "" 6 1, "" 7 1, "" 8 1, "" 9 1, 10)
> > or
> >   set xtics ("1" 1, "2" 2 1, "" 3 1, "" 4 1, "5" 5 1, "" 6 1, "" 7 1, "" 8 1, "" 9 1, "10" 10)
> > each produces a graph with the 2 and 5 labels missing (i.e., only 1 and
> > 10 labels are present).  This behavior is also present for a linear-scale
> > plot, 
> [snip]
> 
> I asked a similar question some months ago and I was told that minor
> tics don't have labels, by definition.
> 
> As far as I know, there is no workaround, because you only have minor
> tics (that don't have labels) and major tics (that may have labels), and
> you can set different sizes for only these two, but all major tics have
> the same length.
> 
> 
> One possible solution that does not break compatibility with the
> existing definition, but provides variable length tics:

Another option is to relax the restriction that tic levels can only be 
"major" (level 0) and "minor" (level 1).  The code already tracks tic level
as an integer but ignores requests for tic level 2 or 3 etc.  It should be
easy to modify the code that so that you can add labels using
      set xtics add ("Level 2" 2 2)
I'm not sure what length tic (if any) to assign at higher levels.

> Allow the third number (the tic level) in the "set tics" specification
> to be a real number instead of an integer. There would still be two tic
> length settings, one for major, the other for minor tics, and the actual
> length of a tic would be calculated by interpolating between the two
> pre-set lengths (tic_len = tic_level * (minor - major) + major).

Sounds too complicated.

> Any tic level that is not 1 could have labels.

Yes - this.   Want to send a patch?

	Ethan

Re: 4.6.3 bug: tic labels disappear on minor tics

[Juhász P. <pet...@gm...>]

On Thu, 2013-06-27 at 16:13 -0700, Jonathan Thornburg wrote:
[snip]
>  the label disappears for level 1
> (minor) tics.  For example,
>   set xtics (1, 2 1, "" 3 1, "" 4 1, 5 1, "" 6 1, "" 7 1, "" 8 1, "" 9 1, 10)
> or
>   set xtics ("1" 1, "2" 2 1, "" 3 1, "" 4 1, "5" 5 1, "" 6 1, "" 7 1, "" 8 1, "" 9 1, "10" 10)
> each produces a graph with the 2 and 5 labels missing (i.e., only 1 and
> 10 labels are present).  This behavior is also present for a linear-scale
> plot, 
[snip]

I asked a similar question some months ago and I was told that minor
tics don't have labels, by definition.

As far as I know, there is no workaround, because you only have minor
tics (that don't have labels) and major tics (that may have labels), and
you can set different sizes for only these two, but all major tics have
the same length.


One possible solution that does not break compatibility with the
existing definition, but provides variable length tics:

Allow the third number (the tic level) in the "set tics" specification
to be a real number instead of an integer. There would still be two tic
length settings, one for major, the other for minor tics, and the actual
length of a tic would be calculated by interpolating between the two
pre-set lengths (tic_len = tic_level * (minor - major) + major).

Any tic level that is not 1 could have labels.


best regards,

Peter Juhasz

4.6.3 bug: tic labels disappear on minor tics

[Jonathan T. <jt...@as...>]

I'm using gnuplot 4.6.3, freshly compiled from the sourceforge tarball.
(See below for my full 'show version long' output.)

I'm trying to produce a log-scale plot with labels at the 1, 2, and 5
positions of each decade.  Alas, If I use the
   "label" posn level 
form of 'set xtics' or 'set ytics', the label disappears for level 1
(minor) tics.  For example,
  set xtics (1, 2 1, "" 3 1, "" 4 1, 5 1, "" 6 1, "" 7 1, "" 8 1, "" 9 1, 10)
or
  set xtics ("1" 1, "2" 2 1, "" 3 1, "" 4 1, "5" 5 1, "" 6 1, "" 7 1, "" 8 1, "" 9 1, "10" 10)
each produces a graph with the 2 and 5 labels missing (i.e., only 1 and
10 labels are present).  This behavior is also present for a linear-scale
plot, i.e., the log-scale is actually irrelevant here (apart from providing
my original motivation).

This works
  set xtics (1, 2, "" 3 1, "" 4 1, 5, "" 6 1, "" 7 1, "" 8 1, "" 9 1, 10)
and so does this
  set xtics ("1" 1 0, "2" 2 0, "" 3 1, "" 4 1, "5" 5 0, "" 6 1, "" 7 1, "" 8 1, "" 9 1, "10" 10 0)
(in the sense that each of these gives labels 1, 2, 5, and 10)
but both of those have the 2 and 5 tics as level-0 (major) instead of
level-1 (minor).

More generally, I can find no way to put a label on a level-1 tic.
It seems to me that is a bug, or at best a mis-feature.
Is there a known workaround (apart from puttting the labels on by hand,
or using multiplot to superimpose another plot)?

Here's a full script to reproduce the problem; comment or uncomment
one of the 'set xtics' command as desired:
--- begin script ---
set xrange [1:10]

# these work (but have 2 and 5 as level 0 (major) tics
##set xtics (1, 2, "" 3 1, "" 4 1, 5, "" 6 1, "" 7 1, "" 8 1, "" 9 1, 10)
##set xtics ("1" 1 0, "2" 2 0, "" 3 1, "" 4 1, "5" 5 1, "" 6 1, "" 7 1, "" 8 1, "" 9 1, "10" 10 0)

# each of these omits the 2 and 5 labels
set xtics (1, 2 1, "" 3 1, "" 4 1, 5 1, "" 6 1, "" 7 1, "" 8 1, "" 9 1, 10)
##set xtics ("1" 1, "2" 2 1, "" 3 1, "" 4 1, "5" 5 1, "" 6 1, "" 7 1, "" 8 1, "" 9 1, "10" 10)
##set xtics ("1" 1 0, "2" 2 1, "" 3 1, "" 4 1, "5" 5 1, "" 6 1, "" 7 1, "" 8 1, "" 9 1, "10" 10 0)

plot sin(x)
--- end script ---

For completeness, here's my ~/.gnuplot file:
--- begin ~/.gnuplot ---
# gnuplot init file
set format "%g"
set term x11
set samples 1000
set style data lines
set zero 0.0
set xyplane 0.0
set clip two
set view ,,0.9
set view 30, 300

min(x,y) = (x < y) ? x : y
max(x,y) = (x > y) ? x : y
hypot(re,im) = sqrt(re**2 + im**2)
cnorm(re,im) = hypot(re,im)
fmod(x,y) = x - y*floor(x/y)
average(x,y) = x + 0.5*(y-x)

# map t in [0,1] --> [a,b]
map01(a,b,t) = a + t*(b-a)
--- end ~/.gnuplot ---

Here's my "show version long" output:
--- begin 'show version long' output ---
gnuplot> show version long

        G N U P L O T
        Version 4.6 patchlevel 3    last modified 2013-04-12 
        Build System: OpenBSD amd64

        Copyright (C) 1986-1993, 1998, 2004, 2007-2013
        Thomas Williams, Colin Kelley and many others

        gnuplot home:     http://www.gnuplot.info
        faq, bugs, etc:   type "help FAQ"
        immediate help:   type "help"  (plot window: hit 'h')
Compile options:
-READLINE  +LIBREADLINE  -HISTORY  
-BACKWARDS_COMPATIBILITY  +BINARY_DATA  
+GD_PNG  +GD_JPEG  +GD_TTF  +GD_GIF  +ANIMATION  
-USE_CWDRC  +X11  +X11_POLYGON  +MULTIBYTE  +X11_EXTERNAL +USE_MOUSE  +HIDDEN3D_QUADTREE  
+DATASTRINGS  +HISTOGRAMS  +OBJECTS  +STRINGVARS  +MACROS  +IMAGE  +USER_LINETYPES +STATS 

GNUPLOT_DRIVER_DIR = "/usr/local/libexec/gnuplot/4.6"
GNUPLOT_PS_DIR     = "/usr/local/share/gnuplot/4.6/PostScript"
HELPFILE           = "/usr/local/share/gnuplot/4.6/gnuplot.gih"

gnuplot> 
--- end 'show version long' output ---

ciao,

-- 
-- "Jonathan Thornburg [remove -animal to reply]" <jt...@as...>
   Dept of Astronomy & IUCSS, Indiana University, Bloomington, Indiana, USA
   on sabbatical in Canada through late August 2013
   "There was of course no way of knowing whether you were being watched
    at any given moment.  How often, or on what system, the Thought Police
    plugged in on any individual wire was guesswork.  It was even conceivable
    that they watched everybody all the time."  -- George Orwell, "1984"

The paradox of scrolling direction (and further problems with scrolling delta)

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

Hi,

this is a somewhat longer email (it's probably also very difficult to
both explain and understand what is going on without a video - I can
provide one if needed), trying to address the following issues:
a) problems with scrolling directions
b) scrolling delta


a) Scrolling direction, related to:
- 2013-03-17 mouse wheel and +/- keys zoom centered on current mouse position
- 2012-01-15 Pass horizontal scroll events through to gnuplot core as
mouse event 6/7

Short version: the patch on 2013-03-17 breaks horizontal scrolling
direction (at least on Mac; on Windows it probably doesn't work
anyway; on my Linux everything seems to be semi-broken).

The long version:
I contributed the first trivial patch when testing more or less
exclusively on Mac. I'm using trackpad
(http://www.apple.com/magictrackpad/) on OS X 10.7 (Lion) which was
the first OS X version that "reversed" the scrolling direction to make
it consistent with iPhones, iPads and other touch devices. That is: if
two fingers slide *up* (away), the page also moves up, but the reading
focus moves *down* the page (equivalent of scrolling down on a normal
mouse) and vice versa. The setting is called "Scroll direction:
natural (Content tracks finger movement)" and can be optionally
switched off. (It was annoying the first few hours of using it, but
it's indeed more natural and it gets more annoying to switch back.) In
the same way one needs to slide fingers from right to left in order to
be able to read a long line of text (the usual left-to-right
direction): the text moves left, but now the eyes finally get to see
the right part of the text.

When using Qt on Mac with "natural scroll direction" turned on
(default since 10.7), sliding with fingers from bottom to top results
in negative event->delta() and  the following code
  // 4 = scroll up, 5 = scroll down
  m_eventHandler->postTermEvent(GE_buttonpress,
    int(event->scenePos().x()), int(event->scenePos().y()),
    event->delta() > 0 ? 4 : 5, 0, 0);
triggers "mouse button 5". The graph moves up, the y axis turns more
negative and all is OK.

When sliding from right to left event->delta() is negative and the
following code
  // 6 = scroll left, 7 = scroll right
  m_eventHandler->postTermEvent(GE_buttonpress,
    int(event->scenePos().x()), int(event->scenePos().y()),
    event->delta() > 0 ? 6 : 7, 0, 0);
triggers "mouse button 7" (scroll right). The problem is that this
worked perfectly fine until 2013-03-17. Now it is sliding in the
opposite direction as it is supposed to.

Note that if I switch the "natural scroll direction" off, the same
actions trigger mouse buttons 4 and 6 respectively.

So scrolling works properly in the released version, but in trunk
version the horizontal scrolling is reversed, at least on Mac. (I
would love to test how this works on *the same* trackpad on Linux, but
I'm reluctant to go through the hell of installing linux on a mac via
dual/tri boot and all my past attempts to boot from USB key on a Mac
machine failed.)

Horizontal scrolling in X11 on Mac is also wrong after the latest
change and worked properly earlier.

-----     -----     -----

Last week my parents bought a new notebook (the cheapest Lenovo) with
a magnificent Synaptic touchpad (videos available on
http://www.synaptics.com/solutions/technology/touchpad). I installed
Kubuntu 13.04 and (I think) libqt4-dev to compile gnuplot. (I can try
with Qt5, but I need to figure out which libraries exactly are needed
first, and I doubt that it would change anything at all.)

The very first thing I changed in settings was to reverse scrolling
direction of the mouse (see
http://www.maketecheasier.com/reverse-mouse-scrolling-direction-in-ubuntu/2011/09/16),
so that the touchpad now behaves exactly as it does on a Mac. (On
Windows I first had to upgrade the touchpad drivers to the latest
version to be able to do that and to enable horizontal scrolling.)

The funny thing: with scrolling direction reversed (non-default
behaviour) the gnuplot code from trunk works properly on linux for
horizontal *and* vertical scrolling. But if I switch back to default
settings, vertical scrolling direction changes, but horizontal
scrolling direction stays the same and thus becomes inconsistent with
vertical behaviour.

I can imagine that these settings on linux might make sense when using
a mouse with a scrolling wheel, one button on the left and one button
on the right. One might want to change the behaviour of the scrolling
wheel, but left & right buttons should stay left & right.

However, with an advanced touchpad it's totally annoying and KDE as
released with the latest Kubuntu doesn't have any setting to reverse
horizontal scrolling direction, only the vertical one (the vertical
direction can be changed under "mouse" and the horizontal one can be
switched on under "touchpad" - maybe this also explains a few
inconsistencies). Another Qt-base program, TeXworks, scrolls in
exactly the opposite horizontal direction as gnuplot does (so it's
consistent with vertical scrolling under default settings and
inconsistent when vertical scrolling direction is reversed).

I also tried to test on Windows, but it would take me too much time to
figure out how to compile gnuplot with sufficient libraries, so I only
tested the binary from sourceforge with wxt (qt is missing), but
horizontal scrolling didn't work there at all. The horizontal scroll
bar showed up, but the graph didn't move. I suspect that wxt on
windows is lacking support for horizontal scrolling, but honestly I
don't really know. (Just for comparison: under "natural scrolling"
setting in Opera horizontal scrolling works fine, in LibreOffice Calc
it's reveresed, and most programs aren't aware of horizontal scrolling
at all. Out of all PDF viewers that I tried only one had support for
pinch/zoom events and that one goes to next/previous page when
horizontal scrolling is used.)

It seems to me that:
i) The current horizontal scrolling direction in gnuplot is wrong
(that is: I suspect that do_zoom_scroll_left() &
do_zoom_scroll_right() should be switched).
ii) The behaviour of horizontal scrolling must be wrong somewhere in
Linux: either in trackpad drivers, somewhere in KDE or ... (I'm not
exactly sure how linux libraries work together).

The cure for (i) could be the following:

--- src/mouse.c
+++ src/mouse.c
@@ -1505,7 +1505,7 @@ zoom_rescale_xyx2y2(double a0,double a1,double
a2,double a3,double a4,double a5,
 static void
 do_zoom_scroll_left()
 {
-    zoom_rescale_xyx2y2(1.1,-0.1, 1,0, 1.1,-0.1, 1,0,  0.1,0.9, 0,1,
0.1,0.9, 0,1,
+    zoom_rescale_xyx2y2(0.9,0.1, 1,0, 0.9,0.1, 1,0,  -0.1,1.1, 0,1,
-0.1,1.1, 0,1,
        "scroll left.\n");
 }

@@ -1513,7 +1513,7 @@ do_zoom_scroll_left()
 static void
 do_zoom_scroll_right()
 {
-    zoom_rescale_xyx2y2(0.9,0.1, 1,0, 0.9,0.1, 1,0,  -0.1,1.1, 0,1,
-0.1,1.1, 0,1,
+    zoom_rescale_xyx2y2(1.1,-0.1, 1,0, 1.1,-0.1, 1,0,  0.1,0.9, 0,1,
0.1,0.9, 0,1,
        "scroll right");
 }

(NB: the same function is also used in builtin_rotate_left and I'm not
sure what that one does; it's very likely that code would have to be
changed in some other places as well, depending on how different key
combinations work and how they are documented, like Shift+scroll etc.)

or the following:

--- src/mouse.c
+++ src/mouse.c
@@ -1730,7 +1730,7 @@ event_buttonpress(struct gp_event_t *ge)

        /* Horizontal stroke (button 6) or Shift+wheel up */
        else if (b == 6 || (modifier_mask & Mod_Shift))
-           do_zoom_scroll_right();
+           do_zoom_scroll_left();

        /* Wheel up (no modifier keys) */
        else
@@ -1750,7 +1750,7 @@ event_buttonpress(struct gp_event_t *ge)

        /* Horizontal stroke (button 7) or Shift+wheel down */
        else if (b == 7 || (modifier_mask & Mod_Shift))
-           do_zoom_scroll_left();
+           do_zoom_scroll_right();

        /* Wheel down (no modifier keys) */
        else

or maybe something else, depending on what people perceive that
"scroll left/right" should mean (compared to "scroll up/down": when
you scroll down, the image actually goes up, not down).

It is true that this would semi-work on some linux boxes, but the
problem on those seems to be elsewhere.


b) Scrolling delta: Qt under Mac uses scrolling delta between 2 and 6
on average (but it can be much bigger depending on the speed of
fingers), while under KDE it is always 120 (or possibly multiples of
it: 240, ... 600). I tried to change settings for speed, but all that
does is possibly change when one event is triggered.

On Mac this is a huge problem for two reasons:

i) Typically a single slide/scroll creates approximately 10 small
events (but it can generate hundreds). It is almost impossible to
scroll for a small amount. One should really take that delta into
account. Petr added partial support to address that problem (email on
2012-07-10, also a patch on sourceforge), but one still needs to
change the way mouse events are handled in the gnuplot core. Currently
a scrolling event with delta 2 or delta 120 results in the same action
and this needs to be addressed somehow.

ii) Even if (i) is addressed, it will still be awfully slow on Macs to
redraw everything ten times for a single slide/scroll. On x11 on Mac
this is not a problem, but Qt really needs some special handling.



Even if the problem (b) is too complicated to solve *right now*: would
it be possible/acceptable to at least reverse direction of horizontal
scrolling (a)? It would be best if Petr would suggest the best
solution since he's the author of the major patch that has been
applied three months ago.

Thank you,
    Mojca