Boost logo

Boost :

From: Paul A Bristow (pbristow_at_[hidden])
Date: 2007-05-16 05:42:25


>-----Original Message-----
>From: boost-bounces_at_[hidden]
>[mailto:boost-bounces_at_[hidden]] On Behalf Of John Maddock
>Sent: 16 May 2007 08:56
>To: boost_at_[hidden]
>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 A Bristow
Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB
+44 1539561830 & SMS, Mobile +44 7714 330204 & SMS

Boost list run by bdawes at, gregod at, cpdaniel at, john at