gnuplot-beta

Tweak for interactive SVGs?

[Bill B. <bi...@br...>]

I've been generating some plots that get a bit busy, sometimes it's nice to be
able to toggle what you see.  So I wrote a script to tweak the gnuplot output,
and it generates:
         http://cse.ucdavis.edu/bill/barc.svg

Try clicking on any of key titles like "1-thread add".  Currently it's a short
perl script.  The changes are just things like adding a
onclick=ToggleVisibilty call for each key text entry, adding a id= group for
each line in the graph, and of course the small routine to actually toggle the
visibility.

Any comments on how hard it would be to add to the gnuplot SVG output routine?

How useful?

Would a reasonably written patch to do this be accepted?

It interactive toggle is responsible to around 1400 bytes of that 55kb file.

In any case I find it rather useful, especially when comparing two different
datasets.

Re: Tweak for interactive SVGs?

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

Bill Broadley wrote:
> I've been generating some plots that get a bit busy, sometimes it's nice to be
> able to toggle what you see.  So I wrote a script to tweak the gnuplot output,
> and it generates:
>          http://cse.ucdavis.edu/bill/barc.svg
> 
> Try clicking on any of key titles like "1-thread add".  Currently it's a short
> perl script.  The changes are just things like adding a
> onclick=ToggleVisibilty call for each key text entry, adding a id= group for
> each line in the graph, and of course the small routine to actually toggle the
> visibility.
> 
> Any comments on how hard it would be to add to the gnuplot SVG output routine?
> 
> How useful?
> 
> Would a reasonably written patch to do this be accepted?
> 
> It interactive toggle is responsible to around 1400 bytes of that 55kb file.
> 
> In any case I find it rather useful, especially when comparing two different
> datasets.
> 

Hi Bill,

from a user's point of view I love it. I have several cases where this
would be useful including my current main use for gnuplot on an embedded
system.

In view of the relatively light overhead it seems like a very good feature.

I would imagine that the biggest problem would be defining the syntax
for the commands to integrate this idea rather than the implementation
itself. I'll let the core devs reply on that issue.

Are you willing to send me your perl script? I may well implement the
same idea in awk rather than waiting for an eventual integration of this
feature in gnuplot (the embedded does not have perl)


Best regards, Peter.

Re: Tweak for interactive SVGs?

[Bill B. <bi...@br...>]

peter wrote:
> Bill Broadley wrote:
>> I've been generating some plots that get a bit busy, sometimes it's nice to be
>> able to toggle what you see.  So I wrote a script to tweak the gnuplot output,
>> and it generates:
>>          http://cse.ucdavis.edu/bill/barc.svg
>>
> Hi again,
> 
> quick after thought: could you extend it to having the line sample next
> to the title as part of the clickable?

That would be somewhat tricky.  Currently I have:
<text  onclick='ToggleVisibilty(evt, "1add")'>1-thread add</text>

Which is inside a <g> that sets the style, color, widget, font, stroke, etc.

The sample line is part of the entire path:
<path id='1add' d='M715.6,72.0 L757.8,72.0 M774.4,440.3 ...

The first M is the beginning of the sample, the next M is the start of the
graph.  So the quick easy thing to do is:
http://cse.ucdavis.edu/bill/out2.svg

I only fixed 1-thread add, notice that you can click on the graph for that
line, the sample, or the text.  But you can't unclick the sample once it
disappears.  Splitting out the sample so it doesn't disappear would be
somewhat harder, but possible.  There are two fixes for that, making the
sample not disappear, or making it clickable even when invisible... both possible.

> I find it more intuitive if I
> want to hide the dark blue line to click on the dark blue sample since
> that it what I have to identify first. Obviously when you are thinking
> in the other direction, removing "2-thread-add" you are more likely to
> click the text.

Indeed, I considered making the samples much thicker to make them easier to
click on.  Or maybe drawing an invisible but clickable box around the title
and sample so it's easier to click on.

Of course once you get used to this you start wishing that gnuplot's
x11/wxwidgets interface had similar functionality.  I looked around for other
solutions to something like this and found none.  Google Gadgets can do some
of this stuff, but seem toy like and not friendly to log/log graphs.  Open
Flash Chart seems like an interesting approach, they definitely do interactive
charts with tooltip/balloons for the values of the nearest datapoint and the
like, but again I didn't see an easy way to toggle data, nor do log/log
graphs.  So here I am with the best solution I've found so far.

> Both approaches are valid depending on why one wants to hide a line. For
> example if I want to see the detail of your "1-thread add" , I would
> identify the dark green line as the one masking what I want to see and
> it would be my instinct to click on the green line segment. (When I
> realise it does nothing I go for the text).

Indeed.

> The other question is discoverability in the svg graphic. There is no
> established token to indicate the titles are interactive. It may be
> worth adding a bullet or round button before each title as a visual key.
>  This may want to be optional since these titles can encroach on the data.

Indeed, I wasn't sure.  On one hand a traditional radio button and/or checkbox
would be the easiest for a user.  Then again I kinda like not changing the
look at all in case a user wants to use it to look just like it does now.

> consider a small red square with a 1px black outline in front of
> "1-thread add". May be helpful.

Navigating a datafile without any metadata via regular expressions is
definitely not the way to do this.  But if it's done in the SVG output driver
anything along these lines should be possible.

Re: Tweak for interactive SVGs?

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

On Sunday 14 December 2008, Bill Broadley wrote:
> 
> I've been generating some plots that get a bit busy, sometimes it's nice to be
> able to toggle what you see.  So I wrote a script to tweak the gnuplot output,
> and it generates:
>          http://cse.ucdavis.edu/bill/barc.svg
> 
> Try clicking on any of key titles like "1-thread add".  Currently it's a short
> perl script.  The changes are just things like adding a
> onclick=ToggleVisibilty call for each key text entry, adding a id= group for
> each line in the graph, and of course the small routine to actually toggle the
> visibility.
> 
> Any comments on how hard it would be to add to the gnuplot SVG output routine?
> How useful? 
> Would a reasonably written patch to do this be accepted?

That's very nice.

Please have a look at the patchset  #2172587  "Embedded hyperlinks"
https://sourceforge.net/tracker/index.php?func=detail&aid=2172587&group_id=2055&atid=302055

That patchset contains an extension to the svg terminal driver that does
something parallel to your idea. It wraps each plot (and key entry) in
a group with an attached xlink hyperref.   

It may be that you could re-use much of that code.
It may also be that you can see a cleaner way to do it, or better yet
propose an extension that handles both uses via the same mechanism.

As to the associated routine that does the toggling, here also I would 
very much encourage brainstorming about how this could be made as 
general as possible. My long-term vision for the svg terminal
(a goal that I keep trying to hand off to someone else :-)
is to  provide all the necessary infrastructure for a set of associated
scripts to carry out client-side mousing operations like the existing
interactive terminals.  I had been thinking mostly of mouse-tracking and
zoom, but your example makes me realize that other operations like 
toggling the grid or ruler bars are even easier.

-- 
Ethan A Merritt

Re: Tweak for interactive SVGs?

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

Ethan A Merritt wrote:
> On Sunday 14 December 2008, Bill Broadley wrote:
>> I've been generating some plots that get a bit busy, sometimes it's nice to be
>> able to toggle what you see.  So I wrote a script to tweak the gnuplot output,
>> and it generates:
>>          http://cse.ucdavis.edu/bill/barc.svg
>>
>> Try clicking on any of key titles like "1-thread add".  Currently it's a short
>> perl script.  The changes are just things like adding a
>> onclick=ToggleVisibilty call for each key text entry, adding a id= group for
>> each line in the graph, and of course the small routine to actually toggle the
>> visibility.
>>
>> Any comments on how hard it would be to add to the gnuplot SVG output routine?
>> How useful? 
>> Would a reasonably written patch to do this be accepted?
> 
> That's very nice.
> 
> Please have a look at the patchset  #2172587  "Embedded hyperlinks"
> https://sourceforge.net/tracker/index.php?func=detail&aid=2172587&group_id=2055&atid=302055
> 
> That patchset contains an extension to the svg terminal driver that does
> something parallel to your idea. It wraps each plot (and key entry) in
> a group with an attached xlink hyperref.   
> 
> It may be that you could re-use much of that code.
> It may also be that you can see a cleaner way to do it, or better yet
> propose an extension that handles both uses via the same mechanism.
> 
> As to the associated routine that does the toggling, here also I would 
> very much encourage brainstorming about how this could be made as 
> general as possible. My long-term vision for the svg terminal
> (a goal that I keep trying to hand off to someone else :-)
> is to  provide all the necessary infrastructure for a set of associated
> scripts to carry out client-side mousing operations like the existing
> interactive terminals.  I had been thinking mostly of mouse-tracking and
> zoom, but your example makes me realize that other operations like 
> toggling the grid or ruler bars are even easier.
> 

Hi,

I have had another think about adding functionality to svg terminal.
Today I realised that in using my gnuplot output to study system
performance I am constantly needing to read x,y values off the graph.
This currently means zooming to a large magnification, placing the mouse
cursor and then scrolling with arrow keys and praying that it falls near
enought to the axis to read the minor ticks near the cursor.

In short rather unsatisfactory and hacky.

What I need is something like the wxt terminal cursor output.

How feasible would it be to add an onhover or onclick event  and grab
the event x,y and display plot related x,y values? That sounds like it
would be fraught with browser compatibility issues.

Is there a more suitable means of picking up the plot coords of a click?

Thanks, Peter.

Re: Tweak for interactive SVGs?

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

On Sunday 21 December 2008, pl...@pi... wrote:
>
> I have had another think about adding functionality to svg terminal.
> Today I realised that in using my gnuplot output to study system
> performance I am constantly needing to read x,y values off the graph.
> This currently means zooming to a large magnification, placing the mouse
> cursor and then scrolling with arrow keys and praying that it falls near
> enought to the axis to read the minor ticks near the cursor.
> 
> In short rather unsatisfactory and hacky.
> 
> What I need is something like the wxt terminal cursor output.
> 
> How feasible would it be to add an onhover or onclick event  and grab
> the event x,y and display plot related x,y values?

It should be feasible.  I have been trying to drum up enthusiasm for this,
and find a volunteer to code it.

> That sounds like it would be fraught with browser compatibility issues.

To some extent. But there are working example of cross-platform code that
uses javascript to do mouse-tracking.  Here is one:
   http://dunnbypaul.net/js_mouse/

As I see it, we need to put the following in place:

 - create a jscript/ECMScript/javascript/whatever mouse-tracker, which
   can be loaded from either the user's own web site or from some 
   central place like the gnuplot pages on SourceForge.  It should
   read the current mouse coords, apply a transformation matrix (see next)
   and print the transformed coordinates on the page, similar to the 
   current interactive terminals.

 - have the svg driver emit code that refers to the script by its URL,
   and initializes the coordinate system to correspond to the one in
   the current plot by providing an appropriate transformation matrix.

There may be other ways to do it.  I am intrigued by the "canvas terminal
driver" uploaded to SourceForge as patch   #2056054


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

Re: Tweak for interactive SVGs?

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

Ethan A Merritt wrote:
> On Sunday 21 December 2008, pl...@pi... wrote:
>> I have had another think about adding functionality to svg terminal.
>> Today I realised that in using my gnuplot output to study system
>> performance I am constantly needing to read x,y values off the graph.
>> This currently means zooming to a large magnification, placing the mouse
>> cursor and then scrolling with arrow keys and praying that it falls near
>> enought to the axis to read the minor ticks near the cursor.
>>
>> In short rather unsatisfactory and hacky.
>>
>> What I need is something like the wxt terminal cursor output.
>>
>> How feasible would it be to add an onhover or onclick event  and grab
>> the event x,y and display plot related x,y values?
> 
> It should be feasible.  I have been trying to drum up enthusiasm for this,
> and find a volunteer to code it.
> 
>> That sounds like it would be fraught with browser compatibility issues.
> 
> To some extent. But there are working example of cross-platform code that
> uses javascript to do mouse-tracking.  Here is one:
>    http://dunnbypaul.net/js_mouse/
> 
> As I see it, we need to put the following in place:
> 
>  - create a jscript/ECMScript/javascript/whatever mouse-tracker, which
>    can be loaded from either the user's own web site or from some 
>    central place like the gnuplot pages on SourceForge.  It should
>    read the current mouse coords, apply a transformation matrix (see next)
>    and print the transformed coordinates on the page, similar to the 
>    current interactive terminals.

Hi Ethan,

maybe I'm missing the point but can't the javascript be included in the
SVG xml? I don't see it as desirable solution to wait for a response
from sourceforge before my plot can fully render, nor that I need an
open internet connection to diplay a local file.

Externalising what could potentially be common and invariant code may be
an option but I would have thought the first aim should be a self
contained svg file.

regards, Peter.

> 
>  - have the svg driver emit code that refers to the script by its URL,
>    and initializes the coordinate system to correspond to the one in
>    the current plot by providing an appropriate transformation matrix.
> 
> There may be other ways to do it.  I am intrigued by the "canvas terminal
> driver" uploaded to SourceForge as patch   #2056054
> 
> 

Re: Tweak for interactive SVGs?

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

On Sunday 21 December 2008, pl...@pi... wrote:
> Ethan A Merritt wrote:
> > On Sunday 21 December 2008, pl...@pi... wrote:
> >> I have had another think about adding functionality to svg terminal.
> >> Today I realised that in using my gnuplot output to study system
> >> performance I am constantly needing to read x,y values off the graph.
> >> This currently means zooming to a large magnification, placing the mouse
> >> cursor and then scrolling with arrow keys and praying that it falls near
> >> enought to the axis to read the minor ticks near the cursor.
> >>
> >> In short rather unsatisfactory and hacky.
> >>
> >> What I need is something like the wxt terminal cursor output.
> >>
> >> How feasible would it be to add an onhover or onclick event  and grab
> >> the event x,y and display plot related x,y values?
> > 
> > It should be feasible.  I have been trying to drum up enthusiasm for this,
> > and find a volunteer to code it.
> > 
> >> That sounds like it would be fraught with browser compatibility issues.
> > 
> > To some extent. But there are working example of cross-platform code that
> > uses javascript to do mouse-tracking.  Here is one:
> >    http://dunnbypaul.net/js_mouse/
> > 
> > As I see it, we need to put the following in place:
> > 
> >  - create a jscript/ECMScript/javascript/whatever mouse-tracker, which
> >    can be loaded from either the user's own web site or from some 
> >    central place like the gnuplot pages on SourceForge.  It should
> >    read the current mouse coords, apply a transformation matrix (see next)
> >    and print the transformed coordinates on the page, similar to the 
> >    current interactive terminals.
> 
> Hi Ethan,
> 
> maybe I'm missing the point but can't the javascript be included in the
> SVG xml? I don't see it as desirable solution to wait for a response
> from sourceforge before my plot can fully render, nor that I need an
> open internet connection to diplay a local file.

I know very little about mixing javascript and svg, so I can't answer
that question.  But the shared URL could still be a local file.

