From: John Maddock (john_at_[hidden])
Date: 2007-05-16 03:56:04
> 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk