On 8/9/07, Jake Voytko <jakevoytko@gmail.com> 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: http://tinyurl.com/32la7r
* 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