Stupid idea: source with all undo(s)/redo(s) history

i have an idea and know it’s (most probably) not one of your concerns or priories, but i started to think about it for a while and hope you find it interesting as an idea.
font sources from start to finish have an undo/redo history for all glyphs, but every time when closing the app and opening again, it’s getting disappear. we can tack backups of the source in several points or creating backup layers in the same source, or even using somethings like git, but these have some limitations or complexities imo. if undo/redo history implemented in one source somehow, helps things go easier(costs are: heavier size, complexer system to support different versions of Glyphs software components, maybe more crash reports! ,…).
to implement such system i have some thoughts, i name it ‘snapshot’. a concept like this:

glyphname = A;
currentsnapshot = 0
snapshot = -1 {
# glyph data...
snapshot = 0 {
snapshot(-1).node(34).transform.move(x) = -5;
snapshot = 1 {
snapshot(0).transform.skew(pivot=topright)= -1.5;
snapshot = 2 {
snapshot(1).filter(id=0x00fb, name= Round, ver=1.02) {
#filter parameters settings
snapshot = 3 {
#new glyph data

(i made up the codes from myself to present the examples)
1- more and more snapshots will make the source file heavier, so one idea to solve that, could be to write them at a separated file.
2- i didn’t talk about branches, where we going back to a snapshot and start to change it, we actually make a new snapshot in the past, so the next snapshot(s) either must be deleted or considered as a new branch(this is not exist in a regular file with undo/redo history). for complex efforts and much snapshots and branches, we need a tree diagram.
3- an option should be available to purge snapshot records for selected glyph(s)

This is not a stupid idea. Good news though: This has existed for a long time already, not just for Glyphs.

Are you aware of git? Most commonly in the form of GitHub.

Tip: use the glyphspackage file format for much easier git integration.

There was a plugin that stored this kind of data in the Glyphs file itself called Layer Whale. It would let you hit record while editing a Glyph, and under the hood made a bunch of backup layers that it would hide from the UI. I don’t believe it was ever ported over to Glyphs 3. One issue with storing this kind of information in Glyphs files is that it takes up a lot of extra file size. That plugin was pretty error-prone too, the larger a file got.

What would be really nice is a tool built on top of git that looks at version history of individual .glyph files in a Glyphspackage and renders images of them as they change over time

If you are using the 3.2 beta, I might have a plugin for you. Write me a message in case you’re interested.


I made some progress on the animation idea :slight_smile:

Composite glyphs and public repos not yet supported. Not sure how far I’ll go with this script or if it was just a fun weekend project…

thank you. yes, i mentioned that. git has its own problems. i didn’t work with glyphspackage yet, … all of these can’t produce an all in one gui based source to explore in whole edit history easily.

thank you.

There is something in the works by Florian, as he hinted at above.

1 Like