Hi, On Sat, Mar 22, 2008 at 6:49 AM, Cameron McCormack <[EMAIL PROTECTED]> wrote: > > > I would like to request public API access to the > > org.apache.batik.anim.timing.TimedElement. > > I agree it would be useful to expose animation engine information from > the document. I'm not sure what the ideal API would be, though. >
Same here I also do not know the ideal API, currently I am still experiment with various access to the underlying SVG Timing model (based on Batik) to model a SVG Animation Editor. As you already know, something is better hidden eg: TimingSpecifier has public initialize()/deinitialize() since it is should not be called by the external application. see the inline comment for more detail. Side Note: If you might be interested, I develop the SVG Animation Editor is under Apache License 2.0, so it might interest to be included in Batik as well (no legal issues, since it is also Apache License 2.0), however there are some technical issue, some part is quite tight with Sketsa. However as for now I could separate the implementation in - Timeline component is stand alone component that only interact with Batik, no sketsa dependency - Sketsa wrapper layer (this has sketsa dependency) Please visit the url below for more info http://blogs.kiyut.com/tonny/2007/12/06/svg-animation-editor-feedback/ > > > After briefly studying Batik code base, I think by simple doing the > > following will expose public TimedElement > > > > - in org.apache.batik.dom.svg.SVGOMAnimationElement provide > > * public SVGAnimationContext getSVGAnimationContext() { > > return ((SVGAnimationContext) getSVGContext()) > > } > > > > - in org.apache.batik.dom.svg.SVGAnimationContext provide > > * public TimedElement getTimedElement(); > > > > - in org.apache.batik.bridge.SVGAnimationElementBridge already provide > > the above getTimedElement() > > Given that SVGAnimationElementBridge already exposes the TimedElement > through that method, I think we don't need to add the first two methods > you propose. You can just do, for example: > > SVGOMAnimateElement e = …; > TimedElement te = > (SVGAnimationElementBridge) e.getSVGContext()).getTimedElement(); Yup, your above code should be fine (finally I could get access to the Timed Element :) However, I would much prefer, if possible the Bridge stuff is not exposed (IMHO this should be deeper down in layer) through package import. SVGOM.. stuff probably fine (although if possible it is also eliminated as well), but I think SVGOM.. is not possible to be elimated because SVG API does not provide enough public API. > I suspect that in the end you'll need some more complex interface to the > animation engine (e.g. registering listeners for changes to the > timegraph, begin/end instance times being created/removed, etc.). Yup you are correct, finally there will be a need for more public interface to the animation engine. But currently I think I can deal by listening to the DOM mutation event > I am a little reluctant to make the existing classes more "public", > since they're not really designed for applications to use. For example, > TimingSpecifier has public initialize()/deinitialize() methods, which > are really just for use by TimedElement. > > But if you don't mind the interface possibly changing later, and if you > promise not to call initialize(), I can add these methods. :-) Yup, I think it is fine to change the interface later for better suited model. I am thinking about exposing the public API as much as permissable, so people could experiment with the stuff first, and by experimenting I think people could finally thinking about better interface/framework/library. I believe in get access to the things first, experiment, then the experience could be used to develop better interface. And get access is better than no access at all. Just make sure, put the javadoc comment to indicate that this/that methods is volatile and should not be called and will change/deprecated, And I will not call initiallze() method :) Cheers Tonny Kohar -- Sketsa SVG Editor imagine, design, create ... http://www.kiyut.com
