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