gnuplot-beta — Developers and beta testers of new gnuplot code

[transferred from Email] Providing/exporting a table of plot style properties

[Ethan A M. <merritt@u.washington.edu>]

[from a conversation started off list]
[summary] The question is whether the code in get_data()
plot2d.c lines 327ff   can be replaced by a table-lookup,
or deleted altogether.   This code sets limits min_cols and max_cols
for the number of columns specified in the "using" part of a plot
command.  Ralf's proposed table would also hold properties like
PLOT_STYLE_HAS_FILL that are currently single bits set in the
line style definitions in gp_types.h

On Saturday 03 January 2009, Ralf Juengling wrote:
> 
> On Sat, 3 Jan 2009, Ethan A Merritt wrote:
> 
> > Your patch may be heading towards something useful, I'll wait
> > and see how it ends up.  As I understand it, the idea is not so
> > much to fix or improve gnuplot per se, but to make a table for
> > use by an external program.  I'm not sure it is worth doing this
> > inside gnuplot;  for the same amount of work you could just make
> > the table part of the external program.  That would have the
> > advantage of working with older versions of gnuplot that don't
> > have your table built in.
> 
> While my main motivation for this patch his making plot style
> properties explicit to applications that generate gnuplot
> scripts, it certainly is useful in that it improves clarity
> of the code. And I would not be surprised if having such a
> descriptor table would enable simplifications at other places
> as well. The reason I would rather see it builtin and used
> than external is that this guarantees the table is current.
> 
> Can you think of other properties that would be useful to
> have in the table? I think it would be useful to know that
> a plot style expects non-numeric input (e.g., labels). 

As you move into that kind of question, I start to think that
the whole idea of a fixed set of properties for a given plot
type breaks down.  For instance, any plot command that includes
  using xticlabels(N)
will require reading from column N and will be expecting non-numeric
data.  But this is outside of the count of columns that the code in
get_data() is making, and the expectation of non-numeric data is
tacked on to whatever expectations the plot style already had.

Similarly, each use of the propery "variable" adds a column of
expected input, independent of however many columns were already
expected.   I am not sure that preparing a table in advance 
actually serves any useful purpose, at least internal to gnuplot.
One really has to total up the number of columns referred to in
this specific plot command.  The specific plot style is largely
irrelevant.

It was this kind of argument that made me inclined to delete
all the code tracking min_cols and max_cols.   Other than issuing
an error message if the command fails to provide at least min_cols
of using specs, they aren't much use for anything.  It may not even
generate an error message if you exceed max_cols, as you have already
pointed out with regard to filledcurves.

> What 
> aboutthe has_grid_topology property in struct surface_points?
> Is that not plot-style specific property?

In truth, I know essentially nothing about the 3dgrid code.
Let's move this discussion to the mailing list so that other people
can usefully comment.


-- 
Ethan A Merritt

Re: [transferred from Email] Providing/exporting a table of plot style properties

[Ethan A M. <merritt@u.washington.edu>]

On Saturday 03 January 2009, Ethan A Merritt wrote:
> On Saturday 03 January 2009, Ralf Juengling wrote:
> 
> > While working on this patch I noticed that xyerrorlines takes
> > up to six data columns plus optionally two more (ps variable, lc
> > variable), which exceeds MAXDATACOLS in datafile.h. Is this a
> > known problem?
> 
> Huh?  xyerrorlines has no points, so how can it have 'ps variable'?
> 
> But yes, there are plot styles that would go over the 7 column limit
> if all the properties were variable.  This is particularly true
> for "linespoints", and several people have complained about it.
> 
> Of course it is possible to increase the number of slots in 
> 
> typedef struct coordinate {
>     enum coord_type type;       /* see above */
>     coordval x, y, z;
>     coordval ylow, yhigh;       /* ignored in 3d */
>     coordval xlow, xhigh;       /* also ignored in 3d */
> } coordinate;
> 
> from 7 to some larger number.

For instance, I would welcome a patch that added a field
     coordval color;
as already commented in the code.
The current handling of color information is a terrible hodgpodge,
with different plot style storing it in various different slots,
and the actual plot code then having to figure out where to pull
it from.  

That would both simplify the color-handling code and free up 
another data slot for storing values read to support other uses
of the "variable" attribute.

	Ethan


> For large datasets this would  
> cause a significant increase in memory use, whether or not the
> plot actually used the extra slots.
> Maybe that's OK.  Memory is cheap these days.
> But if we are going to do that, we need some more coherent system of
> where to store what kind of value.  The definitions that are in the
> code as deceptive, in that they are not always true.
> 
> /* These fields of 'struct coordinate' used for storing the color of 3D data
>  * points (if requested by NEED_PALETTE(this_plot), for instance).
>  */
> #define CRD_COLOR ylow
> #define CRD_R yhigh
> #define CRD_G xlow
> #define CRD_B xhigh
> #define CRD_A ylow
> /* The field of 'struct coordinate' used for storing the point size in plot
>  * style POINTSTYLE with variable point size
>  */
> #define CRD_PTSIZE xlow
> 
> 
> 
> 



