On Tue, 2004-06-08 at 20:30, Bryce Harrington wrote:
[some changing control value] -|
when the graph is complete you press play and watch.
I already know about the concept SVG animations, however I cannot rely on them since the animation speed is fixed (eg : I want to be able to, say, rotate a box at a speed that is a sinusoidal wave, not constant). This kinda clashes with my concept of animation, but anyway... So what I want to do is animate with API calls like
setRotationAngle(MyBox, sin(time) ) (or myBox.setRotationAngle..... )
If you're not familiar with the SVG DOM (http://www.w3.org/TR/SVG11/svgdom.html) I think that's basically what you want. (though the interface for many things is not so simple)
We don't implement any W3C DOM yet.
- am I correct when I assume inkscape already has all the API calls I'm
looking for ?
It does have calls for performing manipulations like this, yes, but it would not really be honest to describe them as API's. There is no interface document, nor ways to easily access the calls external from Inkscape. So unfortunately the best answer would be, "No, not without a lot of digging..."
There is some of this, but the APIs we inherited from Sodipodi require a lot of direct manipulation of textual attributes, and we are only slowly adding more convenient interfaces on top ourselves.
- how is the internal representation of the graphical objects organised
? As an XML document would be ? A tree?
Yes, and in fact this internal representation is one of the codebases' very interesting features. It is implemented as a DOM 'repr' that contains everything in an object tree, including attributes and references. It's quite sophisticated and powerful. There is some documentation about this but not nearly as much as one would need.
Any given SVG object is represented by three classes:
SPRepr (xml syntax) ["backing store" as XML data]
SPObject (SVG semantics) [cache for efficient editing/rendering]
NRArenaItem (simple renderable object) [one per view]
- how to strip the GUI part from the core of inkscape ?
Mental and Nathan have tried stripping the GUI part off of it once before; they'd be the best to answer this. As I understand it, there is not a sufficiently clean separation between the interface and the renderer to make this trivial, but it did not sound impossible.
It really depends on how much of Inkscape he wants. I think the entire SPObject/SPDocument layer, SPRepr layer, libnr/libnrtype, inkscape-livarot, and NRArena layer can be extracted together _relatively_ cleanly.
(though I've not tried it)
Trying to extract smaller pieces would likely prove very difficult.
Also be aware that our internal APIs are currently under heavy flux, and will probably continue to be until version ~0.9 or so.
- when inkscape moves to cairo for rendering, will it use glitz ? if
not, why so?
I don't know; Mental might know, but to be honest we haven't dug very far into investigating Cairo yet. If you choose to use Cairo we'd be very interested in hearing about your experiences with it.
I would like us to use cairo with glitz someday if we could. Neither it nor our own code is mature enough yet to attempt it, however. Hardware acceleration (could) be a big win.
For now we're probably best off using our own renderer (which seems to be fast enough for most users), until we implement the complete set of rendering features required by SVG (notably things like filter effects). system.
-mental