Re: brainstorming SVG_INTERACTIVE

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

Ethan A Merritt wrote:
> On Tuesday 30 December 2008, pl...@pi... wrote:
> 
>> It was the js eventhandler for onclick . I originally wanted to extend
>> the argument list with a struct pointer as I suggested but you weren't
>> keen.
> 
> You misunderstood me. I was not objecting to passing a structure pointer; 
> I think that is a good idea.  I was just pointing out that extra
> parameters added "for slop" are not a great recommendation for a design.
> 
>>> 4) Please document the use of term->set_id_click(), term->move_ex(), and so on.
>>>    The description must be complete enough so that someone can code up the
>>>    corresponding routines for other terminals.  
>>>    It seems that you only ever pass in strings "legend#", "line#", and "sample#".
>>>    Do these have to be strings at all? Can they be defined constants?   Enums?   
>> For the purposes of this functionality yes, future js may want actual
>> variables here so I left it open.
> 
> But the core code cannot pass anything that is specific to a particular
> terminal driver.  Anything that refers to jscript or svg tags must be
> generated by the driver from generic requests passed in from the core.
> It's OK to pass a URL as a string so that the driver can wrap it in 
> whatever code is needed to trigger that link.  But it's not OK to have
> the core code pass in a fragment of xml or jscript or svg or whatever.
> The same call has to work for other terminal drivers.
> 
I realise that , there will be some generics that several terminals can
do but that should not cripple what svg is capable of.

Adding a link effectively means adding an onclick event , that is
possible in latex svg pdf, possibly bitmapped. SVG offers the
possiblitly to add the interactivity of the current real-time
interactives but after the fact and in a distribuatable form. More over
much of that functionality can be user determined not limitted to what
is compiled into gnuplot.

I think the generic approach should be pushed as far as possible without
killing the power of what svg offers that the others never can.

That would seem to be in keeping with the current philosophy.


> 
>>> 5) It would be good to include a demo script, so that people can test the
>>>    patchset immediately without having to learn the details first.
>>>
>> Yes a demo would be good, I just wanted to make sure it was in an
>> acceptable form before going to that sort of lengths.
> 
> You'll get more testers if you make easy to test.
> The easiest test is to run a script that is supposed to work.
> If the tester has to roll his own, and it doesn't work, then he
> doesn't know whether the code is failing or if he misunderstood
> how to use it, or what.
> 
> Even if you post a sample output plot, it is good to also provide the
> script that generated it. For instance, in the plot you posted before,
> "150tank-test.svg", only 2 of the 9 plots listed in the key are visible.
> Those two can be toggled off, but the other 7 cannot be toggled on.
> Is this intended?  Is it a bug?  Hard to say without seeing the script.

Which is why I did not post the script , I sent the first rough to the
list so your could see it work. Its not a demo file.

> 
>> I wanted to get this checked a bit before submitting to SF but you
>> requested I post it. Once you're happy with the state of it I'll resubmit.
> 
> 
> 

/P