-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: [transferred from Email] Providing/exporting a table of plot style properties

[Ethan A M. <merritt@u.washington.edu>]

On Saturday 03 January 2009, Ralf Juengling wrote:

> While working on this patch I noticed that xyerrorlines takes
> up to six data columns plus optionally two more (ps variable, lc
> variable), which exceeds MAXDATACOLS in datafile.h. Is this a
> known problem?

Huh?  xyerrorlines has no points, so how can it have 'ps variable'?

But yes, there are plot styles that would go over the 7 column limit
if all the properties were variable.  This is particularly true
for "linespoints", and several people have complained about it.

Of course it is possible to increase the number of slots in 

typedef struct coordinate {
    enum coord_type type;       /* see above */
    coordval x, y, z;
    coordval ylow, yhigh;       /* ignored in 3d */
    coordval xlow, xhigh;       /* also ignored in 3d */
} coordinate;

from 7 to some larger number.  For large datasets this would 
cause a significant increase in memory use, whether or not the
plot actually used the extra slots.
Maybe that's OK.  Memory is cheap these days.
But if we are going to do that, we need some more coherent system of
where to store what kind of value.  The definitions that are in the
code as deceptive, in that they are not always true.

/* These fields of 'struct coordinate' used for storing the color of 3D data
 * points (if requested by NEED_PALETTE(this_plot), for instance).
 */
#define CRD_COLOR ylow
#define CRD_R yhigh
#define CRD_G xlow
#define CRD_B xhigh
#define CRD_A ylow
/* The field of 'struct coordinate' used for storing the point size in plot
 * style POINTSTYLE with variable point size
 */
#define CRD_PTSIZE xlow




-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: [transferred from Email] Providing/exporting a table of plot style properties

[Ralf J. <jue...@cs...>]

On Sat, 3 Jan 2009, Ethan A Merritt wrote:

> [from a conversation started off list]
> [summary] The question is whether the code in get_data()
> plot2d.c lines 327ff   can be replaced by a table-lookup,
> or deleted altogether.   This code sets limits min_cols and max_cols
> for the number of columns specified in the "using" part of a plot
> command.  Ralf's proposed table would also hold properties like
> PLOT_STYLE_HAS_FILL that are currently single bits set in the
> line style definitions in gp_types.h

The number of data columns all the plotting style accepts and
what optional columns they may take (for variable line color
or variable point size) is scattered across the documentation.
There currently does not seem to be a place in the code that
makes this information explicit. I think it would be useful to
have this, however, for the reasons stated below.

>> While my main motivation for this patch his making plot style
>> properties explicit to applications that generate gnuplot
>> scripts, it certainly is useful in that it improves clarity
>> of the code. And I would not be surprised if having such a
>> descriptor table would enable simplifications at other places
>> as well. The reason I would rather see it builtin and used
>> than external is that this guarantees the table is current.


While working on this patch I noticed that xyerrorlines takes
up to six data columns plus optionally two more (ps variable, lc
variable), which exceeds MAXDATACOLS in datafile.h. Is this a
known problem?

Ralf

Re: Tweak for interactive SVGs?

[James R. V. Z. <jr...@co...>]

Peter <pl...@pi...> writes:
>James R. Van Zandt wrote:
>> I would also like a way to select a data point on the graph and
>> display information about it.  In particular:
>>
>>  - The X, Y (Z, T, U, V) data value, with full precision (not
>>    transformed to integer screen coordinates then transformed back).
>>    Also DX and DY for errorbars graphs.
>>
>>  - Where it came from (file name, line, index, line within index,
>>    etc.).  Useful for tracking down an outlier.
>
>Don't forget that we are talking about the graphical output of a
>plotting program. This may be a function plot not data or a log plot or
>a result of applying a function to the difference of two data series.
>
>I don't think what you suggests has much meaning outside of a trivial x,y
>plot of the input data and while svg has individual vectors for x,y data
>the bitmapped output do not.

Maybe SVG is the only format that writes full-precision values into
the output file.  If they come from a data file, then depending on its
size, it can be non-trivial to identify where a particular point came
from.  And if the points didn't come from a data file, I would still
like to have access to the full-precision values.

       - Jim Van Zandt

Re: error "contradicting arguments"

[Ralf J. <jue...@cs...>]

On Tue, 30 Dec 2008, Ethan A Merritt wrote:

>> gnuplot gives me an error:
>>
>>   line 3: duplicated or contradicting arguments in plot options
>>
>> Not sure why it generates an error, the user-defined linestyle
>> does not specify a color.
>
> [..]
>
>> Bug or feature?
>
> Probably no one thought about it much one way or the other.
> I don't know if there would be further problems if the parser were
> changed to accept additional qualifiers after the "ls 1".

Yes, why not accept duplicate specifications without error
and let later specifications override earlier ones? E.g.,

