I’ve been reading Grok Tiddlywiki based on @khinsen’s recommendation. Tiddlywiki’s achilles heel is the complexity of saving data. I don’t know why it says browser File/Save doesn’t work. I just tried it on Firefox and it seems to work just fine. With some minor issues:
I suppose the “doesn’t work” warning refers to the fact that what happens is browser-dependent and changes over time. It should really read “play with it if you want, but don’t bother us with questions”.
This is an issue for all in-browser editors, and one big reason why I prefer to avoid them. It seems you can’t have in-browser tools with local-first data, unless you run a server on every device and let the user deal with the resulting interfacing issues (port number conflicts etc.).
Yes, TW has a lot of varieties of ways to save data and no predefined default. In our workshops we start by making the apprentices to get and account in TiddlyHost, replace the default wiki with one of our custom wiki seeds (usually our mod of projectify with prepackaged learning projects and lessons for the participants). If they want to use TW offline, including saving, we advice them to use Timimi (and in fact is one of the optional lessons included in our wiki seed).
You may find the previous learning path useful to you, as it has been tested with dozens of TW novices before. Of course, suggestions are welcomed.
Redbean exists. It’s new-ish but not nearly enough people seem to appreciate the implication of its existence. It’s more or less how you’d go about solving the problems you mentioned.
Thanks for the pointer! Redbean looks very interesting indeed, and I had never seen it before.
It’s still not what I would propose for “ordinary” users, because you have to be at ease on the command line to deploy the server. But for use in small communities with a few techies, it looks great.
BTW, Fossil can be used in a similar way. It doesn’t include the executable, so you have to install that on each machine, you store a complete Web site in a Fossil repository (which is a single SQLite file) and deploy it with a single command. Not programmable, so no Web apps, but great for static sites and Wikis.
The docs on the landing page are written for developers, but I don’t know of anything that would preclude using Redbean as an app that can be run without having to use a terminal emulator to launch it. Is there something you know of?
I suppose it can be done by adding a suitable wrapper, but that wrapper would have to be different for each platform. You thus lose both the “all-in-one-file” feature and straightforward portability.
Note that in-browser apps can themselves trigger a file save (and thus assist with naming) by using the
I don’t see why that would be so.
On a Mac, that “wrapper” would consist of making sure the binary is in a directory
Foo.app/ (for your app Foo), right? This doesn’t pose a problem for Windows or Linux. Mac users will see “Foo.app” as an opaque app that can be launched by clicking. Windows and Linux users upon double-clicking will be taking into
Foo.app/ where they will see the binary, which in turn can be double-clicked.
It’s not exactly the same experience, but close enough to idiomatic for each platform and doesn’t require abandoning the one-size-fits-all distribution strategy (i.e. different form of packaging on each platform).
Am I wrong? Is this something about the fact that recent versions of Mac OS don’t by default like running unsigned apps that are just downloaded willy nilly from the Internet, rather than going through the anointed channels on on the Mac App Store? I haven’t had a Mac in several years and don’t have one handy to check.
The macOS app layout would be
for the executable plus at least one configuration file (XML) under
Other platforms could ignore the configuration file, but their users would need to be convinced to run an executable from a folder called
What if there were a stub loader at Foo.app/foo that when run was hardcoded to invoke Foo.app/Contents/MacOS/foo? (Alternatively, Foo.app/Contents/MacOS/foo would invoke Foo.app/foo?) That’s a minor piece of overhead, but it could also be put into the toolchain that produces the Actually Portable Executable in the first place, so the developer doesn’t see it either—even though it would be an acceptable tradeoff if they did have to, since the user’s experience should be prioritized. (The APE toolchain is, after all, already going through the process of emitting correctly formed executables that satisfy each platforms’ executable format in a roundabout way.)
I can’t say if that would work. I know what is minimally required for a macOS app, but I don’t know the complete rules. My vague memory is that you cannot have anything else than the “Contents” folder inside the root app folder, otherwise the directory is not recognized as an app. But I left macOS two years ago, so all my memories are slowly fading away.