more svg animation updates.

--===============1108044805099376300==
Content-Type: multipart/alternative; boundary="0000000000005bcc6e05a5ba50f1"

--0000000000005bcc6e05a5ba50f1
Content-Type: text/plain; charset="UTF-8"

I didn't manage to catch up wiith anyone on irc yet, and i only managed to
catch up with the scribes team tonight as my irc client was buggy. short of
a programming task I';ve been working on my psychology project.

hopefully, any day soon, I will begin implementing the PDF import routines
in Inkscape internal with Scribus, this is my first mini project to do and
after growing through the code it doesn't appear it should take too long
unless there's major issues implementing multipage/full document import.

after this, I'm free to spend the majority of the considerable amount of
free time i have on Inkscape..

sorry I repeat the same thing a couple of times in a couple of places
because I added a couple of paragraphs that added background that the
reader may not be familiar with or remembered.

 I've been thinking some more about the best way to implement SVG animation
and I would also include +UI as in makes sense to implement some
interactive features that would allow the SVG files to be used too create
user interfaces for games and apps, though actually creating games and apps
insider Inkscape is out of scope so a full flash feature set won't be
available without third-party apps.


my current proposal to implement SVG animation is as follows (i expect this
list isn't exhaustive but I feel I have the majority of the critical
components listed)

as I went through the list of possible ways of implementing animation
before SIDL isn't possible due to lack of support from Microsoft and plans
to drop support by google.
css seems a bit limiting, especially for those hardcore flash
fanboy animators that have been begging for animation to be implemented.
leaving us with javascript which is feature rich and if animations readonly
and the feature set reduced should be no more difficult to pull the element
numbers from than CSS would as both would need custom parsers as they are
not xml.

a javascript implementation allows the animation to be implemented in two
phases, the first phase is to implement the javascript engine and ensure
all the relevant hooks are in place and an inkscape API for javascript has
been created. it makes sense at this time to slightly extend the feature
set so as to support javascript macros, I make various arguments bellow
including cost-effectiveness.

aside from hooking up a javascript engine within Inkscape an API for
Inkscape's functionality is also required to allow javascript and Inkscape
to interact. My current plan goes along the lines of hickaking inkscapes
undo/redo features and extending and generalizing them so that when a macro
is set to be recorded a call to add something onto the undo stack writes
the equivalent of a redo to the macro file buffer.

why bother implementing javascript powered macros?
a javascript engine would have to be integrated into inkscape for it to
efficiently support anyway
trigers on updates would have to be extended so as to write values to
keyframes anyway, it is fairly trivial to write out a line in a macro file
at the same time.
a macro engine allows for relatively easy testing that hooks are in place,
the API is correct, the javascript engine is properly integrated etc...
it also makes it possible to test that animation features are working
correctly even if the UI hasn't been fully implemented.
it's not a major job so why not most of the functionality would be needed
for animation anyway and it allows for the implementation and testing to be
done in two phases.
it makes testing and debugging much easier and will probably save more time
and headaches than it cost to create.

a simple code editor also needs to be implemented, but


























*I wouldn't go beyond the basics otherwise people may be tempted
to write apps in inkscsape.at the same time as doing this I intended to
write a guide to implementing macro engines in computer software with undo
redo support. maybe with a nicely packaged up javascript engine and API
starter kit. it makes sense to do this so that others are encouraged to add
this kind of functionality to applications once they realize that it's
relatively straight forward and not as complicated as one may think.undo
redo hooks need to be extended again but this time to write javascript for
animation not for macros, calls to append to the undo buffer should now
additionally update the values at keyframesInkscapes user interface needs
to be extended to add any animation-related data, this should update undo
which will then populate the relative animation setting in the animation
script.a timeline navigator with support for keyframes and layers needs to
be createdthe ability to go to any frame, step through and preview play SVG
files and their animation needs to be added.javascript used for animation
should have a restricted set of javascript functionality. it should be
viewable but read-only. I would allow it to be extended using scripts with
a predefined interface, these scripts should be editable but only allow for
a reduced set of javascript functionality. they are there to make script
extendable and customizable and to implement features that inkscape doesn't
implement for whatever reason.a parser needs to be created to scrape the
relevant bits of javascript so as to import the animation values into the
gui where they can then be edited and updated.*

--0000000000005bcc6e05a5ba50f1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I didn&#39;t=C2=A0manage=C2=A0to catch up wiith=C2=A0anyon=
e=C2=A0on irc yet, and i only managed=C2=A0to catch up with the scribes tea=
m tonight as my irc client was buggy. short of a programming task I&#39;;ve=
 been working on my psychology project.<br><br>hopefully, any day soon, I w=
ill begin implementing the PDF import routines in Inkscape internal with Sc=
ribus, this is my first mini project to do and after growing through the co=
de it doesn&#39;t appear it should take too long unless there&#39;s major i=
ssues implementing multipage/full document import.<br><br>after this, I&#39=
;m free to spend the majority of the considerable amount of free time i hav=
e on Inkscape..<br><br>sorry I repeat the same thing a couple of times in a=
 couple of places because I added a couple of paragraphs that added backgro=