set style line 1 lc 1 lc 2

would be equivalent to

set style line 1 lc 2

While a user rarely has reason to write code like this, you
argue, a more tolerant command line processing would simplify
writing applications that auto-generate gnuplot code.

And, as a side benefit, removing checks for duplicates would
simplify the code in parsing routines lp_parse(), eval_plots()
and such.

Ralf

Re: Tweak for interactive SVGs?

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

James R. Van Zandt wrote:
> 
> Ethan A Merritt <merritt@u.washington.edu> writes:
>> On Saturday 27 December 2008, James R. Van Zandt wrote:
>>> I think these would be useful functions for a selected curve:
>>>  - Toggle visibility (as Bill demonstrated).
>>>  - Move to front/back.
>>>  - Dim (partially desaturate, or just turn light gray) / restore.  
>>>  - Highlight (move to front, and dim all the other curves) / restore.
>>>  - If X2 or Y2 axes are in use, then when you select a curve, it would
>>>    be nice to have the corresponding axes automatically highlighted.
>> What sort of user interface would this functionality use?
>>
>> Would it be possible to implement popup menus for all the interactive
>> terminals?  
>> svg - easy if you have already commited to using jscript or the like.
>> wxt - there is an extension that allow this, but it is very crude
>> x11 - not without pulling in some additional toolkit layer
>> win - no idea
>>
>> Or perhaps we could add a clickable icon to each key entry?
>> 1st click toggles off, 2nd click brings it back at dim/grey,
>> 3rd click highlights, 4th click returns it to the original state
> 
> I like this concept of cycling among the choices with clicks (though I
> think the first click should highlight).
> 
>>> I would also like a way to select a data point on the graph and
>>> display information about it.  In particular:
>>>
>>>  - The X, Y (Z, T, U, V) data value, with full precision (not
>>>    transformed to integer screen coordinates then transformed back).
>>>    Also DX and DY for errorbars graphs.
>>>
>>>  - Where it came from (file name, line, index, line within index,
>>>    etc.).  Useful for tracking down an outlier.
>>>
>>> If there are several data points very close together (say, within an
>>> eight pixel radius), I would like a way to cycle among them.
> 
> For drilling down to a particular data point, one could click at or
> near it.  The software would scan the data points until finding one
> within an N pixel radius, and pop up a window with data about that
> point.  For the next click it would restart its scan where it left off
> the last time, so all the nearby data points are eventually visited.
> 
>             - Jim Van Zandt
> 

Don't forget that we are talking about the graphical output of a
plotting program. This may be a function plot not data or a log plot or
a result of applying a function to the difference of two data series.

I dont think what you suggests has much meaning outside of a trivial x,y
plot of the input data and while svg has individual vectors for x,y data
 the bitmapped output do not.

I think the only thing that can have meaning here is cursor coordinates
displayed like the wxt terminal does. It would be nice to get that into
svg. A second best would be cross-hairs which help read the coords off
the axses without it having to calculate from the mouse. I don't think
what would be too hard to add.

Peter.

Re: Patch for makefile.mgw using gdlib-config

[Tatsuro M. <tma...@ya...>]

Hello

I found that microsoft help work shop has been no longer available from 

   www.helpmaster.com/help/devaids.htm.

that was indicated in makefile.mgw

I also have found that it is now available from

   ftp://ftp.microsoft.com/softlib/mslfiles/hcwsetup.exe

Therefore makefile.mgw has also modified from this point.

The patch has been shown in the end of the mail  

--- Tatsuro MATSUOKA <tma...@ya...> wrote:

> Hello
> 
> The current gd (gd-2.0.36RC1) has gdlib-config, which enable us to get information for
> configuration
> of the gd libraries and tools.  Therefore it is better to use it for makefile,mgw.
> Perhaps similar modification can be made for makefile.cyg.
> 
> Please consider a patch at the end of this mail.


*** makefile.mgw.orig	Sun Nov 23 16:48:58 2008
--- makefile.mgw	Wed Dec 31 16:02:48 2008
***************
*** 103,109 ****
  
  
  # To compile the .hlp file you need hcw either out of Microsoft SDK or MS Help
! # Workshop. The latter can be obtained at www.helpmaster.com/help/devaids.htm.
  # Put the path to hcw here unless it is already in PATH:
  #HCWPATH = /c/Program\ Files/Help\ Workshop/
  HCW = $(HCWPATH)hcw
--- 103,109 ----
  
  
  # To compile the .hlp file you need hcw either out of Microsoft SDK or MS Help
! # Workshop. The latter can be obtained at ftp://ftp.microsoft.com/softlib/mslfiles/hcwsetup.exe.
  # Put the path to hcw here unless it is already in PATH:
  #HCWPATH = /c/Program\ Files/Help\ Workshop/
  HCW = $(HCWPATH)hcw
***************
*** 208,219 ****
    CFLAGS += -DHAVE_GD_GIF -DGIF_ANIMATION -DHAVE_GD_PNG
  ifdef JPEG
    CFLAGS += -DHAVE_GD_JPEG
