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