Template(s) for "Export for web"

[jeremydouglass]

It would be a nice feature if Inky allowed customization of its default export-for-web assets -- like a template or templates for main.js + index.html, e.g. stored in Library/Application Support/Inky/templates/. However easiest to implement: edit those files directly, define a default in preferences, select at export time, or indicate in .ink via #TEMPLATE.

1. simple core assets like main.js can be edited. Export uses these.
   • ...and you can reset them to the stored shipping defaults if you mess them up
2. optionally, as an advanced feature, inky allows you to store multiple templates. Any one or multiple of these patterns would work:
   • choose one at export time
   • choose one in preferences, configuring export
   • indicate one in the main ink file, e.g. #TEMPLATE: templatename

If I am working with a team or class I could distribute a template that makes it easy for them to set up multiple new projects with specific in-house features from within inky.

Currently I believe this must be done by exporting, then customizing the export, then using export story.js. The drawbacks of the current method are that it is not only laborious, it is brittle for learners -- if they forget and use the wrong export they wipe out their template materials.

Possibly related to #181

[jeremydouglass]

Hmm. Are the template files packed and concealed in the Inky electron app "app.asar"?

https://github.com/inkle/inky/search?q=asar

To mitigate issues around long path names on Windows, slightly speed up require and conceal your source code from cursory inspection, you can choose to package your app into an asar archive with little changes to your source code. https://www.electronjs.org/docs/tutorial/application-packaging

The problem is that this conceals the template files. If they were not hidden in an asar fiile then they could at least be manually overridden, for example on macOS with Finder > Inky.app > Show Package Contents. So without any features added, customization would be possible without a rebuild.

It looks like currently there is already an exception for inklecate.

[jeremydouglass]

Thinking about this a bit further, I think that just excluding template files from the asar won't work -- Inky may be headed for app signing as per #181 #225, and once signed anything modifying the package contents could invalidate that signature.

Instead, template files should have their default copies stored in the .asar but their working copies saved in app data (electron appData / app.getPath(name)) -- on macOS, ~/Library/Application Support/Inky/. This is just a bit more involved because then Inky needs some basic logic to replace those files if they are missing, or to rename-and-replace them when a new version runs for the first time (so as to not letting customization silently break the next version, while also not silently deleting custom user files.

[joethephish]

The expected way to do this right now is to only export the template once at the beginning of the project, use it as a starting point and customise to your heart’s desire.

Then you can use the option to only export the updated story JS file, leaving the other files intact.

Does that suit your use case?

[jeremydouglass]

The expected way to do this right now is to only export the template once at the beginning of the project, use it as a starting point and customise to your heart’s desire.

Thank you, yes, this works and I am able to use this. I used this flow while working on #LINK and #AUDIO.

Does that suit your use case?

Not fully. Here is the use case:

Several writers, house style: A group of writers (such as a team, a writing workshop, or a classroom, etc.) are working with Inky. Each writer will create and export multiple ink projects. The group is using a shared template (html/css/js). The template could use any features that wouldn't be accepted as a PR to the Inky default template because it should be a house style instead (video clips, map hud, VN characters, credit or copyright information in an html file, whatever).

What the lead / instructor wants:

1. distribute the template (html/css/js) to the writers, who install them.
2. each time a writer creates a new project or exports a project, it works.

What may happen instead:

1. Lead distributes files to writers, and instructs them to save them someplace in use file space, then, on each new project, to full export the project then copy (but not move) the template files into that project -- for the first time only, then use story.js on the second export and thereafter.
2. Some writers do this successfully
3. Others fail to copy the files as instructed--they put them in the wrong place, or drag in the css but not the js, or js but not the css, etc. Sometimes this is immediately evident, other times it is not -- e.g. the css changes the appearance, but they assume they are making .ink errors when in fact they failed to copy the .js correctly.
4. Others move rather than copying the files, installing them but losing their template. This has bigger consequences later when:
5. A substantial number who do install the files correctly will later overwrite their files by accidentally selecting "export." For some, this also deletes their only copy, so they must also re-download.

Everything is doable, but error prone -- the face that clicking the wrong export and the two options are next to each other in a menu seem to be particularly hard. That's why I'm trying to think through the very least complex implementation possible that would allow the default template to be customized in a way that could be used by new projects.

A different workaround would be if Inky allowed a scriptable hook on its export menu item that ran e.g. a customizable pre-export.js or post-export.js script in appdata. However I'm not sure what the implications would be for external scripts run by Inky having file system permissions.

[joethephish]

Hrm. Understood, and I can understand how this stuff can be error-prone.

It's difficult though, it's hard to imagine a perfect UI without mistakes for this use case.

I wonder if the easiest thing is simply for you to build your own custom version of inky? You may have already done this, but just in case you haven't, it's not too tricky:

1. Download source
2. Replace template in Inky/app/export-for-web-template
3. Double-click one of the BUILD_ scripts depending on platform (BUILD_PACKAGE.command does all platforms but only runs on Mac). You need to have node installed.
4. Distribute to students

[jeremydouglass]

This is a good option, thank you. It works for me.

A downside going forward is that -- if code signing is added to Inky (#181) -- this method will break that signing.

[joethephish]

I currently have no immediate plans to add code signing, and I’m sure it would be possible to separate out the build and code signing steps, so you could still use an unsigned version.