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

AquaTerm 1.1.1

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

Dear all,

I just wanted to let you know that AquaTerm 1.1.1 has been released.

The sources are available at
    https://github.com/AquaTerm/AquaTerm

Binaries can be downloaded from here:
    https://github.com/AquaTerm/AquaTerm/downloads
and support ppc/i386/x86_64 for Mac OS X 10.5 or later.

This is the first released version that properly works on 64-bit macs.
It supports transparency (it didn't support it in version 1.0.1, and
version 1.1.0 had two semi-serious problems). Gnuplot needs a patch to
make transparency work though:
-   AQUA_hasAlphaSupport = [AQTAdapter
respondsToSelector:@selector(setColorRed:green:blue:alpha:)];
+   AQUA_hasAlphaSupport = [adapter
respondsToSelector:@selector(setColorRed:green:blue:alpha:)];
or alternatively
AQUA_hasAlphaSupport = [AQTAdapter
instancesRespondToSelector:@selector(setColorRed:green:blue:alpha:)];


(The sourceforge page still needs to be updated to redirect to GitHub pages.)

Mojca

Fwd: Re: hyperbolic functions - set angle degrees

[Hans-Bernhard B. <HBB...@t-...>]

Oops, forgot to CC the list...

On 16.07.2012 22:39, Ethan A Merritt wrote:
> On Monday, July 16, 2012 12:39:28 pm Bastian Märkisch wrote:

>> While looking into the complex hyperbolic functions, I noticed that
>> asinh, acosh and atanh honour 'set angle degree' setting, while
>> sinh, cosh and tanh do not.
[...]
> I think that is because their domain is not "angles" but instead
> "hyperbolic angles". See
> http://en.wikipedia.org/wiki/Hyperbolic_angle

Obviously true for the real part of the argument of a hyperbolic
function --- not so much for the imaginary.

As-is, we break the defining identity sinh(asinh(x)) = x in 'set angles
degrees' mode.  That's seriously bad news, even if it's documented.
But if we remove the effect of this setting from asinh() etc., we break
another identity: asinh(i*x)=i * asin(x).  That's bad, too, in a
different way.

What this means that no matter what we do, something would break.  Might
as well leave it as it is, if only because people might be relying on
this status quo.

The only sane way out would be to remove 'set angles' altogether, but
I'm afraid it's about 20 years too late for that.

Re: hyperbolic functions - set angle degrees

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

Am 16.07.2012 22:39, schrieb Ethan A Merritt:
> On Monday, July 16, 2012 12:39:28 pm Bastian Märkisch wrote:
>> While looking into the complex hyperbolic functions, I noticed that asinh, acosh and atanh honour 'set angle degree' setting, while sinh, cosh and tanh do not. I know this is documented (see 'help set angles'). But I am curious if anybody remembers the rationale behind this. Is it because of relations like asinh(x) = -i asin(i x)?
>>   I have also tried out various pocket calculators and a few calculator programs, but none of them considered the deg/rad setting for the (inverse) hyperbolic functions.
>>
>
> I think that is because their domain is not "angles" but instead "hyperbolic angles".
> See
> 	http://en.wikipedia.org/wiki/Hyperbolic_angle
>
> Under this interpretation the independent variable is not in radians to begin with,
> so converting it to degrees does not make sense.

That's what I thought. But why do asinh, acosh and atanh care about the 
setting? Should we change that?
Btw. my good old HP48G calculator also ignores the deg/rad setting for 
complex arguments to sin, cos and tan.

Bastian

Re: hyperbolic functions - set angle degrees

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

On Monday, July 16, 2012 12:39:28 pm Bastian Märkisch wrote:
> While looking into the complex hyperbolic functions, I noticed that asinh, acosh and atanh honour 'set angle degree' setting, while sinh, cosh and tanh do not. I know this is documented (see 'help set angles'). But I am curious if anybody remembers the rationale behind this. Is it because of relations like asinh(x) = -i asin(i x)?
>  I have also tried out various pocket calculators and a few calculator programs, but none of them considered the deg/rad setting for the (inverse) hyperbolic functions.
> 

I think that is because their domain is not "angles" but instead "hyperbolic angles".
See
	http://en.wikipedia.org/wiki/Hyperbolic_angle

Under this interpretation the independent variable is not in radians to begin with,
so converting it to degrees does not make sense.

	Ethan

hyperbolic functions - set angle degrees

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

<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>While looking into the complex hyperbolic functions, I noticed that asinh, acosh and atanh honour &#39;set angle degree&#39; setting, while sinh, cosh and tanh do not. I know this is documented (see &#39;help set angles&#39;). But I am curious if anybody remembers the rationale behind this. Is it because of relations like asinh(x) = -i asin(i x)?<br/></div><div> I have also tried out various pocket calculators and a few calculator programs, but none of them considered the deg/rad setting for the (inverse) hyperbolic functions.<br/></div><div><br/></div><div>Bastian<br/></div><div><br/></div></div></body></html>

Re: Gnuplot installer of Dr. Tatsuro MATSUOKA

[Shigeharu T. <sh...@ie...>]

