|
|
Boost : |
From: Stjepan Rajko (stipe_at_[hidden])
Date: 2007-08-10 01:18:01
On 8/9/07, Jake Voytko <jakevoytko_at_[hidden]> wrote:
> Stjepan,
>
> Thank you for taking the time to review this library! Let me know when
> yours is in a stable state, and I'll respond in kind.
>
Feel free to take a look anytime you like. I am currently churning
the concepts in my head and it will take a while before I stabilize
the next iteration of the code/docs :-) The last post with an update
is:
> >
> > * From the Colors docs:
> >
> > "The list contains one extra color element, blank, used when you need
> > to pass a color, but would not like it to show up. This comes in handy
> > for defining defaults for functions, for example."
> >
> > I don't understand this. What do you mean by "would not like it to
> > show up?" The element whose color you are specifying should not show
> > up?
>
> SVG is cascading, in the CSS sense. If we have the following SVG fragment:
>
> <g fill="red">
> <g>
> <rect x="5" y="50" width="490" height="295"/>
> </g>
> </g>
>
> the rectangle produced will have a red fill. If you would like the
> rectangle to simply be a frame, you can provide the color "blank", and
> be written as the following:
>
> <g fill="red">
> <g>
> <rect x="5" y="50" width="490" height="295" fill="none"/>
> </g>
> </g>
>
>
> and it will appear as a rectangular frame. This will be made clearer
> in the documentation.
>
OK I see. If you wanted the color to be completely unspecified (as in
the former snippet), is there an "inherit" element? (perhaps that is
not needed for svg_plot though...)
> >
> > * From the x and y axis documentation:
> >
> > "For an alternate way to display a regular axis, you can use an external style:"
> >
> > What is an external style?
>
> http://tinyurl.com/2vzp2o [tcnj.edu]
>
> I will provide an example in 2D as well.
>
Ahh!!! lol - It took me forever to notice that the difference is that
the axis went to the bottom of the figure! I just thought they went
missing, and didn't get what the point was :-) Saying something like
"the external style will place the axis on the border of the figure"
(or whatever the appropriate correct explanation is) might be helpful
for other imperceptive individuals like me.
> >
> > * About customizing the plot
> >
> > It first struck me as odd that some drawing parameters are specified
> > through the plot object, and some at plotting time (.plot method).
> > Then I realized that it is because there are common "plot" elements -
> > axis, title, background, etc., and then there are elements that are
> > common to each range "plot" - area fill, bezier, line color...
> >
> > First thing - how can we disambiguate between "plot" as "the whole
> > shabang" / with options describing common supporting elements (axis,
> > title, ...), and "plot" as what is visualizing a single range (drawn
> > via .plot())?
>
> One of my ideas for post-GSoC was to try to group similar style
> methods using Boost.Parameter:
>
> my_plot.x_axis_style( width = 2, color = red, position = left)
> .legend_style( font_size = 15, background_color = lightgray);
>
> To me, this helps the user understand at a glance what is happening,
> as well as allowing for some clarity as to what sections are being
> affected. I wasn't sure that I was going to go this route, but the
> more I look at it, the better a solution it appears to be. My only
> concern is that this is very non-standard syntax, but OTOH it's
> already accepted into Boost, so on average, the community has accepted
> this. This should help a little with the first part of your concern.
>
That is indeed very easy to understand. I like the fact that it
nicely groups the related attributes.
> However, the definition of series styles should be done at the time
> the series is entered into the plot, IMO. Users are much less likely
> to define colors for the wrong series if they do it when they call
> plot(). Changing the name of the plot function to something like
> draw_series could help, but I also think that brief familiarity of the
> library (plus differentiating plot as a noun and plot as a verb) makes
> this a non-issue.
>
You are right, it makes sense to specify the format while plotting the
series. In fact, even specifying the data to be plotted can almost be
regarded as an attribute of the plot, so a call to .plot is kind of
like any other attribute setting member function (and that makes the
syntax proposed above for specifying other elements very consistent
with plotting, which is nice). As far as nomenclature goes, perhaps
one big image where you clearly indicate the name of every element
would be a good reference for a user that is learning the library.
If you decide to change .plot, consider something like
.add_series_plot or add_range_plot or whatever - "add" so it is clear
that you are adding it, and "series" or "range" (or whatever) so it is
clear what you are adding. That way, if you decide later that you
want to provide support for plotting something else, you can also
have, say, add_function_plot, or add_range_run_plot, or whatever...
> >
> > Second - specifying the line / area fill characteristics (only) at
> > .plot() invocation seems to have a drawback. Suppose that I want to
> > create a large number of .SVGs, out of the same data but all in
> > different styles. So I create the plot in the first style, and output
> > it to a file. Now I want to change the style for the second file.
> > For the background elements, i can just change them by invoking the
> > appropriate methods. But for the .plots? There seems to be no
> > mechanism for me to go in and change the style of a plot drawn with
> > .plot(). So, I have to recreate each plot from scratch. Maybe an
> > avenue for this will be added when you allow for the use of external
> > stylesheets? Or maybe you will cover it as a part of "avoiding having
> > to redraw the entire plot each time".
>
> You don't have to redo the *entire* graph from scratch, but yes, there
> is currently no way to modify the style of a series that is already
> stored. The stylesheet method could be a potential solution to this,
> if I allow the user to define class and ID names at .plot()
> invocation.
>
> Something like the following is also possible:
>
> my_plot.series(3).style().fill_color(black).stroke_color(white);
>
That would do it.
> >
> > * The defaults tables docs
> >
> > The two tables have a huge overlap - could they be condensed into one
> > table? There could be two columns, describing the setting for each
> > scenario (1d/2d). if something has the same default value for both,
> > it can span both columns, otherwise you can list different values in
> > each column or say "N/A" in one of the columns.
>
> I will have to play around with it and see what looks better from the
> viewpoint of looking up information. IMO, the biggest use of a table
> like you mention is to do feature comparisons. When I use reference
> documents, it is purely a lookup function. If a user is looking for
> data on a 1D plot, they don't need to have information about 2D plots
> in front of them.. it's just extra noise, as far as the person is
> concerned. They are performing purely a lookup task.
>
> This gets even more difficult when differentiating between the 1D and
> 2D plot() features, as they both use Boost.Parameter, and to different
> ends. I would either have separate sections that still have redundant
> information, or I would have to try to take extra care to not confuse
> the user between options available in 1D and 2D (which is a concern I
> have, since named parameters are relatively unheard of outside of
> Boost).
Valid point.
>
> > Also, it would be nice to cross-reference this with the functions that
> > change the values.
>
> I don't understand what you mean.
>
When looking up a default value for an attribute, I might be
immediately interested in what member function is used to change it,
and vice versa. So, providing a conveniently located link to the
member function from the default value, and vice versa, might be
useful.
> >[snip]
> >
> > I didn't look into the reasons for the errors much. Simple fix?
>
> So simple that they've already been fixed :). You must have downloaded
> the library at a bad time, because I think the errors were only in the
> SVN repository for 30 minutes or so.
>
:-) It works now, thanks for the quick fix. I'll let you know how
the psfrag thing goes!
Best regards,
Stjepan
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk