Hi Mr Nasa,
The regular developer meeting happen every eight days (so the next one is Sep 17th) usually at 7pmCEST (we can be flexible on the time but that one (same as board meetings) allows participation from the widest range of timezones where we have contributors (from california to india)) - we have a calendar at https://inkscape.org/cals/event/1/ .
I remember talking at length with you about animations on IRC/rocketchat with, in particular, the following message:
"While I'm not opposed to animation in Inkscape there are few things that make me doubtful it could be done reasonably in the short term (I know @doctormo warned you of people like me :p ) : 1/ A crucial requirement of any javascript engine integrated in Inkscape would be that it SHOULD be completely stripped of any networking. No XHR, no WS, nothing. Inkscape is present but not prominently featured in CVE lists, and if possible that should stay the case. Honestly I'd *much* prefer SMIL for several reasons : (a) it's much safer (it's harder to implement remote exploitation vulnerabilities as all it can do is animation), (b) it's simpler to read ! the <animate> tags can be understood from the svg code, (c) as weird as it could seem, it's better supported by browsers. javascript in embedded svg <img> linked images will never be loaded, so for js the only way you can get animated images is in direct <svg> tags of images, while for smil you could integrate and link them (and all modern browsers support it). 2/ The change in UI should be vetted by our ui team and if possible tested on users, before being pushed. 3/ I don't see (in the current state of things) how you will (or how you *could*) do rendering. For complex images (with text and filters) we're already at <1fps for still images, so I don't know how you could achieve a comfortable (realtime) preview of animated images. We do have plans to move the rendering to the gpu, but that will only make matters worse if you plan to have the cpu computing changes, you will need to upload all the svg changes at 60fps to the gpu and it will need to be really well optimized to look decent"
I don't think the situation has changed much since this message: In my opinion, Javascript engines are a can of worms that we will not want anywhere near and will lead to expectations like if we say we support js, then people will just embed jquery, vue, and d3js and either complain that it does not run, or shoot themselves in the foot by opening crafted files; maintaining a version of an existing js engine with features like network and local file access disabled might be hard; and already just implementing DOM in Inkscape first might also be a big task in itself. CSS3 animations are imo probably fine (and would be good to investigate), but might be weaker than SMIL and harder to read, parse, and execute.
If you're 100% sure that the javascript route is the only way, then the next best thing would be to develop it as an Inkscape plugin so that it would be optionally loaded (which is quite easy to do, and would resonate with your idea of "lightweight/fullyfledged" in a more modular way) - we have an example one in src/extension/plugins/grid2/ but it can be used to do almost anything in the program.
On the topic of scribus/pdf, I really think we could gain a lot with more closely using Scribus pdf code and your improvements to it, as pdf import (and export!) is always something tricky and has problems in Inkscape. AFAIK there is no Scribus "library" that we could use (or compare to poppler), but that would be well worth investigating!
Anyway, we'll see you at the dev meeting so that we can discuss these topics again, maybe more in depth, I'd be happy to be convinced that something could make Inkscape more useful to all :)
Do you already have a WIP merge request pending for either of the topics? (to understand how you envisioned things code-wise)