shige 07/12 2012
----------------

Morten Tretmar wrote:
> I am using the recent Gnuplot you are providing gratefully via you
> webpage here:
> http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/
>
> Unfortunately since you switched to a proper installer it is no longer
> possible to install Gnuplot as a non-administrator. I would like to ask
> therefore if it is possible that you could either provide the package as
> ZIP archive, too or adjust the installer so it allows non-administrative
> installations, too.

There is another win32 binary of development version of gnuplot:

ftp://ftp.ring.gr.jp/pub/text/TeX/ptex-win32/w32/gnuplot-47pl0w32.zip
(by A.Kakuto)

+========================================================+
 Shigeharu TAKENO     NIigata Institute of Technology
                       kashiwazaki,Niigata 945-1195 JAPAN
 sh...@ie...   TEL(&FAX): +81-257-22-8161
+========================================================+

Re: mouse zoom centred on mouse position.

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

> >> So it would be very helpful to have not just
> >>     zoom_around_mouse('+');
> >> but rather something like
> >>     zoom_around_mouse(1.134);

I have added this to the patch.

Now you can use a shift factor for scrolling (10% shift is the default) and 
speed for zooming (cca 0.92 and 1.14 being the default, otherwise 
pow(0.92 or 1.14, speed).

Maybe the shift can also be a power instead of that value.

Please try it. Think it over how to pass and evaluate those delta's of fine 
values of mousepad or touchscreen.


> if you redefine the meaning of scrolling event, then please provide 
> drag-and-drop to move around the graph.

You mean click-and-drag, not drag&drop (=dropping objects into the canvas)? 
That would need to go inside button press and release functions in mouse.c. 
If MB3 is clicked (and not released), then allow dragging, otherwise show 
current zoom box.

---
Petr

Re: Gnuplot installer of Dr. Tatsuro MATSUOKA

[Mac-Fly <ma...@gm...>]

> It was not on my list of features to backport, but I'll look into it.
No worries, if you have a release planning I don't want to push anything
here.

> Since you've been using it, do you have any suggestions?
Well for now I am happy with it as it is. Maybe I can describe my
use-case shortly: I am generating Gnuplot scripts out of a (modelling)
software. So far, for certain plots it was easier to integrate the data
directly into the gnuplot script rather than writing a data file and a
script using that data file. However, this limited myself (so far) to
one "plot" call to avoid complex auto-generated code or repeating
integrated data. Now, I can re-use the data easily, so the script
becomes way easier to read and to auto-code.

> I have wondered whether it would be useful to add a variant
> 	$mydata << "filename";
Well I personally could even think of making use of that. Again, mainly
to reduce complexity in auto-generated code or at least improve readability.

Besides these (my) specific use-cases for generated scripts I don't
really see much use in it if you are using Gnuplot from the command line
via the user interface at least. But that is just me.

Thanks again for your time and best regards,

Morten.

On 06.07.2012 22:32, Ethan A Merritt wrote:
> On Friday, July 06, 2012 12:01:50 pm Mac-Fly wrote:
>>
>> Dear Ethan,
>>
>> thank you for that information.
>>
>> Why I am using the 4.7.x branch (recently) is because of this new feature:
>>
>> * NEW inline data can be stored for reuse in named data blocks
>>
>> ...which is actually something I as hoping for a very long time.
>>
>> If this will be implemented in 4.6.1, too I am looking forward to this
>> release. 
> 
> It was not on my list of features to backport, but I'll look into it.
> The code itself is relatively small and unobtrusive, so it may be feasible.
> 
> Ideally it is nice for a new feature to remain in the development version
> long enough to attract bug reports and modification requests before
> including it in an official release version.  Since you've been using it,
> do you have any suggestions?  
> 
> For example, I have wondered whether it would be useful to add a variant
> 	$mydata << "filename";
> that would read the entire contents of a file into a named data block.
> I can't see much call for this if the file is local, but I could imagine
> a case like
>     $mydata << "< wget URL://remote_filename";
> 
> 		cheers,
> 
> 				Ethan
> 
> 
>> Besides: I am writing installers myself, too so I was hoping
>> that this is more a flag for the installer rather than a more complex
>> operation... I might be wrong though.
>>
>> Best regards!
>>
>> Ps.: Let me take the chance to thank you all for your hard work. I am
>> using Gnuplot for more than 10 years now and it is my #1 scriptable and
>> feature rich plotter application. Excellent work!
>>
>> On 06.07.2012 17:42, sfeam (Ethan Merritt) wrote:
>>> On Thursday, 05 July 2012, Morten Tretmar wrote:
>>>> Dear Dr. Tatsuro MATSUOKA,
>>>>
>>>> I am using the recent Gnuplot you are providing gratefully via you webpage here:
>>>> http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/
>>>>
>>>> Unfortunately since you switched to a proper installer it is no longer possible to install Gnuplot as a non-administrator. I would like to ask therefore if it is possible that you could either provide the package as ZIP archive, too or adjust the installer so it allows non-administrative installations, too.
>>>
>>> The latest official release of gnuplot (version 4.6 patchlevel 0),
>>> is provided for download on the project's home site on SourceForge:
>>>   https://sourceforge.net/projects/gnuplot/files/gnuplot/4.6.0/
>>>
>>> It was released in March 2012.
>>> Three windows versions are available, only one of which is wrapped
>>> in the installer that is causing you a problem.
>>>
>>>     gp460-win32-setup.exe  Windows binary installer
>>>     gp460win32.zip         Windows binary (no installer)
>>>     gp460win32x11.zip      Cygwin (x11) binary package
>>>     gp460dj2.zip           DJGPP binary package
>>>
>>> Tatsuro Matsuoka is kind enough to provide occasional snapshot 
>>> builds from the CVS development branch on his private site, but
>>> it is not reasonable to expect that these snapshots will represent
>>> the full range of build options for today's (or even this month's) 
>>> development version.  For that you should download directly from the
>>> CVS source and build it yourself.
>>>
>>> The official version is updated every 6 months or so.  Is there is 
>>> some particular new feature or fix in the CVS source that you are 
>>> missing in 4.6.0?  A list of changes already slated for includion in
>>> 4.6.1 is here:
>>>    http://gnuplot.cvs.sourceforge.net/viewvc/gnuplot/gnuplot/NEWS?revision=1.229.2.27&view=markup
>>>
>>>> With regards,
>>>>
>>>> Morten.
>>>>
>>>> BTW: I send this request here because I read this statement:
>>>> "I prefer that inquiries will be done through gnuplot-beta_atmark_lists.sourceforge.net"
>>>> If that is the wrong place to ask, please guide me accordingly.
>>>
>>> Here is fine.
>>>
>>> 	Ethan 
>>>
>>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and 
>> threat landscape has changed and how IT managers can respond. Discussions 
>> will include endpoint security, mobile security and the latest in malware 
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> gnuplot-beta mailing list
>> gnu...@li...
>> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>>
> 
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 
> 