und that the reader may not be familiar with or remembered.<br><br>=C2=A0I&=
#39;ve been thinking some more about the best way to implement SVG animatio=
n and=C2=A0I would also include=C2=A0+UI as in makes sense to implement som=
e interactive features that would allow the SVG files to be used too create=
 user interfaces for games and apps, though actually creating games and app=
s insider Inkscape is out of scope so a full flash feature set won&#39;t be=
 available without third-party apps.=C2=A0=C2=A0<br><br><br>my current prop=
osal to implement=C2=A0SVG animation is as follows (i expect this list isn&=
#39;t exhaustive but I feel I have the majority of the critical components =
listed)=C2=A0=C2=A0<br><br>as I went through the list of possible ways of i=
mplementing animation before SIDL isn&#39;t possible due to lack of support=
 from Microsoft and plans to drop support by google.<br>css seems a bit lim=
iting,=C2=A0especially for those hardcore flash fanboy=C2=A0animators that =
have been begging for animation to be implemented.<br>leaving us with javas=
cript which is feature rich and if animations readonly and the feature set =
reduced should be no more difficult to pull the element numbers from than C=
SS would as both would need custom parsers as they are not xml.<br><br>a ja=
vascript implementation allows the animation to be implemented in two phase=
s, the first phase is to implement the javascript engine and ensure all the=
 relevant hooks are in place and an inkscape API for javascript has been cr=
eated. it makes sense at this time to slightly extend the feature set so as=
 to support javascript macros, I make various arguments bellow including co=
st-effectiveness.<br><div><br>aside=C2=A0from hooking up a javascript=C2=A0=
engine within Inkscape=C2=A0an API for Inkscape&#39;s functionality is also=
 required to allow=C2=A0javascript and Inkscape to interact. My current pla=
n goes along the lines of hickaking inkscapes undo/redo features and extend=
ing and generalizing them so that when a macro is set to be recorded a call=
 to add something onto the undo stack writes the equivalent=C2=A0of a redo =
to the macro file buffer.<br><br>why bother implementing javascript powered=
 macros?<br>a javascript engine would have to be integrated into inkscape f=
or it to efficiently support anyway<br>trigers=C2=A0on updates would have t=
o be extended so as to write values to keyframes anyway, it is fairly trivi=
al to write out a line in a macro file at the same time.<br>a macro engine =
allows for relatively easy testing that hooks are in place, the API is corr=
ect, the javascript engine is properly integrated etc...<br>it also makes i=
t possible to test that animation features are working correctly even if th=
e UI hasn&#39;t been fully implemented.<br>it&#39;s not a major job so why =
not most of the functionality would be needed for animation anyway and it a=
llows for the implementation and testing to be done in two phases.<br>it ma=
kes testing and=C2=A0debugging much easier and will probably=C2=A0save=C2=
=A0more time and headaches than it cost to create.<br><div><br>a simple cod=
e editor also needs to be implemented, but <i>I wouldn&#39;t=C2=A0go beyond=
 the basics otherwise people may be tempted to=C2=A0write=C2=A0apps in inks=
csape.<br><br>at the same time as doing this I intended to write a guide to=
 implementing macro engines in computer software with undo redo support. ma=
ybe with a nicely packaged up javascript engine and API starter kit. it mak=
es sense to do this so that others are encouraged to add this kind of funct=
ionality to applications once they realize that it&#39;s relatively straigh=
t forward and not as complicated as one may think.<br><br><br><br>undo redo=
 hooks need to be extended again but this time to write javascript for anim=
ation not for macros, calls to append to the undo buffer should now additio=
nally update the values at keyframes<br><br>Inkscapes user interface needs =
to be extended to add any animation-related data, this should update undo w=
hich will then populate the relative animation setting in the animation scr=
ipt.<br><br><br>a timeline navigator with support for keyframes and layers =
needs to be created<br>the ability to go to any frame, step through and pre=
view play SVG files and their animation needs to be added.<br><br><br>javas=
cript used for animation should have a restricted set of javascript functio=
nality. it should be viewable but read-only. I would allow it to be extende=
d using scripts with a predefined interface, these scripts should be editab=
le but only allow for a reduced set of javascript functionality. they are t=
here to make script extendable and customizable and to implement features t=
hat inkscape doesn&#39;t implement for whatever reason.<br><br><br><br>a pa=
rser needs to be created to scrape the relevant bits of javascript so as to=
 import the animation values into the gui where they can then be edited and=
 updated.<br><br><br><br><br><br><br><br></i></div></div></div>

--0000000000005bcc6e05a5ba50f1--


--===============1108044805099376300==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--===============1108044805099376300==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Inkscape-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

--===============1108044805099376300==--