> Externalising what could potentially be common and invariant code may be
> an option but I would have thought the first aim should be a self
> contained svg file.

In pretty much all cases that I generate SVG plots, it is for display on
dynamically generated pages that contain multiple plots.  Again I don't
know that much about it, but it would seem to me that you would need a
single copy of the script that serves the entire page, and mousing into
the box of any individual plot just triggers a new mouse_coord->plot_coord
transformation matrix.  I don't know if you can have multiple copies of
the same script on the same page, separated by the scope of the 
<svg> tags.  But maybe you can.

-- 
Ethan A Merritt

Re: Tweak for interactive SVGs?

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

Ethan A Merritt wrote:

> In pretty much all cases that I generate SVG plots, it is for display on
> dynamically generated pages that contain multiple plots.  Again I don't
> know that much about it, but it would seem to me that you would need a
> single copy of the script that serves the entire page, and mousing into
> the box of any individual plot just triggers a new mouse_coord->plot_coord
> transformation matrix.  I don't know if you can have multiple copies of
> the same script on the same page, separated by the scope of the 
> <svg> tags.  But maybe you can.
> 

js can be added either externally or within each <svg> tag pair.

<script type="text/ecmascript" xlink:href="scripts/gnuplot.js" />
<script type="text/ecmascript"><![CDATA[
...
]]></script>

I would favour each svg object being complete and autonomous.
Outsourcing the scripts should be regarded as (possibly) an optimisation.


As for the coordinate display, I've given this some thought and I think
there are significant obstacles to using mouse event coords and a matrix.

The main issue being how to detect zoom level in the viewer and also
scrolling of an svg that is bigger than the viewer window. (I often zoom
to max available to examine detail, after all, that is one of the
biggest advantages of using scalar graphics).

I think we would need some coordinate info in the svg output.

I'm thinking of trying:

Each line of a grid could have an onmouseover method called with it's x
or y coord , thus once the mouse has passed at least two x and two y
grid lines the current view is calibrated and your matrix upto date.
This way, current mouse coords could be kept upto date and used in
mousehover to display coords in a bubble (or in status bar of browser?).
It would mean a lot of calls to the mouseover event but there would be
little processing in it and at the time where the user is waving his
mouse around, the system is probably not doing much work in displaying
the svg anyway. This is probably acceptable.

This could potentially leave a period after a zoom or scroll where the
coord transform is out of date but it would basically work. It seems
reasonable to assume that if the user is looking for coord display he
will be moving the mouse around the plot. The calibration grid would
have to be detailed enough to minimise the dead time.

I don't think this would be the actual plot grid as it is now. It may be
better to add a second invisible grid with suitable intervals when this
sort of interactive output is requested. Since the paths would be
straight lines with two end points, this could be done with minimal
overhead in file size.

I think that outlines an implementation method as far as svg markup is
concerned.

regards, Peter.

Re: Tweak for interactive SVGs : coordinate display

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

Ethan A Merritt wrote:

> In pretty much all cases that I generate SVG plots, it is for display on
> dynamically generated pages that contain multiple plots.  Again I don't
> know that much about it, but it would seem to me that you would need a
> single copy of the script that serves the entire page, and mousing into
> the box of any individual plot just triggers a new mouse_coord->plot_coord
> transformation matrix.  I don't know if you can have multiple copies of
> the same script on the same page, separated by the scope of the 
> <svg> tags.  But maybe you can.
> 

Hi,

I'll split this subject from the original thread to distinguish
discussions of coordinate display from Bill's line ToggleVisibility
proposal.


I had a closer look at mouse events and coordinates. As I originally
suspected it gets rapidly bogged down in viewer incompatibilities,
mainly the badly non-standard Abobe plugin for IE. (I just love broken
closed source software!).

Even if restricted to reasonably well written viewers like Opera and
Firefox3 it is a non trivial exercise that involves quite a bit of
javascript to take account of viewports, scrolling etc., and finally the
 accuracy of the output is compromised by the integer resolution of
mouse event coordinates.

There may be a workaround for this latter problem by defining the svg
larger and then zooming down (??).

Much of the basics can be sourced from these sites though further work
will be needed , the tooltip example produces some anomalies and
ViewBox.js comments note some limitations.


http://www.carto.net/papers/svg/gui/tooltips/
http://www.carto.net/papers/svg/resources/mapApp.js
http://www.kevlindev.com/gui/utilities/viewbox/ViewBox.js

regards, Peter.

Re: Tweak for interactive SVGs?

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

Ethan A Merritt wrote:

>> Hi Ethan,
>>
>> maybe I'm missing the point but can't the javascript be included in the
>> SVG xml? I don't see it as desirable solution to wait for a response
>> from sourceforge before my plot can fully render, nor that I need an
>> open internet connection to diplay a local file.
> 
> I know very little about mixing javascript and svg, so I can't answer
> that question.  But the shared URL could still be a local file.

I'll try to find time to look into that a bit over the new year. If you
can link to an external script I dont see why it can't be within the
file itself.