Re: Gnuplot installer of Dr. Tatsuro MATSUOKA

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

On Friday, July 06, 2012 12:01:50 pm Mac-Fly wrote:
> 
> Dear Ethan,
> 
> thank you for that information.
> 
> Why I am using the 4.7.x branch (recently) is because of this new feature:
> 
> * NEW inline data can be stored for reuse in named data blocks
> 
> ...which is actually something I as hoping for a very long time.
> 
> If this will be implemented in 4.6.1, too I am looking forward to this
> release. 

It was not on my list of features to backport, but I'll look into it.
The code itself is relatively small and unobtrusive, so it may be feasible.

Ideally it is nice for a new feature to remain in the development version
long enough to attract bug reports and modification requests before
including it in an official release version.  Since you've been using it,
do you have any suggestions?  

For example, I have wondered whether it would be useful to add a variant
	$mydata << "filename";
that would read the entire contents of a file into a named data block.
I can't see much call for this if the file is local, but I could imagine
a case like
    $mydata << "< wget URL://remote_filename";

		cheers,

				Ethan


> Besides: I am writing installers myself, too so I was hoping
> that this is more a flag for the installer rather than a more complex
> operation... I might be wrong though.
> 
> Best regards!
> 
> Ps.: Let me take the chance to thank you all for your hard work. I am
> using Gnuplot for more than 10 years now and it is my #1 scriptable and
> feature rich plotter application. Excellent work!
> 
> On 06.07.2012 17:42, sfeam (Ethan Merritt) wrote:
> > On Thursday, 05 July 2012, Morten Tretmar wrote:
> >> Dear Dr. Tatsuro MATSUOKA,
> >>
> >> I am using the recent Gnuplot you are providing gratefully via you webpage here:
> >> http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/
> >>
> >> Unfortunately since you switched to a proper installer it is no longer possible to install Gnuplot as a non-administrator. I would like to ask therefore if it is possible that you could either provide the package as ZIP archive, too or adjust the installer so it allows non-administrative installations, too.
> > 
> > The latest official release of gnuplot (version 4.6 patchlevel 0),
> > is provided for download on the project's home site on SourceForge:
> >   https://sourceforge.net/projects/gnuplot/files/gnuplot/4.6.0/
> > 
> > It was released in March 2012.
> > Three windows versions are available, only one of which is wrapped
> > in the installer that is causing you a problem.
> > 
> >     gp460-win32-setup.exe  Windows binary installer
> >     gp460win32.zip         Windows binary (no installer)
> >     gp460win32x11.zip      Cygwin (x11) binary package
> >     gp460dj2.zip           DJGPP binary package
> > 
> > Tatsuro Matsuoka is kind enough to provide occasional snapshot 
> > builds from the CVS development branch on his private site, but
> > it is not reasonable to expect that these snapshots will represent
> > the full range of build options for today's (or even this month's) 
> > development version.  For that you should download directly from the
> > CVS source and build it yourself.
> > 
> > The official version is updated every 6 months or so.  Is there is 
> > some particular new feature or fix in the CVS source that you are 
> > missing in 4.6.0?  A list of changes already slated for includion in
> > 4.6.1 is here:
> >    http://gnuplot.cvs.sourceforge.net/viewvc/gnuplot/gnuplot/NEWS?revision=1.229.2.27&view=markup
> > 
> >> With regards,
> >>
> >> Morten.
> >>
> >> BTW: I send this request here because I read this statement:
> >> "I prefer that inquiries will be done through gnuplot-beta_atmark_lists.sourceforge.net"
> >> If that is the wrong place to ask, please guide me accordingly.
> > 
> > Here is fine.
> > 
> > 	Ethan 
> > 
> > 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: Gnuplot installer of Dr. Tatsuro MATSUOKA

