I'm working on the Summer of Code project "Visualization of STL Containers", the goal of which is to create 2D graphs of data stored in STL containers. (For more details, see the Trac link at the bottom of the email) The basic organization of the code is a "svg" class for working directly in the SVG format, and a "svg_graph" class that inherits from "svg" that the user uses as an interface. My current predicament is the design of the "svg" class itself. My personal view of the "svg" class was simply that it separates the handling of the svg document from the handling of the graphing logic. This was the way I designed the rapid prototype, and ostensibly, it worked. In my head, the "svg" class could technically be implemented without any external interface for users, and exist as a worker class. However, this doesn't seem at all ideal from a long-term planning perspective. I want to know if people would want me to spend some of the time of this project making the "svg" class act as a stand-alone (yet not fully implemented, obviously) SVG solution. Should it have a proper user interface? Should it be extensible to a full-blown SVG solution in the future? More specifically, are people looking for both a SVG manipulating class *AND* a way to graph STL data? There were suggestions of even treating the "svg" class as manipulating a document as per the DOM standard, which is indeed possible, but would require a complete overhaul of my current design, which I set up my current design in order to make optimizations on space and speed in the future. I see the obvious long term benefits of this method, but I question the benefit to the current project. I only have a finite amount of time in which to complete this, and it seems like it would take away from the stated goal. However, I'd be more than glad to implement a DOM if there were clamorous demand for this feature! Thank you for your time Jake Voytko Link to wiki on the project: http://svn.boost.org/trac/boost/wiki/soc/2007/VisualizationOfContainers
My current predicament is the design of the "svg" class itself. My personal view of the "svg" class was simply that it separates the handling of the svg document from the handling of the graphing logic. This was the way I designed the rapid prototype, and ostensibly, it worked. In my head, the "svg" class could technically be implemented without any external interface for users, and exist as a worker class.
However, this doesn't seem at all ideal from a long-term planning perspective. I want to know if people would want me to spend some of the time of this project making the "svg" class act as a stand-alone (yet not fully implemented, obviously) SVG solution. Should it have a proper user interface? Should it be extensible to a full-blown SVG solution in the future? More specifically, are people looking for both a SVG manipulating class *AND* a way to graph STL data?
From a personal perspective, yes please :-)
There were suggestions of even treating the "svg" class as manipulating a document as per the DOM standard, which is indeed possible, but would require a complete overhaul of my current design, which I set up my current design in order to make optimizations on space and speed in the future. I see the obvious long term benefits of this method, but I question the benefit to the current project. I only have a finite amount of time in which to complete this, and it seems like it would take away from the stated goal. However, I'd be more than glad to implement a DOM if there were clamorous demand for this feature!
My gut feeling is to keep it simple at this stage: make the svg class "write only" so we can use it to create basic diagrams, but can't open/modify existing ones. I don't want to distract you too much from your core aims of visualising data - and a fully fledged DOM is probably unrealistic within the timeframe anyway - but it seems a shame to have this class, and not have it useable at a user-level. HTH, John.
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of John Maddock Sent: 16 May 2007 08:56 To: boost@lists.boost.org Subject: Re: [boost] [GSoC 07] Visualizing STL
My current predicament is the design of the "svg" class itself. My personal view of the "svg" class was simply that it separates the handling of the svg document from the handling of the graphing logic. This was the way I designed the rapid prototype, and ostensibly, it worked. In my head, the "svg" class could technically be implemented without any external interface for users, and exist as a worker class.
However, this doesn't seem at all ideal from a long-term planning perspective. I want to know if people would want me to spend some of the time of this project making the "svg" class act as a stand-alone (yet not fully implemented, obviously) SVG solution. Should it have a proper user interface? Should it be extensible to a full-blown SVG solution in the future? More specifically, are people looking for both a SVG manipulating class *AND* a way to graph STL data?
From a personal perspective, yes please :-)
There were suggestions of even treating the "svg" class as manipulating a document as per the DOM standard, which is indeed possible, but would require a complete overhaul of my current design, which I set up my current design in order to make optimizations on space and speed in the future. I see the obvious long term benefits of this method, but I question the benefit to the current project. I only have a finite amount of time in which to complete this, and it seems like it would take away from the stated goal. However, I'd be more than glad to implement a DOM if there were clamorous demand for this feature!
My gut feeling is to keep it simple at this stage: make the svg class "write only" so we can use it to create basic diagrams, but can't open/modify existing ones. I don't want to distract you too much from your core aims of visualising data - and a fully fledged DOM is probably unrealistic within the timeframe anyway - but it seems a shame to have this class, and not have it useable at a user-level.
I agree with John's (usually unerring) instinct on this. Although SVG is being used for other fancy pictorial graphic jobs, I suspect there are good tools that output SVG already, and they have a head start. So although it would have been sensible to start off by writing an SVG DOM class, and using C++ to write the graphics tools, I fear the best moment may have already passed. So I would put the priority on getting some simple graphing tools - for which there is a pressing and unfulfilled need. I'm sure a proper SVG DOM would be a fun project - next years GSoC? ;-)) But I'm sure you'll have an eye on this and try not to 'design it out' as a future development (even if it is a bit back-to-front). Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
Paul wrote:
I agree with John's (usually unerring) instinct on this.
Although SVG is being used for other fancy pictorial graphic jobs, I suspect there are good tools that output SVG already, and they have a head start.
So although it would have been sensible to start off by writing an SVG DOM class, and using C++ to write the graphics tools, I fear the best moment may have already passed.
So I would put the priority on getting some simple graphing tools - for which there is a pressing and unfulfilled need.
I agree with the general sentiment that it'd be a shame to have all of the work go into a SVG class and not have it usable and extensible by a more generic crowd. The way I see it, giving it no treatment would require no effort, giving it an interface similar to the SVG_GRAPH class would require a little effort, but not inordinate, and treating the issue properly (DOM support, full SVG suite base) would take *quite* a bit of time, given the timeframe. If the demand's there, I'll spend more time working on the SVG side of things, but in my discussions in the past, as well as this thread, it seems like the *real* need is for graphing ability. In the intervening weeks between now and the start of the coding portion of GSoC, I'll toy around with a few different ideas I have and see which one I feel is reasonable
I'm sure a proper SVG DOM would be a fun project - next years GSoC? ;-))
Or potentially a side-project for me following GSoC ;) Jake
Jake wrote:
I want to know if people would want me to spend some of the time of this project making the "svg" class act as a stand-alone (yet not fully implemented, obviously) SVG solution.
I would appreciate a smart, concise way to format XML output. Maybe some operator-overloading would help? Whether or not this would be useful to you in this project, may I encourage other readers to suggest how it could be done? And no I don't want an implementation of the standard DOM: it is much too verbose. Here's a completely fabricated example. To generate: <rootnode name="r"> <subthing>Hello</subthing> <subthing>World</subthing> </rootnode> how about: cout << node("rootnode")( attribute("name","r"), node("subthing")(text("Hello")), node("subthing")(text("World")) ); Phil.
On 5/16/07, Phil Endecott <spam_from_boost_dev@chezphil.org> wrote:
Jake wrote:
Here's a completely fabricated example. To generate:
<rootnode name="r"> <subthing>Hello</subthing> <subthing>World</subthing> </rootnode>
how about:
cout << node("rootnode")( attribute("name","r"), node("subthing")(text("Hello")), node("subthing")(text("World")) );
I've used this syntax in the past: rootnode(name = "r") [ subthing(text = "Hello"), subthing(text = "World") ]; Not for XML output, but for general static info that is in a hierarchy, and modeled somewhat after XML. You could also do: rootnode(name = "r", foo = 17) where the attributes were not strings (could be anything that rootnode 'accepts') etc. it requires pre 'building' the magic elements and attributes: struct RootNode { RootNode(string s); void Set(Foo foo); void AddChild(...); }; // rootnode is an element corresponding to RootNode // when attributes are passed to rootnode, it will construct a RootNode with those attributes // that correspond to the constructor, and call Set for the rest element<RootNode> rootnode; attribute<Foo> foo; the rootnode(...) call doesn't have to create and return a RootNode, but that's the default. The sub elements get added to the RootNode via AddChild. If the attribute type doesn't match the Set(s) type, it doesn't compile. If the child element type doesn't match the AddChild function(s), it doesn't compile. Creating elements and adding children, however, were just the default Policies, you could do whatever. So maybe it could be made to output XML. Anyhow, I just want to mention that interesting syntax like that IS possible. (although it wasn't simple...) Tony
participants (5)
-
Gottlob Frege -
Jake Voytko -
John Maddock -
Paul A Bristow -
Phil Endecott