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