Re: brainstorming SVG_INTERACTIVE

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

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.