-   TERMLIBS += -ljpeg
  endif
  ifdef FREETYPE
    CFLAGS += -DHAVE_GD_TTF
-   TERMLIBS += -lfreetype
  endif
  endif
  
  ifdef PDF
--- 208,218 ----
    CFLAGS += -DHAVE_GD_GIF -DGIF_ANIMATION -DHAVE_GD_PNG
  ifdef JPEG
    CFLAGS += -DHAVE_GD_JPEG
  endif
  ifdef FREETYPE
    CFLAGS += -DHAVE_GD_TTF
  endif
+   TERMLIBS += $(shell gdlib-config --libs)
  endif
  
  ifdef PDF



--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Re: error "contradicting arguments"

[Ethan A M. <merritt@u.washington.edu>]

On Tuesday 30 December 2008, Ralf Juengling wrote:
> Greetings,
> 
> When I do this
> 
> set style line 1 lt -1 lw 2
> set style increment user
> plot 'data.txt' with lines ls 1 lc rgb variable
> 
> gnuplot gives me an error:
> 
>   line 3: duplicated or contradicting arguments in plot options
> 
> Not sure why it generates an error, the user-defined linestyle
> does not specify a color. 

From the perspective of the internal implementation, 
the line style does specify a color; the color is "lt -1".

But the real problem is that the command parser stops
looking for further style information once it sees "ls 1".
You will see this at the very top of the routine lp_parse()
in file misc.c

Given that you have already done "set style increment user",
the command "plot ... lt 1 lc rgb variable" should do the
same thing as "ls 1 lc rgb variable" would have done if the
parser accepted it.

> Bug or feature? 

Probably no one thought about it much one way or the other.
I don't know if there would be further problems if the parser were
changed to accept additional qualifiers after the "ls 1".
You could try modifying the code in lp_parse().

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: Tweak for interactive SVGs?

[James R. V. Z. <jr...@co...>]

Ethan A Merritt <merritt@u.washington.edu> writes:
>
> On Saturday 27 December 2008, James R. Van Zandt wrote:
> > 
> > I think these would be useful functions for a selected curve:
> >  - Toggle visibility (as Bill demonstrated).
> >  - Move to front/back.
> >  - Dim (partially desaturate, or just turn light gray) / restore.  
> >  - Highlight (move to front, and dim all the other curves) / restore.
> >  - If X2 or Y2 axes are in use, then when you select a curve, it would
> >    be nice to have the corresponding axes automatically highlighted.
>
> What sort of user interface would this functionality use?
>
> Would it be possible to implement popup menus for all the interactive
> terminals?  
> svg - easy if you have already commited to using jscript or the like.
> wxt - there is an extension that allow this, but it is very crude
> x11 - not without pulling in some additional toolkit layer
> win - no idea
>
> Or perhaps we could add a clickable icon to each key entry?
> 1st click toggles off, 2nd click brings it back at dim/grey,
> 3rd click highlights, 4th click returns it to the original state

I like this concept of cycling among the choices with clicks (though I
think the first click should highlight).

> > I would also like a way to select a data point on the graph and
> > display information about it.  In particular:
> > 
> >  - The X, Y (Z, T, U, V) data value, with full precision (not
> >    transformed to integer screen coordinates then transformed back).
> >    Also DX and DY for errorbars graphs.
> > 
> >  - Where it came from (file name, line, index, line within index,
> >    etc.).  Useful for tracking down an outlier.
> > 
> > If there are several data points very close together (say, within an
> > eight pixel radius), I would like a way to cycle among them.

For drilling down to a particular data point, one could click at or
near it.  The software would scan the data points until finding one
within an N pixel radius, and pop up a window with data about that
point.  For the next click it would restart its scan where it left off
the last time, so all the nearby data points are eventually visited.

            - Jim Van Zandt

error "contradicting arguments"

[Ralf J. <jue...@cs...>]

Greetings,

When I do this

set style line 1 lt -1 lw 2
set style increment user
plot 'data.txt' with lines ls 1 lc rgb variable

gnuplot gives me an error:

  line 3: duplicated or contradicting arguments in plot options

Not sure why it generates an error, the user-defined linestyle
does not specify a color. Bug or feature?

Ralf

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

Re: brainstorming SVG_INTERACTIVE

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

Ethan A Merritt wrote:
> On Tuesday 30 December 2008, Ethan A Merritt wrote:
>> On Tuesday 30 December 2008, pl...@pi... wrote:
>>> Ethan A Merritt wrote:
>>>> On Tuesday 30 December 2008, pl...@pi... wrote:
>>>>> 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.
>>>>>
>>>>> gnuplot_svg_interactive.patch
>>>> Please upload it to the SourceForge site:
>>>>
>>>>    https://sourceforge.net/tracker/?group_id=2055&atid=302055
>>>>
>>> Patches item #2477391, was opened at 2008-12-30 17:29
>>> Message generated for change (Tracker Item Submitted) made by Item Submitter
>>> You can respond by visiting:
>>> https://sourceforge.net/tracker/?func=detail&atid=302055&aid=2477391&group_id=2055
>>>
>>>
>>> It probably needs tidying up a bit but could you make sure it applies
>>> OK? Made against currect CVS.
>>

