xmlgraphics-batik-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cameron McCormack <...@mcc.id.au>
Subject Re: Request public API to TimedElement
Date Wed, 26 Mar 2008 04:51:48 GMT
Tonny Kohar:
> 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.

Oh, nice!

> 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/

Cool.  One of our Summer of Code students last year started working on
an animation viewer/editor interface for Batik, but it didn’t get beyond
preliminary stages.

It is in the patch attached to
https://issues.apache.org/bugzilla/show_bug.cgi?id=42741; you may or may
not find it useful for ideas about design or the document animation
information interface.

Anyway, of course it’d be awesome if your animation visualising
component could be integrated into Batik.  I think it would be a nice
debugging tool to have, in addition to the DOM Viewer window.

> 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.

Yeah, probably you are right.  But for now I’ve gone the easy route and
only added those two methods (getBeginInstanceTimes() and
getEndInstanceTimes()) on to TimedElement.

> 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.

Sure, good idea.

> 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,

Have done.

> And I will not call initiallze() method :)



Cameron McCormack, http://mcc.id.au/
	xmpp:heycam@jabber.org  ▪  ICQ 26955922  ▪  MSN cam@mcc.id.au

To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org

View raw message