In #232, cluster animations were added, but they weren't serialized as part of the cluster design, which meant that sharing them wouldn't copy over the animation. This fixes that.
This also removes "(experimental)" from the animation widget label.
Currently it's possible to generate random clusters (formerly known as creatures), but unlike mandalas, there's no way to _edit_ one if you decide that there's something about it that you'd like to change. This means, for instance, that if a randomly-generated cluster looks nice but needs a hat, or if it has arms you don't like, or if you find something cool in the gallery but want to remix it a bit, you will be able to make those changes.
It also isn't currently possible to randomly generate a cluster with lots of complexity; the data structure to represent a cluster is defined recursively, however, so this editing UI--however horrible this initial version is--allows for the construction of clusters of arbitrary complexity.
Note that the UX for this is currently terrible, but we can improve on it in future PRs.
This adds another color-modifying button, "Mono", which makes the fill and stroke colors a minor variation of the background. This makes the composition as a whole monochromatic, hence the name.
In practice, this is just tinting the background by black (stroke) and white (fill) a tiny bit. The color transformation could be used, for instance, to turn a cluster (even a simple one that is essentially just a single symbol) into a background for another cluster. (Note that there's not currently an easy way to actually compose multiple compositions like this, though I'd like there to be!)
This adds a "B&W" button to the colors area in the cluster and mandala pages. Clicking it will reset the background, stroke and fill colors to their monochromatic defaults.
I'm calling the button "B&W" for now to minimize the amount of space the button takes up, since I'd like to add at least one more to that area. At some point we might want to use a UI that scales a bit better, like a dropdown button.
This fixes#213. It is not particularly accessible, but since it (hopefully) shouldn't be displayed too often, I'm going to merge it anyways for now--better an inaccessible modal than failing silently.
This fixes#222. Note that it only renames it in the UI, not in the code or the TOML metadata, as that would require a ton of changes, and possibly break old links.
This adds thumbnails to the gallery (#26). Mandalas are not currently animated (I'm worried that doing this for lots of mandalas would severely impact performance). It also adds a loading throbber for the gallery page.
If a gallery item can't be deserialized, a sad face is shown in place of a thumbnail, with a more detailed explanation on mouseover.
Currently the implementation is not as clean as I'd like. I'll clean it up in a separate PR, as it will involve factoring out logic from the creature and mandala pages (similar in concept to #189 / #190), which would add lots of noise to this diff.
This implements an _extremely_ basic Firebase-powered gallery (#26). At present it's just a list of links to creatures/manadalas that open in new tabs, without preview thumbnails. Or the ability to submit new entries. These features will be forthcoming in future PRs.
As with #215, this decouples the view logic from Firebase so we can use something else in the future if we want.
This adds GitHub login via Firebase, as a foundation for adding a gallery (#26). Currently it just adds a login/logout button to the Debug page.
At an architectural level, this adds an `AuthContext` React context, whose interface is generic enough that it's not coupled to Firebase or GitHub. In fact, the default context is a "null context" whose operations are all no-ops.
This adds a new `useRememberedState()` React hook that effectively allows us to have user interface elements that "remember" their most recent value, even if the UI itself was unmounted at some point. (It only works for the lifetime of the page, however, so it doesn't remember values across page reloads; this is intentional, as I didn't want to have to worry about serialization or schema migration.)
The hook is now used in the randomizer widget and for some of the creature page widgets, to ensure that their settings are preserved more often than not.
The creature state stored in #210, while quite compact, is also very fragile, because any minor change in our creature generation algorithm or even vocabulary will completely throw off existing serializations.
This attempts to serialize the actual _creature_ created by the generator rather than its random number seed, which will be a larger serialization but also one that is more resilient to future changes in the algorithm and/or vocabulary. It should also pave the way for tweaking generated creatures.
Note that the previous `v1` schema implemented in #210 is no longer supported--i.e., links that use it will now be broken. Hopefully this is OK because it hasn't been around for very long, but it was just way too much work to migrate that schema to the new `v2` format.
This is an attempt to help with #61 by storing the creature state in the querystring.
However, a crucial issue with this implementation as it stands is that it stores the random number seed used to generate the creature. This is great for representing the state in a compact form, but it's also likely to break easily as the vocabulary and randomization algorithm changes.
So, in the future, we might want to represent the creature state by enumerating the actual structure of the creature, which is likely to be a bit more future-proof. (It also makes it possible for us to add features in the future that allow users to tweak the randomly-generated creature.)
But for now at least, this will allow users to use the back and forward buttons in their browser to navigate between creatures, so that if they click randomize and skip past something that looked cool, it's easy to go back and visit it.
Fixes#191.
Currently the implementation is fairly naive, in that a really large value for `creature_frequency_multiplier` will not be handled terribly efficiently, but we can optimize later if needed.
This splits up our `styles.css` file into multiple CSS files that sit alongside the TSX files that use their classes. All "generic" CSS that isn't used by any one particular component, such as our `thingy` class, is currently being put into `page.css`.
The CSS files are imported via `import` statements in their associated TSX files. As such, this fixes#164.
This also starts formatting our CSS using Prettier.
It also moves some of our `<head>` tags back into `index.html`, reverting a tiny bit of #205, to ensure that some of the metadata can be recognized by browsers, and start loading asynchronously, independently of the page's JavaScript (I see no reason why any of those elements need to change dynamically based on the app's state, so there don't seem to be any downsides to this).
This does the following:
* Adds logo
* Adds favicon
* Creates css directory in dist
* Creates img directory in dist
* Updates /lib/page.tsx to use helmet to incporate the logo, favicon and style.css file
* adds a new file .gitattributes to make Windows use Linux line endings per https://prettier.io/docs/en/options.html
Co-authored-by: Webaissance <git@webais.com>
This adds a new attachment point type called `wildcard` (colored `#000000` in the SVGs) which, as the name suggests, can contain _any_ kind of symbol.
Fixes#187.
This minimally fixes#143 by adding optional hills to the waves page (they default to being disabled but can be enabled via a checkbox). It also adds haze to the waves, so that they are blended with the color of the sky as they recede into the distance.
This makes us actually check TSX files with Prettier (until now we were only checking TS files).
It also re-runs Prettier, although apparently it fixes something in a TS file that was raising a warning, which I find very odd--since TS files were already being checked, I'm not sure how we didn't have a broken build...
This adds a toggle to disable gradients, fixing #140.
On the Mandala page, this changes how our permalinks are structured, but does so in a backwards-compatible way, thanks to [Avro schema evolution][1]. Now the `s` querystring argument is prefixed with a schema version, the latest being `v2`. If this prefix is missing, it's assumed to be the very first schema version, `v1`, and interpreted accordingly.
[1]: https://martin.kleppmann.com/2012/12/05/schema-evolution-in-avro-protocol-buffers-thrift.html
Fixes#128.
A number of hook-related warnings were brought up, which this PR also fixes. Note that from now on, if there are any warnings raised by the eslint, CI will fail.
This replaces Parcel with [esbuild][].
esbuild has a number of advantages over Parcel:
* It is much, much, *much* faster. A Parcel build takes several seconds on my system, while esbuild takes 60-70 _milliseconds_.
* Parcel hard-crashes when I switch branches on Windows, esbuild doesn't.
The one disadvantage is that, as far as I can tell, esbuild doesn't support any kind of auto-reloading in the browser when you change things. IMO this isn't that big a deal and the benefits outweigh this minor inconvenience (and anyways, auto-reload has historically backfired so many times that I usually have been manually reloading the page whenever I make changes).
[esbuild]: https://esbuild.github.io/
Made the new rule the default, but its now easy to play with to adjust the exact color rule we are using. This new one pick 3 values (with a bit of randomness), picks a random hue (then picks 2 more with a small chance of taking the opposite hue), and picks a saturation level that tends to be high.
This fixes#93 by making the exported mandala filenames include the names of the symbols used in them. So for example, a mandala with circles made up of the `crown_ornate` symbol and the `heart_break` symbol will now have an exported GIF filename of `mandala-crown_ornate-heart_break.gif`.
Atul Varma