> 
> 
> More comments:
> 
>  - "set key clickable" works, but the current setting needs to be reported by
>    "show key" and saved by save_set_all().
> 
>  - Coding style.  Please make new code conform to the surrounding coding style.
>    Rather than 
> 
>         /* Draw key text in black */
>         (*t->linetype)(LT_BLACK);
> +//*** add legend id and onclick
> +  if ( (key->clickable) && (term->set_id_click) ) (term->set_id_click) ("legend#","line#");
> 
>    Please use
> 
>         /* Draw key text in black */
>         (*t->linetype)(LT_BLACK);
> +       /* add legend id and onclick */
> +       if (key->clickable && (*t->set_id_click))
> +           (*t->set_id_click)("legend#", "line#");
> 
>  - Thinking out loud here ...
>    As I understand it, the curent patch associates the action specifically with
>    the text of the key title.  What if the plot has no title?
>    Maybe it would be better to associate the action with the rectangular block
>    that bounds the key title and associated key sample.  That would at least
>    hypothetically allow associated the action with an image-mapped *.png plot
>    in addition to the more obviously interactive terminal types.
Maybe adding a wrapper element would be useful if you want to add an
href but that was not the aim of this patch. Like I said this needs some
top down thinking before it expands, as it surely will.

The sample line is also active with this patch but you need to be a good
shot with the mouse. A larger target would be good.

> 
>  - I'd like to hear more suggestions or brainstorming about a generalized
>    framework.  This patch associates a specific action (toggle on/off) with
>    a click on the key title.  My earlier href patch associated a different
>    action (link to URL) with a click on the key title.  Another suggestion from
>    the first round of comments was to also allow the click to trigger various
>    other actions (highlight the plot, erase other plots, grey out the plot).
>    
>    All of these options sound reasonable, but it means that "set key clickable"
>    is not sufficient to specify the desired result.  OK, fine, we could make
>    that "set key click=toggle" or "set key click=URL".  But do we need a
>    new set of terminal entry points for each option, or can we share a single
>    entry that handles all of the various options that apply to that terminal?
> 
>    Maybe we need a structure that describes the desired actions, and a 
>    corresponding set of keywords to instantiate one.
> 
>    struct action {
> 	int type;    /* toggle, cycle, highlight, hyperlink, ... */
>         char *url;   /* NULL unless action type is hyperlink */
>         t_colorspec highlight_color;
>    }

I'd like to bring the function name onclick=toogleVisible out to a
string that could be "set". Your *url should be free to set anything.
This allows the user to add his own js functions in svg.js and link them
in this way.

This way he has the freedom to do window.parent.location="....." to
break out of frames or whatever. Or pop up an alert() with some info
about the plot. This is very powerful.

It also circumvents the problem of trying to code the <a></a> pair and
leave it dangling while diverse possible code paths happen and then hope
to close it again properly.


> 
>    struct legend_key {
> 	...
> 	struct action *action;
>    }
> 
>       # default action is to toggle the plot on/off
>         set key title action TOGGLE  
>       # but individual plots can do something else, 
>       # e.g. cycle grey/off/on/highlight 
>         plot foo title "foo" action cycle, 
>              baz title "baz" action link "file:///data/baz.dat" 
> 

Yes I like linking to the data.

The current two args are probably not enough but it shows the mechanism.
It probably needs :

id unique id , probably utilising plotno if in the plotting loop
event   [onclick , onmouseenter, ....]
action  [toggleVisibilty, other std, user defined]
target  [null,self,another id]

This shows a limitation on the 'set key' approach, how to define more
than one event handler (onclick , and onmouseover for coords)

set key event 1 onclick
set key action 1 togglevisiblity

??

The first arg will be simple an unique but the second is looking a lot
like a struct* to me. If this is not flexible each new idea is going to
change the code for all terminals.

I'll get back to cleaning up the patch.

regards.

Re: brainstorming SVG_INTERACTIVE

[Ethan A M. <merritt@u.washington.edu>]

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.


> > 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.

> 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.



-- 
Ethan A Merritt

Re: brainstorming SVG_INTERACTIVE

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