> 
>> Externalising what could potentially be common and invariant code may be
>> an option but I would have thought the first aim should be a self
>> contained svg file.
> 
> In pretty much all cases that I generate SVG plots, it is for display on
> dynamically generated pages that contain multiple plots.  Again I don't
> know that much about it, but it would seem to me that you would need a
> single copy of the script that serves the entire page, and mousing into
> the box of any individual plot just triggers a new mouse_coord->plot_coord
> transformation matrix.  I don't know if you can have multiple copies of
> the same script on the same page, separated by the scope of the 
> <svg> tags.  But maybe you can.
> 

I have not tried to do this in detail but I envisage a <script> tag
defining the function called from an onclick or onhover event on
elements on the graph. This may be possible on the <svg> itself.

Bill's plot toggle seems to establish the principal of how to do that.

In the mean time it would be good to start defining what functionality
to add and how to integrate this into gnuplot command structure.

I would strongly recommend a well thought out and extensible structure
because the possibilities that this kind of technique opens up are vast.
It should be anticipated from the outset that this will develop over
time to be a very full featured extension quite likely with the need to
user definable elements.

Maybe a starting point would be to see how to add Bill's toggle and the
coord display features to the command structure.

I only have a user's understanding of the command syntax so I'll let
others consider that one.

regards, Peter.

current cvs broke?

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

Hi,

I just pulled a clean cvs and it fails at "make install"


make[1]: Leaving directory `/svn/gnuplot/src'
Making install in docs
make[1]: Entering directory `/svn/gnuplot/docs'
../mkinstalldirs /usr/local/share/gnuplot/4.3
/usr/bin/install -c -m 644 gnuplot.gih
/usr/local/share/gnuplot/4.3/gnuplot.gih
Creating texinfo
Symbol's value as variable is void: load
make[1]: *** [gnuplot.texi] Error 255
make[1]: Leaving directory `/svn/gnuplot/docs'
make: *** [install-recursive] Error 1


command sequence was this:

  636  ./prepare
  637  CFLAGS="-O2" ; ./configure --prefix="/usr/local" --without-tutorial
  638  make
  639  make install


BTW , INSTALL instructions for Unix bases system says just run
configure. This does not exist! As a wild guess I ran ./prepare so I
dont know if that is correct. Why are there no valid installation
instructions included with the source code?

thanks , Peter.

Re: current cvs broke?

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

On Friday 26 December 2008, pl...@pi... wrote:
> Hi,
> 
> I just pulled a clean cvs and it fails at "make install"
> 
> 
> make[1]: Leaving directory `/svn/gnuplot/src'
> Making install in docs
> make[1]: Entering directory `/svn/gnuplot/docs'
> ../mkinstalldirs /usr/local/share/gnuplot/4.3
> /usr/bin/install -c -m 644 gnuplot.gih
> /usr/local/share/gnuplot/4.3/gnuplot.gih
> Creating texinfo
> Symbol's value as variable is void: load
> make[1]: *** [gnuplot.texi] Error 255
> make[1]: Leaving directory `/svn/gnuplot/docs'
> make: *** [install-recursive] Error 1

For reasons that we have never pinned down, some people have trouble
regenerating the gnuplot.texi file from gnuplot.doc.  That is the reason
a pre-built version is included in the cvs repository and in the 
distribution, even though it is a derived file.   But it doesn't get
updated in cvs after every single change to gnuplot.doc.

Anyhow, your simplest fix is to do "touch gnuplot.texi" before
issuing the "make" command.  That will cause it to use the current
version rather than trying to rebuild it from source.  I'll update
the copy in cvs the next time I am working on it.

If it were up to me, I would drop the texinfo support altogether.
It's got to be the world's most cumbersome and worst-designed
documentation system.


> BTW , INSTALL instructions for Unix bases system says just run
> configure. 

The INSTALL file contains instructions relevant to people who
receive it as part of the distribution package.  But you are building
directly from the CVS source; that is not the process it describes.

> This does not exist! As a wild guess I ran ./prepare so I 
> dont know if that is correct. Why are there no valid installation
> instructions included with the source code?

You can find several sets of instructions on SourceForge, which is the
same place you must have obtained the CVS source. 

   http://gnuplot.sourceforge.net/development/index.html

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

Re: current cvs broke?

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

On Fri, 26 Dec 2008, Ethan A Merritt wrote:

> If it were up to me, I would drop the texinfo support altogether.
> It's got to be the world's most cumbersome and worst-designed
> documentation system.

Whatever merits it may have had in its day, texinfo seem seriously
obsolete.

Allin Cottrell

Re: Tweak for interactive SVGs?

[James R. V. Z. <jr...@co...>]

Peter <pl...@pi...> writes:

> In the mean time it would be good to start defining what functionality
> to add and how to integrate this into gnuplot command structure.
>
> I would strongly recommend a well thought out and extensible structure
> because the possibilities that this kind of technique opens up are vast.
> It should be anticipated from the outset that this will develop over
> time to be a very full featured extension quite likely with the need to
> user definable elements.

