Re: brainstorming SVG_INTERACTIVE

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

pl...@pi... wrote:
> Ethan A Merritt wrote:
>> On Monday 29 December 2008, pl...@pi... wrote:
>>> Hi Ethan,
>>>
>>> I have the basic mechanics in place to add some interactivity to
>>> svg.trm, so  I need to look at how to integrate this into the rest of
>>> gnuplot.
>>>
>>> One of the main needs is to sprinkle a few id=xxx markers into the
>>> various path and group elements so they can be identified and
>>> modified via js and the DOM.
>>>
>>> If I want to add another arguement to the functions made visisble in
>>> TERM_TABLE that would seem to mean changing every call and also the
>>> terminals that dont support the new features. While feasible, it seems a
>>> bit radical.
>> You want to add one to every terminal function?
>> That indeed sounds rather disruptive. Can you not achieve the same thing
>> by creating a single new entry that passes in a cookie? 
> 
> I used a method like the href patch in the end just to label the legend
> text and the plot line. These are fairly well defined as you rightly
> point out of the case of labels.
> 
>>> It is generally a good idea to have at least one 'joker' arguement as a
>>> structure pointer in such interdependant interfaces. This allows for
>>> future expansion without altering the prototypes and reorganising the
>>> whole code structure.
>> Opinions vary.  The contrary argument is that if you have to put in 
>> slop variables, this just means that you have not put sufficient thought
>> into getting the interface design right the first time.
> 
> I agree , but I'm sure over lifetime of a project like gnuplot it's
> impossible to even define objectives that will not need changing so by
> definition it's impossible to get the interface "right the first time".
> 
> Since half your variables are going to be stringz you have to work with
> sloppies anyway but I don't see anything sloppy about passing a struct
> pointer. Yyou can still have firmly defined vars within the struct it
> just saves changing the protos.
> 
> Anyway, if you prefer not to I'll leave it there.
> 
>>> This is certainly a result of a long running project that has evolved
>>> well beyond it's original objectives. At some stage it may be worth
>>> adding such extra args.
>>>
>>>
>>> I had a look at the href patch which seems to work by adding a href
>>> variable to some structures and an SVG_href() function to output the
>>> xlink code. This works quite well for the labels and the command syntax
>>> is clear but it looks less robust for more general entities like plots ,
>>> where trying to wrap it needs several flags to keep track of things.
>> "A label" maps directly into a single call to the terminal. So it is
>> easy to attach an additional to it, in this case xlink, and deliver it
>> to the driver at the right time.  "A plot" contains many, many calls to
>> the terminal driver.  If a driver needs to track whether it is currently
>> in the context a plot, or a particular plot, it needs to maintain state
>> variables.
>>
> 
> I used a method like the href patch in the end just to id the legend
> text and the plot line. These are "fairly" well defined as you rightly
> point out is the case of labels. This approach is fine for just tacking
> on a bit of functionality but don't regard it as a very robust approach.
> 
> Anyway, I've hooked that up to something like Bill's toggle code and
> I've got what I wanted a gnuplot implementation of Bill's perl hack.
> 
> graphics.c
> 
> 	/* Draw key text in black */
> 	(*t->linetype)(LT_BLACK);
> //*** add legend onclick here
> if (term->set_id_click) (term->set_id_click) ("legend#","line#");
> 
> 
> 
> //*** force separte path for plot and sample (re svg_interactive)
> 		closepath();
> //*** add id to plot line to toggle***
> if (term->set_id_click) (term->set_id_click) ("line#",NULL);
> 
>     /* oops - doing the point sample now would break the postscript
> 
> 
> The onclick is in svg.js so eventually user accessible without
> recompilation.
> 
> It's a one off feature so probably could used a syntax like:
> 
> set key toggleVisiblitly
> 
> 
> Let me know if you have a better idea.
> 
> regards, Peter.
> 
> 

OK I've added set key clickable/noclickable cleaned up a bit and done
trivial testing.

Here's the patch. Though I probably missed something out. ;)

Thanks to Bill for the idea and the perl hack to do it.

regards, Peter.