[Mac-Fly <ma...@gm...>]

Dear Ethan,

thank you for that information.

Why I am using the 4.7.x branch (recently) is because of this new feature:

* NEW inline data can be stored for reuse in named data blocks

...which is actually something I as hoping for a very long time.

If this will be implemented in 4.6.1, too I am looking forward to this
release. Besides: I am writing installers myself, too so I was hoping
that this is more a flag for the installer rather than a more complex
operation... I might be wrong though.

Best regards!

Ps.: Let me take the chance to thank you all for your hard work. I am
using Gnuplot for more than 10 years now and it is my #1 scriptable and
feature rich plotter application. Excellent work!

On 06.07.2012 17:42, sfeam (Ethan Merritt) wrote:
> On Thursday, 05 July 2012, Morten Tretmar wrote:
>> Dear Dr. Tatsuro MATSUOKA,
>>
>> I am using the recent Gnuplot you are providing gratefully via you webpage here:
>> http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/
>>
>> Unfortunately since you switched to a proper installer it is no longer possible to install Gnuplot as a non-administrator. I would like to ask therefore if it is possible that you could either provide the package as ZIP archive, too or adjust the installer so it allows non-administrative installations, too.
> 
> The latest official release of gnuplot (version 4.6 patchlevel 0),
> is provided for download on the project's home site on SourceForge:
>   https://sourceforge.net/projects/gnuplot/files/gnuplot/4.6.0/
> 
> It was released in March 2012.
> Three windows versions are available, only one of which is wrapped
> in the installer that is causing you a problem.
> 
>     gp460-win32-setup.exe  Windows binary installer
>     gp460win32.zip         Windows binary (no installer)
>     gp460win32x11.zip      Cygwin (x11) binary package
>     gp460dj2.zip           DJGPP binary package
> 
> Tatsuro Matsuoka is kind enough to provide occasional snapshot 
> builds from the CVS development branch on his private site, but
> it is not reasonable to expect that these snapshots will represent
> the full range of build options for today's (or even this month's) 
> development version.  For that you should download directly from the
> CVS source and build it yourself.
> 
> The official version is updated every 6 months or so.  Is there is 
> some particular new feature or fix in the CVS source that you are 
> missing in 4.6.0?  A list of changes already slated for includion in
> 4.6.1 is here:
>    http://gnuplot.cvs.sourceforge.net/viewvc/gnuplot/gnuplot/NEWS?revision=1.229.2.27&view=markup
> 
>> With regards,
>>
>> Morten.
>>
>> BTW: I send this request here because I read this statement:
>> "I prefer that inquiries will be done through gnuplot-beta_atmark_lists.sourceforge.net"
>> If that is the wrong place to ask, please guide me accordingly.
> 
> Here is fine.
> 
> 	Ethan 
> 
> 

Re: Gnuplot installer of Dr. Tatsuro MATSUOKA

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

On Thursday, 05 July 2012, Morten Tretmar wrote:
> Dear Dr. Tatsuro MATSUOKA,
> 
> I am using the recent Gnuplot you are providing gratefully via you webpage here:
> http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/
> 
> Unfortunately since you switched to a proper installer it is no longer possible to install Gnuplot as a non-administrator. I would like to ask therefore if it is possible that you could either provide the package as ZIP archive, too or adjust the installer so it allows non-administrative installations, too.

The latest official release of gnuplot (version 4.6 patchlevel 0),
is provided for download on the project's home site on SourceForge:
  https://sourceforge.net/projects/gnuplot/files/gnuplot/4.6.0/

It was released in March 2012.
Three windows versions are available, only one of which is wrapped
in the installer that is causing you a problem.

    gp460-win32-setup.exe  Windows binary installer
    gp460win32.zip         Windows binary (no installer)
    gp460win32x11.zip      Cygwin (x11) binary package
    gp460dj2.zip           DJGPP binary package

Tatsuro Matsuoka is kind enough to provide occasional snapshot 
builds from the CVS development branch on his private site, but
it is not reasonable to expect that these snapshots will represent
the full range of build options for today's (or even this month's) 
development version.  For that you should download directly from the
CVS source and build it yourself.

The official version is updated every 6 months or so.  Is there is 
some particular new feature or fix in the CVS source that you are 
missing in 4.6.0?  A list of changes already slated for includion in
4.6.1 is here:
   http://gnuplot.cvs.sourceforge.net/viewvc/gnuplot/gnuplot/NEWS?revision=1.229.2.27&view=markup

