Re: more svg animation updates.

--===============8701131493933164505==
Content-Type: multipart/alternative; boundary="00000000000095836405a6291551"

--00000000000095836405a6291551
Content-Type: text/plain; charset="UTF-8"

updated hypothetical road map foir the javascript path, I'll also use this
as the basis for a road map for the SIML path, which I'll send shortly

reading thought it it wasn't the flour phase plan I put together prev just
some basic ideas and a breakdown

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.(there is now a shim to do this so it's no longer
an issue)
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 allowing people to
hand-edit javascript in inkscape has to be considered but there is an
alternative of only allowing editing through the GUI and making the
javascript read-only. It remains to be seen how common a problem complex or
bizarre javascript usage is, if it's detectable then inkscapes animation
features can be turned off selectively preventing any attempts at
interpreting the meaning of the javascript. inkscape then just reverse to
an SVG editor for the files in question
there is a hypothetical risk of viruses being spread by svg files that
implement javascript but I think this can be mitigated against by limiting
the exposure of the hosts API and potentially which lists for what to allow
javascript to load via import routines.

a javascript implementation allows the animation to be implemented in 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. I expect that the API shim can be generated via a script keeping
the task accurate and timely. I've not reviewed Inkscape's codebase to see
if this is a possibility.

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. security fort macros and svg would require than the
javascript engine can  isolate running macros and running svg
the next phase is loading svg files and parsing the javascript to extract
positioning and animation information from it, the user interface also
needs to be extended sot hat values can be read and written
following on from the there is a requirement of creating new javascript via
the GUI and updating/replacing the existing script

the next phase requires that the javascript is hooked up to the objects on
the canvas enabling them to be animated


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.the final phase is a 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.animation parameters need to be, get, set and updated for
the keyframesfake smile could then be used to implement SIML on top of the
already written javascript implementation, * SIML would have to be parsed
and integrated into the GUI



*finally with all in place and tested a CSS implementation can be
compleated.one of the benefits of this implementation is that javascript
engines already exist and are well tested so complex parsers and
interpreters don't have to be created, * fake smile  exists and is well
tested it could be used to implement  SIML on top of javascript keeping
the number of implementations down  and limiting bugs etc...  it should
also be a lot faster than a standalone  SIML  implementation. There are
also libraries available and tested that implement SVG animation via
javascript


On Sat, 16 May 2020 at 03:01, NASA Jeff <[email protected]> wrote:

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

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

<div dir=3D"ltr">updated hypothetical road map foir=C2=A0the javascript pat=
h, I&#39;ll also use this as the basis for a road map for the SIML path, wh=
ich I&#39;ll send shortly<br><br>reading thought it it wasn&#39;t the flour=
 phase=C2=A0plan I put together prev=C2=A0just some basic ideas and a break=