Ethan A Merritt wrote:
> On Tuesday 30 December 2008, pl...@pi... wrote:
>> Ethan A Merritt wrote:
>>> On Tuesday 30 December 2008, pl...@pi... wrote:
>>>> 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.
>>>>
>>>> gnuplot_svg_interactive.patch
>>> Please upload it to the SourceForge site:
>>>
>>>    https://sourceforge.net/tracker/?group_id=2055&atid=302055
>>>
>> Patches item #2477391, was opened at 2008-12-30 17:29
>> Message generated for change (Tracker Item Submitted) made by Item Submitter
>> You can respond by visiting:
>> https://sourceforge.net/tracker/?func=detail&atid=302055&aid=2477391&group_id=2055
>>
>>
>> It probably needs tidying up a bit but could you make sure it applies
>> OK? Made against currect CVS.
> 
> 
> First quick comments on the patch:
> 
> 1) Remove all the residual garbage in the patch file caused by comparing
>    the CVS "hidden" files in your own cvs setup.  As it stands, this patch
>    will not apply against anyone else's cvs tree.
> 
> 2) Conversely, the patch does not contain your new .../term/svg subdirectory.
>    For that you would need to include the -N switch in your "diff" command,
>    but it also means that you need to run it on a clean directory tree rather
>    than one that contains all the *.o files and modified CVS directories.
Oops, -auN .

> 
> 3) The patch contains some changes that I assume you made for local
>    convenience (e.g. removing the docs directory from the build dependencies).
>    Please remove these.
> 
> For these various reasons, it doesn't actually apply and "make" correctly.
> I attach a somewhat cleaner version of your patch, but obviously it still
> doesn't contain any of the missing files.
> 
> As to the code itself:
> 
> 1) Please no C++ style comments.  
>    Not everyone is using a C compiler that accepts them.
Check,

> 
> 2) Compilation produces the following error messages:

Well warnings. OK, I've cleaned them up.

> 
> In file included from term.h:368,
>                  from term.c:1368:
> ../term/svg.trm: In function ‘SVG_PathOpen’:
> ../term/svg.trm:257: warning: ISO C90 forbids mixed declarations and code
> ../term/svg.trm:261: warning: suggest parentheses around assignment used as truth value
> ../term/svg.trm:267: warning: suggest parentheses around assignment used as truth value
> ../term/svg.trm: In function ‘SVG_init’:
> ../term/svg.trm:752: warning: ISO C90 forbids mixed declarations and code
> ../term/svg.trm: In function ‘SVG_put_text’:
> ../term/svg.trm:1134: warning: suggest parentheses around assignment used as truth value
> ../term/svg.trm:1142: warning: suggest parentheses around assignment used as truth value
> 
> unset.c: In function ‘reset_key’:
> unset.c:864: warning: missing braces around initializer
> unset.c:864: warning: (near initialization for ‘temp_key.bounds’)
> 

Can't suss that last one...

> 
> 3) I don't get this "event handler" business.  
>    term_api.h:
> 	typedef struct  ext {
> 	  char *id;
> 	  char *event_handler;
> 	} ext ;
> 
>    This obviously is not an event handler in the normal unix sense of the term.
>    Please add a comment explaining exactly what it is, and how various terminal
>    drivers are supposed to use it.   
> 
>    Actaully, it doesn't seem to be used anywhere.
>    Is it a remnant from an earlier version?

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. In which case this is obselete.

> 
> 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.

> 
> 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.

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.

Thanks for your comments.

Peter.

Re: brainstorming SVG_INTERACTIVE

[Ethan A M. <merritt@u.washington.edu>]

On Tuesday 30 December 2008, Ethan A Merritt wrote:
> On Tuesday 30 December 2008, pl...@pi... wrote:
> > Ethan A Merritt wrote:
> > > On Tuesday 30 December 2008, pl...@pi... wrote:
> > >> 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.
> > >>
> > >> gnuplot_svg_interactive.patch
> > > 
> > > Please upload it to the SourceForge site:
> > > 
> > >    https://sourceforge.net/tracker/?group_id=2055&atid=302055
> > > 
> > 
> > Patches item #2477391, was opened at 2008-12-30 17:29
> > Message generated for change (Tracker Item Submitted) made by Item Submitter
> > You can respond by visiting:
> > https://sourceforge.net/tracker/?func=detail&atid=302055&aid=2477391&group_id=2055
> > 
> > 
> > It probably needs tidying up a bit but could you make sure it applies
> > OK? Made against currect CVS.
> 
> 
> First quick comments on the patch:
> 
> 1) Remove all the residual garbage in the patch file caused by comparing
>    the CVS "hidden" files in your own cvs setup.  As it stands, this patch
>    will not apply against anyone else's cvs tree.
> 
> 2) Conversely, the patch does not contain your new .../term/svg subdirectory.
>    For that you would need to include the -N switch in your "diff" command,
>    but it also means that you need to run it on a clean directory tree rather
>    than one that contains all the *.o files and modified CVS directories.
> 
> 3) The patch contains some changes that I assume you made for local
>    convenience (e.g. removing the docs directory from the build dependencies).
>    Please remove these.
> 
> For these various reasons, it doesn't actually apply and "make" correctly.
> I attach a somewhat cleaner version of your patch, but obviously it still
> doesn't contain any of the missing files.
> 
> As to the code itself:
> 
> 1) Please no C++ style comments.  
>    Not everyone is using a C compiler that accepts them.
> 
> 2) Compilation produces the following error messages:
> 
> In file included from term.h:368,
>                  from term.c:1368:
> ../term/svg.trm: In function ‘SVG_PathOpen’:
> ../term/svg.trm:257: warning: ISO C90 forbids mixed declarations and code
> ../term/svg.trm:261: warning: suggest parentheses around assignment used as truth value
> ../term/svg.trm:267: warning: suggest parentheses around assignment used as truth value
> ../term/svg.trm: In function ‘SVG_init’:
> ../term/svg.trm:752: warning: ISO C90 forbids mixed declarations and code
> ../term/svg.trm: In function ‘SVG_put_text’:
> ../term/svg.trm:1134: warning: suggest parentheses around assignment used as truth value
> ../term/svg.trm:1142: warning: suggest parentheses around assignment used as truth value
> 
> unset.c: In function ‘reset_key’:
> unset.c:864: warning: missing braces around initializer
> unset.c:864: warning: (near initialization for ‘temp_key.bounds’)
> 
> 
> 3) I don't get this "event handler" business.  
>    term_api.h:
> 	typedef struct  ext {
> 	  char *id;
> 	  char *event_handler;
> 	} ext ;
> 
>    This obviously is not an event handler in the normal unix sense of the term.
>    Please add a comment explaining exactly what it is, and how various terminal
>    drivers are supposed to use it.   
> 
>    Actaully, it doesn't seem to be used anywhere.
>    Is it a remnant from an earlier version?
> 
> 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?   
> 
> 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.


More comments:

 - "set key clickable" works, but the current setting needs to be reported by
   "show key" and saved by save_set_all().

 - Coding style.  Please make new code conform to the surrounding coding style.
   Rather than 

        /* Draw key text in black */
        (*t->linetype)(LT_BLACK);
+//*** add legend id and onclick
+  if ( (key->clickable) && (term->set_id_click) ) (term->set_id_click) ("legend#","line#");

   Please use

        /* Draw key text in black */
        (*t->linetype)(LT_BLACK);
+       /* add legend id and onclick */
+       if (key->clickable && (*t->set_id_click))
+           (*t->set_id_click)("legend#", "line#");

 - Thinking out loud here ...
   As I understand it, the curent patch associates the action specifically with
   the text of the key title.  What if the plot has no title?
   Maybe it would be better to associate the action with the rectangular block
   that bounds the key title and associated key sample.  That would at least
   hypothetically allow associated the action with an image-mapped *.png plot
   in addition to the more obviously interactive terminal types.

 - I'd like to hear more suggestions or brainstorming about a generalized
   framework.  This patch associates a specific action (toggle on/off) with
   a click on the key title.  My earlier href patch associated a different
   action (link to URL) with a click on the key title.  Another suggestion from
   the first round of comments was to also allow the click to trigger various
   other actions (highlight the plot, erase other plots, grey out the plot).
   
   All of these options sound reasonable, but it means that "set key clickable"
   is not sufficient to specify the desired result.  OK, fine, we could make
   that "set key click=toggle" or "set key click=URL".  But do we need a
   new set of terminal entry points for each option, or can we share a single
   entry that handles all of the various options that apply to that terminal?

   Maybe we need a structure that describes the desired actions, and a 
   corresponding set of keywords to instantiate one.

   struct action {
	int type;    /* toggle, cycle, highlight, hyperlink, ... */
        char *url;   /* NULL unless action type is hyperlink */
        t_colorspec highlight_color;
   }

   struct legend_key {
	...
	struct action *action;
   }

      # default action is to toggle the plot on/off
        set key title action TOGGLE  
      # but individual plots can do something else, 
      # e.g. cycle grey/off/on/highlight 
        plot foo title "foo" action cycle, 
             baz title "baz" action link "file:///data/baz.dat" 



-- 
Ethan A Merritt

Re: brainstorming SVG_INTERACTIVE

[Ethan A M. <merritt@u.washington.edu>]

On Tuesday 30 December 2008, pl...@pi... wrote:
> Ethan A Merritt wrote:
> > On Tuesday 30 December 2008, pl...@pi... wrote:
> >> 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.
> >>
> >> gnuplot_svg_interactive.patch
> > 
> > Please upload it to the SourceForge site:
> > 
> >    https://sourceforge.net/tracker/?group_id=2055&atid=302055
> > 
> 
> Patches item #2477391, was opened at 2008-12-30 17:29
> Message generated for change (Tracker Item Submitted) made by Item Submitter
> You can respond by visiting:
> https://sourceforge.net/tracker/?func=detail&atid=302055&aid=2477391&group_id=2055
> 
> 
> It probably needs tidying up a bit but could you make sure it applies
> OK? Made against currect CVS.


First quick comments on the patch:

1) Remove all the residual garbage in the patch file caused by comparing
   the CVS "hidden" files in your own cvs setup.  As it stands, this patch
   will not apply against anyone else's cvs tree.