> With regards,
> 
> Morten.
> 
> BTW: I send this request here because I read this statement:
> "I prefer that inquiries will be done through gnuplot-beta_atmark_lists.sourceforge.net"
> If that is the wrong place to ask, please guide me accordingly.

Here is fine.

	Ethan 

Gnuplot installer of Dr. Tatsuro MATSUOKA

[Morten T. <Ma...@gm...>]

Dear Dr. Tatsuro MATSUOKA,

I am using the recent Gnuplot you are providing gratefully via you webpage here:
http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/

Unfortunately since you switched to a proper installer it is no longer possible to install Gnuplot as a non-administrator. I would like to ask therefore if it is possible that you could either provide the package as ZIP archive, too or adjust the installer so it allows non-administrative installations, too.

With regards,

Morten.

BTW: I send this request here because I read this statement:
"I prefer that inquiries will be done through gnuplot-beta_atmark_lists.sourceforge.net"
If that is the wrong place to ask, please guide me accordingly.

Re: mouse zoom centred on mouse position.

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

On Mon, Jun 25, 2012 at 11:57 PM, Petr Mikulik wrote:
>
> I have tested the changes with an USB mouse attached to my notebook.
> But it seems you write only about touchpads?

Apple's trackpad + latest mouses by Apple (I never used one) +
touchscreens (but as long as there is no nice port of gnuplot to a
phone or tablet, those can be ignored).

> (I don't like touchpads. It's a hardware thing that goes worse and worse :-)

In particular, I wasn't talking about any trackpad, but about Apple's
trackpad in particular, and even then I never tested to what extent Qt
applications under Windows/Linux also support those gestures.

>> generate one single scrolling event for one pixel. Usually one gets
>> 2-5 steps with very very tiny movement. Last time when I tested, a
>> single swipe from left to right moved me from default (-10,10) to
>> somewhere around 2000. With a single movement!!! In a native mac
>> application that would correspond to a movement across the width of
>
> Does it mean that touchpad and mouse have very different sensitivity on Mac?

newer trackpads & newer mouses: high sensitivity (for scrolling;
allows zooming in)
older mouses: lower sensitivity (= same as a normal pc mouse), no
support for zooming in
older trackpads: I forgot about sensitivity, but probably no support
for zooming in either

>> So it would be very helpful to have not just
>>     zoom_around_mouse('+');
>> but rather something like
>>     zoom_around_mouse(1.134);
>
> Or a global variable mouse_sensitivity?

What I want to say is that the lowest level function that does zoom in
should have an argument of type "double", not just a "boolean"
(whether to zoom in or out). And then the higher level function could
call it with some default parameter which could be read from a global
variable or from user setting. But the main idea would be not to have
just:
    void zoom(bool in_or_out)
    void shift_x()
    void shift_y()
but rather something like:
    void zoom(double ratio);
    void shift(int pixels_x, int pixels_y);
    void zoom_in() { zoom(1.1); }
    void zoom_out() { zoom(0.9); }
    void shift_right() { shift(0.1*term->size_x,0); }
    void shift_left() { shift(-0.1*term->size_x,0); }
    void shift_up() { shift(0, 0.1*term->size_x); }
    void shift_down() { shift(0, -0.1*term->size_x); }

> So it seems you want different mapping for events generated by touchpads and
> trackpoints than events for mouses,

I'm not sure about that.

With current behaviour I would only have to add "zoom in" events and I
would be done. But if behaviour changes ... I'm not exactly sure about
what would be the best approach.

> because, by chance, the mouse wheel
> up/down events useful for zooming correspond to y-sliding touchpad while
> x-sliding and double-finger gestures on touchpad have no mouse equivalents.

That is true. (Some mouses might have x-sliding though.)

> Is it possible to know the input device sending the event?

Zoom in (pinch) can only be sent by a modern trackpad/mouse.

I'm not sure if it is possible to know whether scrolling is done by an
old mouse or by trackpad, but you can safely assume that the majority
of mac users is using a modern mouse/trackpad. Cocoa is aware of
whether mouse/trackpad has high precision scrolling enabled or not,
but I doubt that one can check that on windows, x11, ... where
trackpad "scrolling"/sliding probably sends exactly the same events as
mouse wheel scrolling. It would be horribly confusing for a Mac user
if X11 and wxt/qt would behave considerably different on the same
machine & with the same binary. That is: scrolling/sliding should
probably not mean "zoom in" in x11 and "move up" in qt in the same
program.


