Introducing SVG animation templates

[nbedos]

I'm currently adding support for SVG templates. Basically a template is a skeleton SVG file where termtosvg will embed the animation it produces. Templates make it possible to add a window frame to the animation, or to add custom Javascript code to control the animation (think play, pause, seek...).

Here's an example of an animation rendered with a template : https://cdn.rawgit.com/nbedos/termtosvg/43a7d461fa7eef86207759515cfe7d8f8897b48a/examples/awesome_js.svg

Usage is as simple as termtosvg --template my_template where my_template refers to a SVG file located in ~/.config/termtosvg/templates.

I have a question and a request:
Question: What templates would you like to see included in termtosvg? Right now I'm thinking:

1. A plain template. No decoration, no JS, nothing. With this template termtosvg will produce the same animations as it does today without template.
2. Pure SVG to add a window frame terminal (see here)
3. Same as 2. but with animation controls written in Javascript (play, pause, timeline). That's the example I've linked to just before.

Any other ideas? Maybe some neat terminal UI you'd like to see included?

Request: I suck at Javascript, so I'd be grateful if someone could review the script portion of this file.

Thanks!

Pinging @ylmrx @styfle @marcelo477 @leonklingele @knktc @vuuv @kaushalmodi @andyone @Earnestly @PetterS @zac-garby @bjd2385 @stevepeak

[styfle]

I'd be grateful if someone could review the script portion of

I think you can avoid using getAttribute and setAttribute and simply use the property, for example: element.display = 'hidden'

Is there a PR that I can add comments on each line?

[nbedos]

Is there a PR that I can add comments on each line?

Thanks for taking a look. Yes, I've just created #54

[Earnestly]

Usage is as simple as termtosvg --template my_template where my_template refers to a SVG file located in ~/.config/termtosvg/templates.

Prefer to not hardcode locations, even if they're backed by environments like XDG_CONFIG_HOME. There's little reason --template cannot simply take a file.

I wouldn't even hardcode any templates whatsoever in the code. termtosvg should only need to understand --template. Even having a configuration file seems overkill.

Otherwise this sounds like a great simple and general solution.

[nbedos]

I wouldn't even hardcode any templates whatsoever in the code. termtosvg should only need to understand --template. Even having a configuration file seems overkill.

I would like to provide something that just works. Currently (well, the code is in the feature/animation_UI branch for now) termtosvg creates ~/.config/termtosvg/templates if it does not exist and copies a few default templates in this directory. The user can then modify them as they wish. Without a default templates directory, if the user wishes to create a template themselves they would have to get a template either in the Python package or in the git repo themselves. Having a default template directory just seemed the most user friendly solution.

That's also why color themes are included in the configuration file: You get a bunch of color themes so that you can pick one and easily alter it if needed.

Would you rather not have a default configuration directory for termtosvg and provide the theme and template yourself?

[Earnestly]

Would you rather not have a default configuration directory for termtosvg and provide the theme and template yourself?

Yeah, I think having --template depend on a file path is a much more simple solution (requiring the least code) than using predefined directory structures where there appears to be no need for such a coupling.

The usual way this problem is solved is to have the project (typically) provide a $datarootdir/termtosvg/ containing various examples and useful files. See afl or git for an example of this.

I'm not entirely convinced a simple tool like this needs to bloat itself with "just works" features (which often don't "just work" in my experience due to the additional failure points the complexity brings). Personally termtosvg is such a breath of fresh air specifically because it is not asciinema.

Edit: termtosvg already provides a --theme flag so I don't see why a configuration file is needed. I can understand the temptation I urge you to resist it as termtosvg is not large enough to warrant it (which is a wonderful position to be in). The only additional thing I would suggest is providing a manual page.

PS: In my experience user-friendly ideals tend to become the most anti-user approaches in the long run because it hijacks their agency to find solutions via unintended means. See http://contemporary-home-computing.org/turing-complete-user/

[nbedos]

Thanks for the thoughtful reply and the interesting essay!

The usual way this problem is solved is to have the project (typically) provide a $datarootdir/termtosvg/ containing various examples and useful files. See afl or git for an example of this.

Yes, placing templates in a location such as /usr/share/termtosvg or ~/.local/share/termtosvg would be ideal. I'm not sure this can be (or should be) done with a Python package though.

Edit: termtosvg already provides a --theme flag so I don't see why a configuration file is needed.

You're right, the configuration file does not seem to be that useful and I could probably remove it. Now that termtosvg works with templates I'm thinking that I could also replace themes by CSS classes defined inside the template. The --font option could also be replaced by something similar. It only makes sense to bring the styling options back in the <style> tag of the template.

The only additional thing I would suggest is providing a manual page.

Agreed!

[Earnestly]

Yes, placing templates in a location such as /usr/share/termtosvg [...] I'm not sure this can be (or should be) done with a Python package though.

The placement of these files would usually be done as part of distribution packaging.

[nbedos]

I've just released version 0.5.0. Hope you'll enjoy it!

• Release notes
• Manual page
• Gallery of examples
• Gallery of default templates

[PetterS]

Cool!

[Earnestly]

Nicely done, the loss of dependencies like svgwrite is very welcome, imo. I'm not sure what you're going to do with the manuals but I've converted termtosvg.md to groff here: https://ptpb.pw/3cri

(I have also done it in mandoc here, but I wouldn't recommend mandoc. You might as well just use a proper semantic mark up if you choose that path.)

[nbedos]

Nicely done, the loss of dependencies like svgwrite is very welcome, imo.

I agree, and lxml is much better suited to my needs anyway.

I'm not sure what you're going to do with the manuals but I've converted termtosvg.md to groff here: https://ptpb.pw/3cri

Thanks, I'll include this page! I'll try to convert temtosvg-template.md too. At first I wanted to use Sphinx to get the manual pages in both groff and HTML or Markdown but I could not get a manual page that looked right in both formats, so I quit using Sphinx and just wrote it in Markdown.

I hope we'll see clever uses of templates. For example, people using rare fonts could encode them in base64 and embed them in a style sheet in the template. It's not a solution for #14 yet but it's a start!

[Earnestly]

While I prefer *roff (because like latex, it's a proper typesetter) I do appreciate the need for a more flexible, or at least modern format. youtube-dl uses markdown (generated from its README) which is then passed through pandoc to generate the man page:

https://github.com/rg3/youtube-dl/blob/master/Makefile#L90-L93

$(PYTHON) devscripts/prepare_manpage.py youtube-dl.1.temp.md
pandoc -s -f $(MARKDOWN) -t man youtube-dl.1.temp.md -o youtube-dl.1
rm -f youtube-dl.1.temp.md

While pandoc itself is a pretty heavy dependency it is pretty much the best document conversion tool available.

Writing the termtosvg-template(5) in roff might be a bit tricky since you've got to deal with more "normal" typesetting instead of the fairly rigid layout of a section 1 manual. The man-pages(7) and groff_man(7) manuals do provides good guidelines and references on how to do various thing, however, using markdown or asciidoc or even pod might be more sensible for your needs.

[ylmrx]

There is a little bug with the window_frame_js the play/pause status gets broken if you resume play clicking anywhere on the window (instead of play/pause button). This gorgeous otherwise.
I will look further into it.