[Feature]: MacOS and Linux support

[thombruce]

Feature request

We're presently building for MacOS and Linux but these aren't tested.

One of my major concerns with these is... where are our config and todo files stored? In the Windows portable app, we've ensured the docs are saved in the same directory. I'm not confident that this behaves the same way on Mac and Linux.

This needs to be tested, and the platforms need to be officially supported or otherwise... removed from published releases (post 1.0.0 anyway - it's all fair game before then).

---

Tangential to this... Auto-updates from GitHub releases? I saw somewhere in the docs that this is possible... maybe not for a portable app, but... also maybe?

Code of Conduct

• I agree to follow this project's Code of Conduct

[thombruce]

VERY handy: https://github.com/electron/electron/blob/main/docs/api/app.md#appgetpathname

Those are utilities for targeting specific files/folders on the target file systems. That should be all I really need to get the Linux and MacOS versions working (non-portable Windows too). With that, I could have a high degree of confidence that Toodles works on all platforms. Not 100% but high. I would still want to test on all platforms I can, where possible.

[thombruce]

Running the dev app on Linux now yields an error when I attempt to save a todo (config too, no doubt):

(node:2287) UnhandledPromiseRejectionWarning: Error: ENOENT: no such file or directory, open 'undefined/todo.txt'
(Use `electron --trace-warnings ...` to show where the warning was created)
(node:2287) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)

undefined/todo.txt is a my bad. We should probably make this change on TNT:

- join(String(process.env.PORTABLE_EXECUTABLE_DIR), "tnt.config.json")
+ join(String(process.env.PORTABLE_EXECUTABLE_DIR || ""), "tnt.config.json")

Right now we're casting undefined to a string. Why? Because join() expects a string, I think, and I didn't think it through. Easy fix.

[thombruce]

That fix is now pushed to TNT and upgraded on Toodles.

[thombruce]

I've read up on AppImage, which is a portable format. If the behaviour of an AppImage is similar to how the app runs in dev, then portable application support is now there on Linux - the documents should store in the same folder as the AppImage, which is a portable format.

For MacOS...

.dmg is not a portable format, but .pkg might be?

These all ideally need to be tested. I can bust out my old MacBook to try and do that (it's pretty busted - monitor does not work - but I can hook it up to my external monitor when I have some time).

---

Additionally,

NSIS and .dmg support auto-updates. It's a good reason to think about supporting non-portable versions eventually too.

---

Ideal path to full set of targets:

1. Windows Portable (done!)
2. Linux Portable (AppImage) (possibly done)
3. MacOS Portable (.pkg, we think)
4. Windows auto-updatable (NSIS)
5. Linux auto-updatable (AppImage/DEB/RPM)
6. Mac auto-updatable (DMG)

Auto Update documentation (targets header selected): https://www.electron.build/auto-update.html#auto-updatable-targets

Also think about restoring Snap support to Linux (it's a default I disabled due to errors in the build).

---

And of course an honorary mention for Web - out of scope here, but it is yet another platform where how we save the data is going to be very different. Our API should take this (and mobile platforms eventually) into account.

Side note: Should TNT Electron really be... TNT Application or something like that? A generic multi-platform approach to publishing a SPA app as an app across multiple platforms? Let's not do that for now - not until we're able to build mobile apps and test them, as this will provide clarity about what the layer structure would look like if we did combine them into one.

[thombruce]

Consider either disabling MacOS and Linux builds until we're certain the features all work on these platforms or...

...maybe conditionally run their build/publish tasks only when the tag is a pre-release (alpha, beta or RC). Standard numbered releases (especially post 1.0) should only build known working applications.