Under wxt (see http://docs.wxwidgets.org/trunk/classwx_mouse_event.html)
there is

    int GetWheelDelta () const
 	Get wheel delta, normally 120.

which is most probably different (smaller) on a modern mouse/trackpad
than on traditional mouses.

In Qt there is

    int QWheelEvent::delta () const

Returns the distance that the wheel is rotated, in eighths of a
degree. A positive value indicates that the wheel was rotated forwards
away from the user; a negative value indicates that the wheel was
rotated backwards toward the user.

Most mouse types work in steps of 15 degrees, in which case the delta
value is a multiple of 120; i.e., 120 units * 1/8 = 15 degrees.

However, some mice have finer-resolution wheels and send delta values
that are less than 120 units (less than 15 degrees). To support this
possibility, you can either cumulatively add the delta values from
events until the value of 120 is reached, then scroll the widget, or
you can partially scroll the widget in response to each wheel event.


Mojca

Re: mouse zoom centred on mouse position.

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

> On Sat, Jun 23, 2012 at 11:23 PM, Petr Mikulik wrote:
> > I have revised the mouse wheel zooming, see patch:
> > https://sourceforge.net/tracker/?func=detail&aid=3537423&group_id=2055&atid=302055
> 
> However (the following comments are all unrelated to your specific
> change), if revising the mouse, I would be very very very grateful if
> functions would be modified in such a way that it would be possible to
> specify the amount of zoom/scroll, not only large discrete steps.

I have tested the changes with an USB mouse attached to my notebook.
But it seems you write only about touchpads?

(I don't like touchpads. It's a hardware thing that goes worse and worse :-) 
That one I have in my Asus notebook is horrible - it is large and flat 
(without edges) but not centered with respect to F and J keys on the 
keyboard so that typing by 10 fingers makes strange things. Hm, yes, 
sometimes I use it ... but I find hitting Arrow or Pg keys much faster for 
scrolling.)

> generate one single scrolling event for one pixel. Usually one gets
> 2-5 steps with very very tiny movement. Last time when I tested, a
> single swipe from left to right moved me from default (-10,10) to
> somewhere around 2000. With a single movement!!! In a native mac
> application that would correspond to a movement across the width of

Does it mean that touchpad and mouse have very different sensitivity on Mac?

> So it would be very helpful to have not just
>     zoom_around_mouse('+');
> but rather something like
>     zoom_around_mouse(1.134);

Or a global variable mouse_sensitivity?

> And related to your change: on Mac it is natural to use scrolling for
> actually scrolling, since there are other events on trackpad which
> allow zooming in (they work the same as maps on smart phones, using
> two fingers and sliding them closer together or further apart).
> Redefining the meaning of scrolling means a slightly unnatural
> experience for mac users, but for the sake of all other more
> widespread OS-es and hardware and for the sake of consistency of
> gnuplot across platforms, it should be acceptable to use key
> combinations that make sense elsewhere.
> 
> However ... if you redefine the meaning of scrolling event, then
> please provide drag-and-drop to move around the graph.

So it seems you want different mapping for events generated by touchpads and 
trackpoints than events for mouses, because, by chance, the mouse wheel 
up/down events useful for zooming correspond to y-sliding touchpad while 
x-sliding and double-finger gestures on touchpad have no mouse equivalents.

Is it possible to know the input device sending the event?

---
PM

Re: mouse zoom centred on mouse position.

[<pl...@pi...>]

On 06/25/12 18:26, Mojca Miklavec wrote:
>   (for example your)

Please note Petr != Peter.  It's not a typo. ;)

Re: mouse zoom centred on mouse position.

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

On Mon, Jun 25, 2012 at 6:26 PM, Mojca Miklavec wrote:
> I have a working code for Qt which
> intercepts & interprets events (by printing out "this is zoom for W%
> around point (X,Y), direction Z"), but I would need (for example your)
> code to actually resize the plot/redraw contents.

Sorry, I meant "for example Peter's".

Mojca

Re: mouse zoom centred on mouse position.

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

On Mon, Jun 25, 2012 at 3:25 PM,  <pl...@pi...> wrote:
> On 06/25/12 10:21, Mojca Miklavec wrote:
>> And related to your change: on Mac it is natural to use scrolling for
>> actually scrolling, since there are other events on trackpad which
>> allow zooming in (they work the same as maps on smart phones, using
>> two fingers and sliding them closer together or further apart).
>
> Does this work on gnuplot ?

Not yet. If I haven't lost it yet, I have a working code for Qt which
intercepts & interprets events (by printing out "this is zoom for W%
around point (X,Y), direction Z"), but I would need (for example your)
code to actually resize the plot/redraw contents. That is: I would
need a function in gnuplot which I could call to do the resizing.

> Do you know what event stream this two finger gesture sends to the
> program with the input focus?

It depends a bit. Here is one example program written in Qt:
    http://qt-project.org/doc/qt-4.8/touch-pinchzoom.html
And here is some Cocoa documentation:
    http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/EventOverview/HandlingTouchEvents/HandlingTouchEvents.html

I don't believe that it would be possible to implement this in X11 (I
might be wrong), in Qt it would be easiest since Qt has up-to-date
support for all Mac OS X sugars, while in wxt it might be only
conditionally doable. Aqua needs mouse support in the first place.

> What point does it scroll on? Finger one; mid pt between fingers; screen
> centre ?

Are we talking about zooming in or moving contents around. If it is
about zooming in, Cocoa returns the middle point between fingers as
the center point, at least I think so. I never did any extensive
experiments, but I could try to play with your code and Qt a bit.

Mojca

PS: There is one minor "problem" though for which I don't think that
gnuplot could be tweaked easily. A smart application would move or
scale current picture during mouse movement without recalculating and
redrawing everything, and only redraw the final image once the mouse
movement is complete. I'm a bit afraid of big speed penalties if
smooth mouse movements are implemented without some intermediate
optimizations.

Re: mouse zoom centred on mouse position.

[<pl...@pi...>]

On 06/25/12 10:21, Mojca Miklavec wrote:
> And related to your change: on Mac it is natural to use scrolling for
> actually scrolling, since there are other events on trackpad which
> allow zooming in (they work the same as maps on smart phones, using
> two fingers and sliding them closer together or further apart).

Does this work on gnuplot ?

Do you know what event stream this two finger gesture sends to the 
program with the input focus?

What point does it scroll on? Finger one; mid pt between fingers; screen 
centre ?

thx

Re: mouse zoom centred on mouse position.

[<pl...@pi...>]

On 06/25/12 10:21, Mojca Miklavec wrote:
> However ... if you redefine the meaning of scrolling event, then
> please provide drag-and-drop to move around the graph.
>
> Thank you,
>      Mojca

Yes, I think this much could be done without confusion or conflicts and 
would get a least one operation free of the keyboards, at the same time 
as providing an interface familiar from pdf viewers and map display 
software.

thanks again for giving this some attention.

Peter.

Re: mouse zoom centred on mouse position.

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

On Sat, Jun 23, 2012 at 11:23 PM, Petr Mikulik wrote:
> I have revised the mouse wheel zooming, see patch:
> https://sourceforge.net/tracker/?func=detail&aid=3537423&group_id=2055&atid=302055

Thank you.

However (the following comments are all unrelated to your specific
change), if revising the mouse, I would be very very very grateful if
functions would be modified in such a way that it would be possible to
specify the amount of zoom/scroll, not only large discrete steps.

Currently a single scroll event moves the graph for approximately
15-40 pixels, while macs allow precise scrolling with pixel precision.
On Mac mouse scrolling events return:
- scrolling direction (up/down or left/right)
- the number of pixels to scroll
and typically one gets several events one after another.

It is practically impossible, or at least very inconvenient to
generate one single scrolling event for one pixel. Usually one gets
2-5 steps with very very tiny movement. Last time when I tested, a
single swipe from left to right moved me from default (-10,10) to
somewhere around 2000. With a single movement!!! In a native mac
application that would correspond to a movement across the width of
the screen.

I volunteer to fix this behaviour in Qt & wxt, but there is no
suitable function to call directly. At the moment I can only "forward
wheel scrolling event", discarding the amount of scrolling (otherwise
it would behave even worse than it does now), but that makes
unproportional movement, depending on the speed of movement, not the
amount of movement.

So it would be very helpful to have not just
    zoom_around_mouse('+');
but rather something like
    zoom_around_mouse(1.134);