I think these would be useful functions for a selected curve:

 - Toggle visibility (as Bill demonstrated).

 - Move to front/back.

 - Dim (partially desaturate, or just turn light gray) / restore.  

 - Highlight (move to front, and dim all the other curves) / restore.

 - If X2 or Y2 axes are in use, then when you select a curve, it would
   be nice to have the corresponding axes automatically highlighted.

I would also like a way to select a data point on the graph and
display information about it.  In particular:

 - The X, Y (Z, T, U, V) data value, with full precision (not
   transformed to integer screen coordinates then transformed back).
   Also DX and DY for errorbars graphs.

 - Where it came from (file name, line, index, line within index,
   etc.).  Useful for tracking down an outlier.

If there are several data points very close together (say, within an
eight pixel radius), I would like a way to cycle among them.


                - Jim Van Zandt

Re: Tweak for interactive SVGs?

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

On Saturday 27 December 2008, James R. Van Zandt wrote:
> 
> Peter <pl...@pi...> writes:
> 
> > In the mean time it would be good to start defining what functionality
> > to add and how to integrate this into gnuplot command structure.
> >
> > I would strongly recommend a well thought out and extensible structure
> > because the possibilities that this kind of technique opens up are vast.
> > It should be anticipated from the outset that this will develop over
> > time to be a very full featured extension quite likely with the need to
> > user definable elements.
> 
> I think these would be useful functions for a selected curve:
> 
>  - Toggle visibility (as Bill demonstrated).
> 
>  - Move to front/back.
> 
>  - Dim (partially desaturate, or just turn light gray) / restore.  
> 
>  - Highlight (move to front, and dim all the other curves) / restore.
> 
>  - If X2 or Y2 axes are in use, then when you select a curve, it would
>    be nice to have the corresponding axes automatically highlighted.

What sort of user interface would this functionality use?

Would it be possible to implement popup menus for all the interactive
terminals?  
svg - easy if you have already commited to using jscript or the like.
wxt - there is an extension that allow this, but it is very crude
x11 - not without pulling in some additional toolkit layer
win - no idea

Or perhaps we could add a clickable icon to each key entry?
1st click toggles off, 2nd click brings it back at dim/grey,
3rd click highlights, 4th click returns it to the original state



> I would also like a way to select a data point on the graph and
> display information about it.  In particular:
> 
>  - The X, Y (Z, T, U, V) data value, with full precision (not
>    transformed to integer screen coordinates then transformed back).
>    Also DX and DY for errorbars graphs.
> 
>  - Where it came from (file name, line, index, line within index,
>    etc.).  Useful for tracking down an outlier.
> 
> If there are several data points very close together (say, within an
> eight pixel radius), I would like a way to cycle among them.
> 
> 
>                 - Jim Van Zandt

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

Re: Tweak for interactive SVGs? ToggleVisibility

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

Hi,

Bill never got a reply to his question of whether a patch to add
ToggleVisibility to gnuplot would be likely to get accepted. I would
like to reiterate that question.

The changes to svg output would be fairly trivial.

1/ separte line sample form the <path> of the plot itself
2/ add some id="..." identifiers to output. This would actually be a
good idea anyway to enable future expansion of functionality (and
readability of the svg markup: try locating the grid output by scanning
the current output).

eg <path id="line1" d=' ....'></path>
   <path id="line1_sample" d=' ....'></path>

3/ add an onclick event to the legend texts
<text  onclick='toggleVisibility(evt,"line1")'>line1 legend</text>

4/ add a short <script >  [CDATA[ .....</script> to the top of the svg file.

5/ someone will have to come up with a spec for adding this to the
command syntax.

I really like this feature and it would be a good first step in adding
interactivity to gnuplot's svg output.

What are the chances of it getting accepted?

TIA,

Peter.

Re: Tweak for interactive SVGs? ToggleVisibility

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

On Thursday 25 December 2008, pl...@pi... wrote:
> Hi,
> 
> Bill never got a reply to his question of whether a patch to add
> ToggleVisibility to gnuplot would be likely to get accepted. I would
> like to reiterate that question.

I am very interested in seeing the SVG terminal evolve into an
interactive client-side terminal.  So yes, ideas and actual patches
are welcome.

But I'd like there to be some sort of coherent development plan.
It should balance at least two considerations:

1) Features that can be implemented for more than one terminal are 
   prefered.  If toggling the plots on/off interactively is a 
   useful thing to do, why should we limit it to SVG?

2) If at all possible, multiple features added to SVG (or any other
   terminal) should share a common syntax and parallel implementation.
   We can hope that makes them easier to remember for the users and
   easier to maintain for the developers.

So it's great if you want to block out an SVG implementation, as you
do below, but let's also see some suggestions for how this is 
specified by the user in a gnuplot command, and especially let's 
brainstorm whether it can also be implemented for x11, windows,
aquaterm, wxt. Maybe even pdf? fig? 

