Starting today, I'll be working on a new Inkscape::AST module, which will eventually replace the current SPRepr subsystem.
The goal is to reduce the complexity of the XML code, while allowing for e.g. CSS and SVG path data to be manipulated in the same tree, in broken-down form (rather than as monolithic strings).
libxml will still be used for parsing XML data, and hopefully we will be able to start using libcroco for CSS data as well.
The new XML editor will also use the AST code, and it in turn will serve as a basis for the Layers dialog UI.
Questions are welcome.
-mental
Sounds cool, this could bring some much needed enhancements to the core of the codebase. Can you update the roadmap to reflect how you plan to do it? A wiki page would also be nice for keeping folks clued in on the design.
Bryce
On Sun, 29 Feb 2004, MenTaLguY wrote:
Starting today, I'll be working on a new Inkscape::AST module, which will eventually replace the current SPRepr subsystem.
The goal is to reduce the complexity of the XML code, while allowing for e.g. CSS and SVG path data to be manipulated in the same tree, in broken-down form (rather than as monolithic strings).
libxml will still be used for parsing XML data, and hopefully we will be able to start using libcroco for CSS data as well.
The new XML editor will also use the AST code, and it in turn will serve as a basis for the Layers dialog UI.
Questions are welcome.
-mental
On Sun, 2004-02-29 at 20:25, MenTaLguY wrote:
The new XML editor will also use the AST code, and it in turn will serve as a basis for the Layers dialog UI.
So there's no dice with looking towards Conglomerate as the XML editor in the long term? ;)
On Sun, 2004-02-29 at 19:25, Charles Goodwin wrote:
So there's no dice with looking towards Conglomerate as the XML editor in the long term? ;)
That depends entirely on how flexible Conglomerate can be about the underlying tree representation, or whether it's possible to write adaptor classes it can use.
In any case I think it'd be appropriate to have a (minimal) XML editor built in to cover the case where Conglomerate isn't installed.
-mental
MenTaLguY wrote:
Starting today, I'll be working on a new Inkscape::AST module, which will eventually replace the current SPRepr subsystem.
The goal is to reduce the complexity of the XML code, while allowing for e.g. CSS and SVG path data to be manipulated in the same tree, in broken-down form (rather than as monolithic strings).
libxml will still be used for parsing XML data, and hopefully we will be able to start using libcroco for CSS data as well.
The new XML editor will also use the AST code, and it in turn will serve as a basis for the Layers dialog UI.
Questions are welcome.
-mental
Yaay. I think this might actually be something I have been needing!
I know that W3 DOM is overkill, and too messy for our purposes, but please keep in mind the ability to access this tree via a DOM -model-.
I was looking over what I have been contributing recently, and it occurred to me that I have made absolutely no progress toward the one feature I actually need --- SVG XPath accessibility and scripting via ECMAscript. When I can finally do this:
svg.scene.forest.tree[x].branch[y].bird.color=blue;
...and the rendering shows this, then I will be happy!
For my day job, drawings and schematics that can be animated and manipulated at runtime programatically are the goal I seek. Since I am not a professional artist, having the program merely be a drawing tool holds no attraction for me.
Bob
participants (4)
-
Bob Jamison -
Bryce Harrington -
Charles Goodwin -
MenTaLguY