| 2 | | This is the central repository for design and implementation considerations for this project. If you have any suggestions or comments, either leave them here or email me at jakevoytko [at] gmail [dot] com[[BR]] |
| | 2 | This project is focused on using STL containers in order to graph data on a two dimensional (and if time allows, three dimensional!) plot. The graph would be written in an `svg` image, compliant with the W3C standard. The goals of the project are as follows: |
| | 3 | |
| | 4 | * To provide an easy syntax for building graphs |
| | 5 | * To let users produce a simple graph with minimal intervention by using sane defaults |
| | 6 | * To demonstrate how to incorporate SVG images into Boost documentation |
| | 7 | * To allow users to easily customize graphs to their heart's content |
| | 8 | * To allow the user to talk with the `svg_graph` class using coordinate units instead of pixels or other arbitrary measures |
| | 9 | |
| | 10 | I have only a student's grasp of C++, so if you have a suggestion to help me with design or implementation, either leave them here or email me at jakevoytko [at] gmail [dot] com[[BR]] |
| 38 | | === Private default constructor === |
| 39 | | I'm making the default constructor private simply because I can not think of a reasonable default for the class to have. I'd bet good money that having the data output to the console was not what the user wanted! Guessing a default file could potentially be disasterous: if we don't overwrite an already existing file, all of the user's efforts would be for naught. If we overwrite an existing file, we could overwrite something the user would have preferred to keep. As a result, I find it reasonable to expect the user to specify a stream when they create the svg object, in keeping with Scott Meyer's suggestion that incorrect use of the interface should not compile. |
| | 49 | * `plot_range(std::vector<double>::iterator, std::vector<double>::iterator)` |
| | 50 | * Will be the made generic |
| | 51 | * Allows the user to input a begin and an end, and have the user plot the data in between |
| 41 | | === To be continued... === |
| | 53 | * `draw_axis()` |
| | 54 | * The user specifies that s/he would like the axis drawn in the image. |
| | 55 | |
| | 56 | '' '''Inherited from `svg`'''. I am only including the ones it makes sense to include. In the current prototype code, it inherits handling for a few functions that are not only illogical, but produce unexpected results! This will be taken care of. |
| | 57 | |
| | 58 | * `write()` |
| | 59 | * Since it would be too much work (and sometimes impossible) to maintain the file without intervention, this function acts as a 'commit'. |
| | 60 | * The user can be sure that whenever they have executed this command, the full output is written to the stream they have specified. |
| | 61 | |
| | 62 | * `line_color(svg_color c)` |
| | 63 | * Allows users to define a color |
| | 64 | * `line_point()` will soon be supported |
| | 65 | * Users will be able to define custom colors soon |
| | 66 | |
| | 67 | == 2.2 `svg` Class == |
| | 68 | All of the design decisions for the `svg` class are motivated by the fact that the `svg` class is the parent for the `svg_graph` class. As such, I tend to treat it as a second-class citizen. My personal tendency is to make it purely a computation and drawing class, and leave all interface work to the `svg_graph` class |
| | 69 | |
| | 70 | When I designed the prototype, I made the svg class have a user interface much in the way that the svg_graph class does with the stream operator. However, as I look at the list of features that I'd like the user to be able to access, I will consider the ramifications of removing a user interface for the svg portion, and instead focus it on being the functional backbone of the svg_graph class. I will post to the Boost discussion board and see if people are more interested in eventually having a fully-functioning SVG suite, or more interested in having a fully-functioning graphing utility in the near future. |