And, as I requested before, please think about how this addition
fits in with the idea of adding hyperlinks (SourceForge patch #2172587).
Is it best to add lots of command line options, but hide the details
from the user, as in:
    set term svg href=(plots,labels,foo)
or is it better to let the user pass an opaque chunk of text for
inclusion in the output file, perhaps gaining far more flexibility 
but requiring detailed implementation knowledge on the part of the user?
    set term svg plot="some opaque per-plot svg fragment" \
                 key = "some opaque per-key svg fragment" \
                 label="some opaque per-label svg fragment"
                 script="script to be included in output"

My inclination is that the latter approach is only tolerable for
svg-specific features.  Any feature that is shared by multiple
terminals should stand on its own, not requiring device-specific
commands.


> The changes to svg output would be fairly trivial.
> 
> 1/ separte line sample form the <path> of the plot itself
> 2/ add some id="..." identifiers to output. This would actually be a
> good idea anyway to enable future expansion of functionality (and
> readability of the svg markup: try locating the grid output by scanning
> the current output).
> 
> eg <path id="line1" d=' ....'></path>
>    <path id="line1_sample" d=' ....'></path>
> 
> 3/ add an onclick event to the legend texts
> <text  onclick='toggleVisibility(evt,"line1")'>line1 legend</text>
> 
> 4/ add a short <script >  [CDATA[ .....</script> to the top of the svg file.
> 
> 5/ someone will have to come up with a spec for adding this to the
> command syntax.
> 
> I really like this feature and it would be a good first step in adding
> interactivity to gnuplot's svg output.
> 
> What are the chances of it getting accepted?
> 
> TIA,
> 
> Peter.


-- 
Ethan A Merritt

Re: Tweak for interactive SVGs? ToggleVisibility

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

Ethan A Merritt wrote:
> On Thursday 25 December 2008, pl...@pi... wrote:
>> Hi,
>>
>> Bill never got a reply to his question of whether a patch to add
>> ToggleVisibility to gnuplot would be likely to get accepted. I would
>> like to reiterate that question.
> 
> I am very interested in seeing the SVG terminal evolve into an
> interactive client-side terminal.  So yes, ideas and actual patches
> are welcome.
> 
> But I'd like there to be some sort of coherent development plan.
> It should balance at least two considerations:
> 
> 1) Features that can be implemented for more than one terminal are 
>    prefered.  If toggling the plots on/off interactively is a 
>    useful thing to do, why should we limit it to SVG?
> 
> 2) If at all possible, multiple features added to SVG (or any other
>    terminal) should share a common syntax and parallel implementation.
>    We can hope that makes them easier to remember for the users and
>    easier to maintain for the developers.
> 
> So it's great if you want to block out an SVG implementation, as you
> do below, but let's also see some suggestions for how this is 
> specified by the user in a gnuplot command, and especially let's 
> brainstorm whether it can also be implemented for x11, windows,
> aquaterm, wxt. Maybe even pdf? fig? 
> 
I had deliberately stayed away from proposing command syntax since I am
not too familiar with how the core team see it being organised. I did
ask for some input on that aspect.

> And, as I requested before, please think about how this addition
> fits in with the idea of adding hyperlinks (SourceForge patch #2172587).
> Is it best to add lots of command line options, but hide the details
> from the user, as in:
>     set term svg href=(plots,labels,foo)
> or is it better to let the user pass an opaque chunk of text for
> inclusion in the output file, perhaps gaining far more flexibility 
> but requiring detailed implementation knowledge on the part of the user?
>     set term svg plot="some opaque per-plot svg fragment" \
>                  key = "some opaque per-key svg fragment" \
>                  label="some opaque per-label svg fragment"
>                  script="script to be included in output"
> 
> My inclination is that the latter approach is only tolerable for
> svg-specific features.  Any feature that is shared by multiple
> terminals should stand on its own, not requiring device-specific
> commands.
> 

I had imagined something that fits both approaches. I prefer the second
syntax and its flexibility but the simple "opaque" solution can be
compatible by providing the functionality in the form of scripts
included with gnpulot in a predefined location and added into the svg
when plotting.

set term svg plotToggle="some transparent per-plot <script> fragment"

The function could be turned "on" or "off" or substituded by a user
script with this kind of syntax.

set term svg plotToggle="on"   // default = off ?
set term svg plotToggle="custom-script.js"


The toggle feature could clearly be applied to some other terminals as
well but I think because of the DOM / JS interaction SVG will offer a
whole world of dynamic content and interaction that will not be possible
on other terms.

The detail of svg implementation , even in the case of features
available in wxt etc will most likely come from including a javaScript
in the xml or via xlink. I was looking at including such source files in
a directory like the PS files : /usr/local/gnuplot/4.3/javaScript

Maybe you could save me some time by giving me a quick hint at where to
modify to create such a dir?

best regards, Peter.

Re: Tweak for interactive SVGs?

[James R. V. Z. <jr...@co...>]

Ethan A Merritt <merritt@u.washington.edu> writes:
>
> On Saturday 27 December 2008, James R. Van Zandt wrote:
> > 
> > I think these would be useful functions for a selected curve:
> >  - Toggle visibility (as Bill demonstrated).
> >  - Move to front/back.
> >  - Dim (partially desaturate, or just turn light gray) / restore.  
> >  - Highlight (move to front, and dim all the other curves) / restore.
> >  - If X2 or Y2 axes are in use, then when you select a curve, it would
> >    be nice to have the corresponding axes automatically highlighted.
>
> What sort of user interface would this functionality use?
>
> Would it be possible to implement popup menus for all the interactive
> terminals?  
> svg - easy if you have already commited to using jscript or the like.
> wxt - there is an extension that allow this, but it is very crude
> x11 - not without pulling in some additional toolkit layer
> win - no idea
>
> Or perhaps we could add a clickable icon to each key entry?
> 1st click toggles off, 2nd click brings it back at dim/grey,
> 3rd click highlights, 4th click returns it to the original state

I like this concept of cycling among the choices with clicks (though I
think the first click should highlight).

> > I would also like a way to select a data point on the graph and
> > display information about it.  In particular:
> > 
> >  - The X, Y (Z, T, U, V) data value, with full precision (not
> >    transformed to integer screen coordinates then transformed back).
> >    Also DX and DY for errorbars graphs.
> > 
> >  - Where it came from (file name, line, index, line within index,
> >    etc.).  Useful for tracking down an outlier.
> > 
> > If there are several data points very close together (say, within an
> > eight pixel radius), I would like a way to cycle among them.

For drilling down to a particular data point, one could click at or
near it.  The software would scan the data points until finding one
within an N pixel radius, and pop up a window with data about that
point.  For the next click it would restart its scan where it left off
the last time, so all the nearby data points are eventually visited.

            - Jim Van Zandt

Re: Tweak for interactive SVGs?

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

James R. Van Zandt wrote:
> 
> Ethan A Merritt <merritt@u.washington.edu> writes:
>> On Saturday 27 December 2008, James R. Van Zandt wrote:
>>> I think these would be useful functions for a selected curve:
>>>  - Toggle visibility (as Bill demonstrated).
>>>  - Move to front/back.
>>>  - Dim (partially desaturate, or just turn light gray) / restore.  
>>>  - Highlight (move to front, and dim all the other curves) / restore.
>>>  - If X2 or Y2 axes are in use, then when you select a curve, it would
>>>    be nice to have the corresponding axes automatically highlighted.
>> What sort of user interface would this functionality use?
>>
>> Would it be possible to implement popup menus for all the interactive
>> terminals?  
>> svg - easy if you have already commited to using jscript or the like.
>> wxt - there is an extension that allow this, but it is very crude
>> x11 - not without pulling in some additional toolkit layer
>> win - no idea
>>
>> Or perhaps we could add a clickable icon to each key entry?
>> 1st click toggles off, 2nd click brings it back at dim/grey,
>> 3rd click highlights, 4th click returns it to the original state
> 
> I like this concept of cycling among the choices with clicks (though I
> think the first click should highlight).
> 
>>> I would also like a way to select a data point on the graph and
>>> display information about it.  In particular:
>>>
>>>  - The X, Y (Z, T, U, V) data value, with full precision (not
>>>    transformed to integer screen coordinates then transformed back).
>>>    Also DX and DY for errorbars graphs.
>>>
>>>  - Where it came from (file name, line, index, line within index,
>>>    etc.).  Useful for tracking down an outlier.
>>>
>>> If there are several data points very close together (say, within an
>>> eight pixel radius), I would like a way to cycle among them.
> 
> For drilling down to a particular data point, one could click at or
> near it.  The software would scan the data points until finding one
> within an N pixel radius, and pop up a window with data about that
> point.  For the next click it would restart its scan where it left off
> the last time, so all the nearby data points are eventually visited.
> 
>             - Jim Van Zandt
> 

Don't forget that we are talking about the graphical output of a
plotting program. This may be a function plot not data or a log plot or
a result of applying a function to the difference of two data series.

I dont think what you suggests has much meaning outside of a trivial x,y
plot of the input data and while svg has individual vectors for x,y data
 the bitmapped output do not.

I think the only thing that can have meaning here is cursor coordinates
displayed like the wxt terminal does. It would be nice to get that into
svg. A second best would be cross-hairs which help read the coords off
the axses without it having to calculate from the mouse. I don't think
what would be too hard to add.

Peter.

Re: Tweak for interactive SVGs?

[James R. V. Z. <jr...@co...>]

Peter <pl...@pi...> writes:
>James R. Van Zandt wrote:
>> I would also like a way to select a data point on the graph and
>> display information about it.  In particular:
>>
>>  - The X, Y (Z, T, U, V) data value, with full precision (not
>>    transformed to integer screen coordinates then transformed back).
>>    Also DX and DY for errorbars graphs.
>>
>>  - Where it came from (file name, line, index, line within index,
>>    etc.).  Useful for tracking down an outlier.
>
>Don't forget that we are talking about the graphical output of a
>plotting program. This may be a function plot not data or a log plot or
>a result of applying a function to the difference of two data series.
>
>I don't think what you suggests has much meaning outside of a trivial x,y
>plot of the input data and while svg has individual vectors for x,y data
>the bitmapped output do not.

Maybe SVG is the only format that writes full-precision values into
the output file.  If they come from a data file, then depending on its
size, it can be non-trivial to identify where a particular point came
from.  And if the points didn't come from a data file, I would still
like to have access to the full-precision values.

       - Jim Van Zandt