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.