Also, as soon as one uses a scrolling event, the default behaviour is
the following (one example):

  if (((b == 5) && (modifier_mask & Mod_Shift)) || (b == 7)) {
    /* scroll right */
    xmin = rescale(FIRST_X_AXIS, .9, .1);
    ymin = rescale(FIRST_Y_AXIS, 1., 0.);
    x2min = rescale(SECOND_X_AXIS, .9, .1);
    y2min = rescale(SECOND_Y_AXIS, 1., 0.);

    xmax = rescale(FIRST_X_AXIS, -.1, 1.1);
    ymax = rescale(FIRST_Y_AXIS, 0., 1.);
    x2max = rescale(SECOND_X_AXIS, -.1, 1.1);
    y2max = rescale(SECOND_Y_AXIS, 0., 1.);
    do_zoom(xmin, ymin, x2min, y2min, xmax, ymax, x2max, y2max);

with hardcoded 10% movement. It would be a lot more useful to have a
finer control of the amount of zoom & movement than just discrete
hardcoded steps. I wanted to change the code, but I'm not sure where
to start. From Qt I can only forward scrolling event or do some other
dirty trickery without knowing much about gnuplot internals.



And related to your change: on Mac it is natural to use scrolling for
actually scrolling, since there are other events on trackpad which
allow zooming in (they work the same as maps on smart phones, using
two fingers and sliding them closer together or further apart).
Redefining the meaning of scrolling means a slightly unnatural
experience for mac users, but for the sake of all other more
widespread OS-es and hardware and for the sake of consistency of
gnuplot across platforms, it should be acceptable to use key
combinations that make sense elsewhere.

However ... if you redefine the meaning of scrolling event, then
please provide drag-and-drop to move around the graph.

Thank you,
    Mojca

Re: mouse zoom centred on mouse position.

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

I have revised the mouse wheel zooming, see patch:
https://sourceforge.net/tracker/?func=detail&aid=3537423&group_id=2055&atid=302055

Tested using a normal USB mouse.
Hotkeys are useful when using touchpad.
Hope you like it.

---
Petr

Re: Build failure in bulding current cvs (2012-06-19) on DJGPP

[Tatsuro M. <tma...@ya...>]

Hello


--- On Thu, 2012/6/21, Tatsuro MATSUOKA  wrote:

> Hello
> 
> I'm trying to build the current cvs source (2012-06-19) on Cygwin, MinGW and DJGPP.
> 
> gcc -c -I/deve/DJDIR/lib/glib/include -Ie:/lua/lua514/src -DHAVE_CONFIG_H -DHAVE_LUA -O3 -fomit-frame-pointer -I. =DHELPFILE=\"gnuplot.gih\" command.c
> command.c:77:23: fatal error: datablock.h: No such file or directory (ENOENT) compilation terminated.
> make.exe: ***[command.o] Error 1
> 
> I'm now using DOSBOX for DJGPP on windows 7 64bit.
> On the DOSBOX, file name of 8.3 format only allowed so that datablock.h
> permitted. I will apply local patch to overcome this issue.  

Sorry for my English was broken.

> I'm now using DOSBOX for DJGPP on windows 7 64bit.
> On the DOSBOX, file name of 8.3 format only allowed so that datablock.h
> permitted. I will apply local patch to overcome this issue.  

On the DOXBOX, file name of 8.3 format only is allowed so that file name datablock.h and datablock.c is not permitted. 
At the moment, I abandon to generate DJGPP binaries.

Regards

Tatsuro 

Re: Build failure in bulding current cvs (2012-06-19) on DJGPP

[Hans-Bernhard B. <HBB...@t-...>]

On 21.06.2012 06:45, Tatsuro MATSUOKA wrote:

> On the DOSBOX, file name of 8.3 format only allowed so that datablock.h
> permitted.

That's not quite it.  Just because the actual name doesn't fit into the 
8.3 scheme doesn't mean the file cannot be available, and findable. 
That only applies if the file system supports long names (LFN), but DOS 
has been restricted to 8.3 format only.

This used to happen a lot back in the days when Windows NT didn't 
support the LFN API in its DOS sessions.  The solution is to either 
install a LFN driver inside the DOSBOX system, or copy files from the 
host system into the DOXBOX such that they end up with properly 
shortened 8.3 names.  DJGPP will find databloc.h if it's looking for 
datablock.h

Re: mouse zoom centred on mouse position.

[<pl...@pi...>]

On 06/21/12 03:58, Tait wrote:
>> Are you saying that you are using some commonly used software that has a
>> sufficiently large user-base  that it should be weighed into a
>> discussion on finding some commonality ?
>>
>> If so , what is it?
>>
>> regards.
>
> I didn't have any one particular software in mind, just a common theme
> that seems to apply to programs I've used: mapping (e.g. Google Earth,
> NGTE), VRML viewers (e.g. web browsers), document viewers for PDF
> (e.g. Acrobat), image editing (e.g. Photoshop), and solid design (CAD
> programs like AutoCad or SolidWorks).
>
> A common exception seems to be using ctrl+wheel for radial/zoom control
> (like Windows, Mathematica, web browsers).
>
>

I tend only to zoom in/out one level or so in web browser so I use keys 
, but you are correct , ctrl+wheel is used for zoom in firefox at least.

However, GoogleEarth zooms on mouse wheel only. As do their embedded 
versions on googlemaps.

I used kicad CAD software which zooms on the mouse position using mouse 
wheel only. This is a fast and efficient way of getting around.

Equally, Gimp is configurable and I have set up mouse+wheel on the image 
for similar behaviour, this leaves mouse events over the scrollbars for 
conventional scrolling.


Clearly 4,5,6,7 are scroll events , the question is how does any 
particular prograrm interpret them.

Document  viewers like browsers and PDF work on larger documents that 
typically do not fit on the screen. It is the whole document that is 
being scrolled/zoomed. The viewer has scrollbars for both directions 
that enable vert/horiz scrolling without recourse to keyboard modifiers.

How happy would anyone be if they had to press the shift key to h-scroll 
a web page. Indeed, I think it's fair to say the graphs more often need 
scrolling horizontally so the inconvenience is perhaps more comparable 
to having to use a modifier to v-scroll a web page.


In gnuplot the axes always fit into the window and there are no 
scrollbars. Even the scroll feature is fairly new (thanks Ethan + Phil 
Jarret).

I see three possible ways this level of interaction could be made a lot 
more efficient.

1. a mouse only zoom control

2. an active region that can act like a scrollbar for each direction (ie 
mouse only scroll)

3. drag-drop within axes bounds.


If there is agreement on the desirability of any of those functions then 
we could look at how they can be achieved without compromising tactile 
devices, for example.

Peter.

Build failure in bulding current cvs (2012-06-19) on DJGPP

[Tatsuro M. <tma...@ya...>]

Hello

I'm trying to build the current cvs source (2012-06-19) on Cygwin, MinGW and DJGPP.

gcc -c -I/deve/DJDIR/lib/glib/include -Ie:/lua/lua514/src -DHAVE_CONFIG_H -DHAVE_LUA -O3 -fomit-frame-pointer -I. =DHELPFILE=\"gnuplot.gih\" command.c
command.c:77:23: fatal error: datablock.h: No such file or directory (ENOENT) compilation terminated.
make.exe: ***[command.o] Error 1

I'm now using DOSBOX for DJGPP on windows 7 64bit.
On the DOSBOX, file name of 8.3 format only allowed so that datablock.h
permitted. I will apply local patch to overcome this issue. 

Regards

Tatsuro