down<br><br>my current proposal to implement=C2=A0SVG animation is as follo=
ws (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 implementing animation before SIDL isn&#39;t poss=
ible due to lack of support from Microsoft and plans to drop support by goo=
gle.(there is now a shim to do this so it&#39;s no longer an issue)<br>css =
seems a bit limiting,=C2=A0especially for those hardcore flash fanboy=C2=A0=
animators that have been begging for animation to be implemented.<br>leavin=
g us with javascript which is feature rich and allowing people to hand-edit=
 javascript in inkscape has to be considered but there is an alternative of=
 only allowing editing through the GUI and making the javascript read-only.=
 It remains to be seen how common a problem complex or bizarre javascript u=
sage is, if it&#39;s detectable then inkscapes animation features can be tu=
rned off selectively preventing any attempts at interpreting the meaning of=
 the javascript. inkscape then just reverse to an SVG editor for the files =
in question<br>there is a hypothetical risk of viruses being spread by svg =
files that implement javascript but I think this can be mitigated against b=
y limiting the exposure of the hosts API and potentially which lists for wh=
at to allow javascript to load=C2=A0via import routines.<br><br>a javascrip=
t implementation allows the animation to be implemented in <span class=3D"g=
mail-il">phases</span>, the first=C2=A0<span class=3D"gmail-il">phase</span=
>=C2=A0is to implement the javascript engine and ensure all the relevant ho=
oks are in place and an inkscape API for javascript has been created. I exp=
ect that the API shim can be generated via a script keeping the task accura=
te and timely. I&#39;ve not reviewed Inkscape&#39;s codebase to see if this=
 is a possibility.<br><br>it makes sense at this time to slightly extend th=
e feature set so as to support javascript macros, I make various arguments =
bellow including cost-effectiveness. security=C2=A0fort macros and svg woul=
d require than the javascript engine can=C2=A0 isolate running macros and r=
unning svg<br><div>the next phase is loading svg files and parsing the java=
script to extract positioning and animation information from it, the user i=
nterface also needs to be extended sot hat values can be read and written<b=
r>following on from the there is a requirement of creating new javascript v=
ia the GUI and updating/replacing the existing script<br><br>the next phase=
 requires that the javascript is hooked up to the objects on the canvas ena=
bling them to be animated<br><br><div><br>a simple code editor also needs t=
o be implemented, but=C2=A0<i>I wouldn&#39;t=C2=A0go beyond the basics othe=
rwise people may be tempted to=C2=A0write=C2=A0apps in inkscsape.<br><br>th=
e final phase is a a timeline navigator with support for keyframes and laye=
rs needs to be created<br>the ability to go to any frame, step through and =
preview play SVG files and their animation needs to be added.<br>animation =
parameters need to be, get, set and updated for the keyframes<br><br>fake s=
mile could then be used to implement SIML=C2=A0on top=C2=A0of the already w=
ritten javascript implementation,=C2=A0</i>

SIML would have to be parsed and integrated=C2=A0into the GUI=C2=A0=C2=A0<b=
r><i><br>finally with all in place and tested a CSS implementation can be c=
ompleated.<br><br>one of the benefits of this implementation is that javasc=
ript engines already exist and are well tested so complex parsers and inter=
preters don&#39;t have to be created,=C2=A0</i>

fake smile=C2=A0 exists=C2=A0and is well tested it could be used to impleme=
nt=C2=A0

SIML=C2=A0on top=C2=A0of javascript keeping=C2=A0 the number of implementat=
ions down=C2=A0

and limiting bugs etc...=C2=A0 it should also be a lot faster than a standa=
lone=C2=A0

SIML=C2=A0 implementation. There are also libraries available and tested th=
at implement SVG animation via javascript<i><br><br></i></div></div></div><=
br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat,=
 16 May 2020 at 03:01, NASA Jeff &lt;<a href=3D"mailto:[email protected]=
">[email protected]</a>&gt; wrote:<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex"><div dir=3D"ltr">I didn&#39;t=C2=A0manage=C2=A0to cat=
ch up wiith=C2=A0anyone=C2=A0on irc yet, and i only managed=C2=A0to catch u=
p with the scribes team tonight as my irc client was buggy. short of a prog=
ramming task I&#39;;ve been working on my psychology project.<br><br>hopefu=
lly, any day soon, I will begin implementing the PDF import routines in Ink=
scape internal with Scribus, this is my first mini project to do and after =
growing through the code it doesn&#39;t appear it should take too long unle=
ss there&#39;s major issues implementing multipage/full document import.<br=
><br>after this, I&#39;m free to spend the majority of the considerable amo=
unt of free time i have 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 paragra=
phs that added background that the reader may not be familiar with or remem=
bered.<br><br>=C2=A0I&#39;ve been thinking some more about the best way to =
implement SVG animation and=C2=A0I would also include=C2=A0+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 fe=
ature set won&#39;t be available without third-party apps.=C2=A0=C2=A0<br><=
br><br>my current proposal to implement=C2=A0SVG animation is as follows (i=
 expect this list isn&#39;t exhaustive but I feel I have the majority of th=
e critical components listed)=C2=A0=C2=A0<br><br>as I went through the list=
 of possible ways of implementing 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 limiting,=C2=A0especially for those hardcore flash fanbo=
y=C2=A0animators that have been begging for animation to be implemented.<br=
>leaving us with javascript which is feature rich and if animations readonl=
y and the feature set reduced should be no more difficult to pull the eleme=
nt numbers from than CSS would as both would need custom parsers as they ar=
e not xml.<br><br>a javascript implementation allows the animation to be im=
plemented in two phases, the first phase is to implement the javascript eng=
ine 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 argumen=
ts bellow including cost-effectiveness.<br><div><br>aside=C2=A0from hooking=
 up a javascript=C2=A0engine within Inkscape=C2=A0an API for Inkscape&#39;s=
 functionality is also required to allow=C2=A0javascript and Inkscape to in=
teract. My current plan goes along the lines of hickaking inkscapes undo/re=
do 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 equi=
valent=C2=A0of a redo to the macro file buffer.<br><br>why bother implement=
ing javascript powered macros?<br>a javascript engine would have to be inte=
grated into inkscape for it to efficiently support anyway<br>trigers=C2=A0o=
n updates would have to be extended so as to write values to keyframes anyw=
ay, it is fairly trivial to write out a line in a macro file at the same ti=
me.<br>a macro engine allows for relatively easy testing that hooks are in =
place, the API is correct, the javascript engine is properly integrated etc=
...<br>it also makes it possible to test that animation features are workin=
g correctly even if the UI hasn&#39;t been fully implemented.<br>it&#39;s n=
ot a major job so why not most of the functionality would be needed for ani=
mation anyway and it allows for the implementation and testing to be done i=
n two phases.<br>it makes testing and=C2=A0debugging much easier and will p=
robably=C2=A0save=C2=A0more time and headaches than it cost to create.<br><=
div><br>a simple code editor also needs to be implemented, but <i>I wouldn&=
#39;t=C2=A0go beyond the basics otherwise people may be tempted to=C2=A0wri=
te=C2=A0apps in inkscsape.<br><br>at the same time as doing this I intended=
 to write a guide to implementing macro engines in computer software with u=
ndo 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 ad=
d this kind of functionality to applications once they realize that it&#39;=
s relatively straight 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 animation not for macros, calls to append to the undo buffe=
r should now additionally update the values at keyframes<br><br>Inkscapes u=
ser 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.<br><br><br>a timeline navigator with support for k=
eyframes and layers needs to be created<br>the ability to go to any frame, =
step through and preview play SVG files and their animation needs to be add=
ed.<br><br><br>javascript used for animation should have a restricted set o=
f javascript functionality. it should be viewable but read-only. I would al=
low it to be extended using scripts with a predefined interface, these scri=
pts should be editable but only allow for a reduced set of javascript funct=
ionality. they are there to make script extendable and customizable and to =
implement features that inkscape doesn&#39;t implement for whatever reason.=
<br><br><br><br>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 ca=
n then be edited and updated.<br><br><br><br><br><br><br><br></i></div></di=
v></div>
</blockquote></div>

--00000000000095836405a6291551--


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


--===============8701131493933164505==
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

--===============8701131493933164505==--