2) Conversely, the patch does not contain your new .../term/svg subdirectory.
   For that you would need to include the -N switch in your "diff" command,
   but it also means that you need to run it on a clean directory tree rather
   than one that contains all the *.o files and modified CVS directories.

3) The patch contains some changes that I assume you made for local
   convenience (e.g. removing the docs directory from the build dependencies).
   Please remove these.

For these various reasons, it doesn't actually apply and "make" correctly.
I attach a somewhat cleaner version of your patch, but obviously it still
doesn't contain any of the missing files.

As to the code itself:

1) Please no C++ style comments.  
   Not everyone is using a C compiler that accepts them.

2) Compilation produces the following error messages:

In file included from term.h:368,
                 from term.c:1368:
../term/svg.trm: In function ‘SVG_PathOpen’:
../term/svg.trm:257: warning: ISO C90 forbids mixed declarations and code
../term/svg.trm:261: warning: suggest parentheses around assignment used as truth value
../term/svg.trm:267: warning: suggest parentheses around assignment used as truth value
../term/svg.trm: In function ‘SVG_init’:
../term/svg.trm:752: warning: ISO C90 forbids mixed declarations and code
../term/svg.trm: In function ‘SVG_put_text’:
../term/svg.trm:1134: warning: suggest parentheses around assignment used as truth value
../term/svg.trm:1142: warning: suggest parentheses around assignment used as truth value

unset.c: In function ‘reset_key’:
unset.c:864: warning: missing braces around initializer
unset.c:864: warning: (near initialization for ‘temp_key.bounds’)


3) I don't get this "event handler" business.  
   term_api.h:
	typedef struct  ext {
	  char *id;
	  char *event_handler;
	} ext ;

   This obviously is not an event handler in the normal unix sense of the term.
   Please add a comment explaining exactly what it is, and how various terminal
   drivers are supposed to use it.   

   Actaully, it doesn't seem to be used anywhere.
   Is it a remnant from an earlier version?

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?   

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.


-- 
Ethan A Merritt

Re: brainstorming SVG_INTERACTIVE

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

Ethan A Merritt wrote:
> On Tuesday 30 December 2008, pl...@pi... wrote:
>> 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.
>>
>> gnuplot_svg_interactive.patch
> 
> Please upload it to the SourceForge site:
> 
>    https://sourceforge.net/tracker/?group_id=2055&atid=302055
> 

Patches item #2477391, was opened at 2008-12-30 17:29
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=302055&aid=2477391&group_id=2055


It probably needs tidying up a bit but could you make sure it applies
OK? Made against currect CVS.

Thanks.

Re: brainstorming SVG_INTERACTIVE

[Ethan A M. <merritt@u.washington.edu>]

On Tuesday 30 December 2008, pl...@pi... wrote:
> 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.
> 
> gnuplot_svg_interactive.patch

Please upload it to the SourceForge site:

   https://sourceforge.net/tracker/?group_id=2055&atid=302055

-- 
Ethan A Merritt

Re: brainstorming SVG_INTERACTIVE

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

pl...@pi... wrote:
> 
> 
> 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.
> 
> 
> 

Another nice feature would be a draggable legend (equally valid for
other interactives).

I would also like to see cross-hairs on svg. That would be a great help
in the absence of coordinate display. This is all going t lead to a
desire for a toolbar like the wxt terminal. That would be attainable by
adding a floating box via js.


/Peter.

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.

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.

Re: brainstorming SVG_INTERACTIVE

[Ethan A M. <merritt@u.washington.edu>]

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? 

> 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.

> 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.

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: problem with "set x11 {size WW,HH} {position XX,YY}"

[Daniel J S. <dan...@ie...>]

Ethan A Merritt wrote:
> On Monday 29 December 2008, Daniel J Sebald wrote:
> 
> 
>> Some work was done on retaining plotting data for all plots but I 
>> think it is only in experimental stage right now.  Such a feature 
>> would enable Octave to not require opening a new version of gnuplot
>>  for every new Octave plot.  Also, my guess is that gnuplot would
>> be able to handle multiplot more robustly with data retention.
>> There is a bit of work on both sides of the exchange to do that 
>> integration.
> 
> 
> I was under the impression that Octave started using that new feature
>  the moment gnuplot started supporting it.  Is that not the case?

I'm guessing not because I hadn't heard discussion on the Octave list.
(Then again, I missed about a year of Octave discussion.)  Petr may
have followed this more closely than I have.

Dan

Re: problem with "set x11 {size WW,HH} {position XX,YY}"

[Ethan A M. <merritt@u.washington.edu>]

On Monday 29 December 2008, Daniel J Sebald wrote:

> Some work was done on retaining plotting data for all plots but I think it is only in experimental stage right now.  Such a feature would enable Octave to not require opening a new version of gnuplot for every new Octave plot.  Also, my guess is that gnuplot would be able to handle multiplot more robustly with data retention.  There is a bit of work on both sides of the exchange to do that integration.

I was under the impression that Octave started using that new feature the moment
gnuplot started supporting it.  Is that not the case?

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742