Re: more svg animation updates.

--===============0364589211297554156==
Content-Type: multipart/alternative; boundary="0000000000000de94e05a629934e"

--0000000000000de94e05a629934e
Content-Type: text/plain; charset="UTF-8"

Hi Jeff! You should try https://chat.inkscape.org

You can follow up on replies that were made when you were offline.

Regards,
Abhay

On Thu, May 21, 2020, 7:42 PM NASA Jeff <[email protected]> wrote:

> 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.*
>>
> _______________________________________________
> Inkscape-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>

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

<div dir=3D"auto">Hi Jeff! You should try <a href=3D"https://chat.inkscape.=
org">https://chat.inkscape.org</a>=C2=A0<div dir=3D"auto"><br></div><div di=
r=3D"auto">You can follow up on replies that were made when you were offlin=
e.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Regards,</div><div di=
r=3D"auto">Abhay</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr"=
 class=3D"gmail_attr">On Thu, May 21, 2020, 7:42 PM NASA Jeff &lt;<a href=
=3D"mailto:[email protected]">[email protected]</a>&gt; wrote:<br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">updated hypothetical roa=
d map foir=C2=A0the javascript path, I&#39;ll also use this as the basis fo=
r a road map for the SIML path, which 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 breakdown<br><br>my current proposal to impl=
ement=C2=A0SVG animation is as follows (i expect this list isn&#39;t exhaus=
tive 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 implementin=
g animation before SIDL isn&#39;t possible due to lack of support from Micr=
osoft and plans to drop support by google.(there is now a shim to do this s=
o it&#39;s no longer an issue)<br>css seems a bit limiting,=C2=A0especially=
 for those hardcore flash fanboy=C2=A0animators that have been begging for =
animation to be implemented.<br>leaving us with javascript which is feature=
 rich and allowing people to hand-edit javascript in inkscape has to be con=
sidered but there is an alternative of only allowing editing through the GU=
I and making the javascript read-only. It remains to be seen how common a p=
roblem complex or bizarre javascript usage is, if it&#39;s detectable then =
inkscapes animation features can be turned off selectively preventing any a=
ttempts at interpreting the meaning of the javascript. inkscape then just r=
everse to an SVG editor for the files in question<br>there is a hypothetica=
l 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=C2=A0v=
ia import routines.<br><br>a javascript implementation allows the animation=
 to be implemented in <span>phases</span>, the first=C2=A0<span>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]=
" target=3D"_blank" rel=3D"noreferrer">[email protected]</a>&gt; wrote:<=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"=
>I didn&#39;t=C2=A0manage=C2=A0to catch up wiith=C2=A0anyone=C2=A0on irc ye=
t, and i only managed=C2=A0to catch up with the scribes team 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 will begin implem=
enting the PDF import routines in Inkscape internal with Scribus, this is m=
y first mini project to do and after growing through the code it doesn&#39;=
t appear it should take too long unless there&#39;s major issues implementi=
ng multipage/full document import.<br><br>after this, I&#39;m free to spend=
 the majority of the considerable amount of free time i have on Inkscape..<=
br><br>sorry I repeat the same thing a couple of times in a couple of place=
s because I added a couple of paragraphs that added background that the rea=
der may not be familiar with or remembered.<br><br>=C2=A0I&#39;ve been thin=
king some more about the best way to implement SVG animation and=C2=A0I wou=
ld also include=C2=A0+UI as in makes sense to implement some interactive fe=
atures that would allow the SVG files to be used too create user interfaces=
 for games and apps, though actually creating games and apps insider Inksca=
pe is out of scope so a full flash feature set won&#39;t be available witho=
ut third-party apps.=C2=A0=C2=A0<br><br><br>my current proposal to implemen=
t=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 implementing anim=
ation 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=A0espe=
cially for those hardcore flash fanboy=C2=A0animators that have been beggin=
g for animation to be implemented.<br>leaving us with javascript which is f=
eature rich and if animations readonly and the feature set reduced should b=
e no more difficult to pull the element numbers from than CSS would as both=
 would need custom parsers as they are not xml.<br><br>a javascript impleme=
ntation allows the animation to be implemented in two phases, the first pha=
se 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 java=
script macros, I make various arguments bellow including cost-effectiveness=
.<br><div><br>aside=C2=A0from hooking up a javascript=C2=A0engine within In=
kscape=C2=A0an API for Inkscape&#39;s functionality is also required to all=
ow=C2=A0javascript and Inkscape to interact. My current plan goes along the=
 lines of hickaking inkscapes undo/redo features and extending and generali=
zing them so that when a macro is set to be recorded a call to add somethin=
g onto the undo stack writes the equivalent=C2=A0of a redo to the macro fil=
e buffer.<br><br>why bother implementing javascript powered macros?<br>a ja=
vascript engine would have to be integrated into inkscape for it to efficie=
ntly support anyway<br>trigers=C2=A0on 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.<br>a macro engine allows for relat=
ively easy testing that hooks are in place, the API is correct, the javascr=
ipt engine is properly integrated etc...<br>it also makes it possible to te=
st that animation features are working correctly even if the 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 allows for the im=
plementation and testing to be done in two phases.<br>it makes 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 code editor also nee=
ds to be implemented, but <i>I wouldn&#39;t=C2=A0go beyond the basics other=
wise people may be tempted to=C2=A0write=C2=A0apps in inkscsape.<br><br>at =
the same time as doing this I intended to write a guide to implementing mac=
ro 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 th=
is so that others are encouraged to add this kind of functionality to appli=
cations 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 mac=
ros, calls to append to the undo buffer should now additionally update the =
values at keyframes<br><br>Inkscapes user interface needs to be extended to=
 add any animation-related data, this should update undo which will then po=
pulate the relative animation setting in the animation script.<br><br><br>a=
 timeline navigator with support for keyframes and layers needs to be creat=
ed<br>the ability to go to any frame, step through and preview play SVG fil=
es and their animation needs to be added.<br><br><br>javascript used for an=
imation should have a restricted set of javascript functionality. it should=
 be viewable but read-only. I would allow it to be extended using scripts w=
ith a predefined interface, these scripts should be editable but only allow=
 for a reduced set of javascript functionality. they are there to make scri=
pt extendable and customizable and to implement features that inkscape does=
n&#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 anima=
tion values into the gui where they can then be edited and updated.<br><br>=
<br><br><br><br><br><br></i></div></div></div>
</blockquote></div>
_______________________________________________<br>
Inkscape-devel mailing list<br>
<a href=3D"mailto:[email protected]" target=3D"_blank" r=
el=3D"noreferrer">[email protected]</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/inkscape-devel" rel=
=3D"noreferrer noreferrer" target=3D"_blank">https://lists.sourceforge.net/=
lists/listinfo/inkscape-devel</a><br>
</blockquote></div>

--0000000000000de94e05a629934e--


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


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

--===============0364589211297554156==--