Note that this does not actually build right now because Elm has done
a thing again to break the universe and it requires massive changes to
the application to make it work again.
Now that Hunchentoot is serving the Elm frontend, Elm needs to connect
to Gemma at a relative path.
Side note: It would be useful if the frontend displayed errors that
happened :sun:
In order to let Hunchentoot serve the static assets from the correct
location, the *static-file-location* parameter is set before image
dumping based on the $out-envvar which is present during the build
process.
This can easily be set manually in the config file if required by a
user.
Adds a build script using ASDF's program-op to build an executable out
of the Gemma source code.
In addition a Nix derivation is provided that will both compile the
Elm source and place it in a folder, as well as create the executable.
Currently static file serving does not function as intended.
Adds configuration loading from a file located at either
"/etc/gemma/config.lisp" or a path determined via the `GEMMA_CONFIG`
environment variable.
The configuration file can contain any number of deftask forms and a
single config form which determines the location at which Gemma stores
its data and also the port on which it should listen.
Uses the cl-prevalence system to store tasks on disk. The storage
location is either relative to the working directory in which the
system is started or determined (with priority) by the environment
variable `GEMMA_DATA_DIR`.
Adds a clickable area to the cards that will inform the backend of a
task being completed.
This of course still looks completely terrible because I don't really
know how frontend works.
The idea is that every task should be shown as an MDL "card" and have
some sort of associated action (probably more than just a click, but
that I'll look at ...).
Tasks are coloured based on their current "urgency".