| Commit message (Collapse) | Author | Age | Lines |
| ... | |
| |
|
|
| |
Co-authored-by: MarkKoz <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A persistent config file will remember whether the daemon is supposed
to be running, or not. This means that instead of relying on the env
variable, the daemon can be turned on or off "once and for all"
via a command, and will not violate this decision on restart.
This effectively deprecates the `Branding.autostart` env var. It is
believed that having two ways to configure the same thing would
be more confusing than useful. The env var will be removed.
The two helper functions for reading and writing have been implemented
in a generic manner, meaning that should a new config key be added in
the future, the helpers shouldn't require any further adjustments.
Suggested by lemon and scragly.
Co-authored-by: Leon Sandøy <[email protected]>
Co-authored-by: scragly <[email protected]>
|
| |
|
|
|
| |
It is not necessary to log all icon paths on each shuffle. Creates
unnecessary visual clutter in the logfile.
|
| |
|
|
|
|
|
|
| |
Define commands in the same order in which the cog's docstring lists
them. This shall make it easier to browse or look up implementations.
The commands are defined roughly in the order in which a user would be
expected to use them.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The previous system required each extension's `setup` func to log
that the cog was loaded. This leads to inconsistent messages all
trying to convey the same thing, variable logger names in the output
file are difficult to read, and several extensions were not logging
at all.
By logging directly in the `add_cog` method, we reduce code repetition,
ensure consistent format, and remove the responsibility to remember
that a log should be made.
|
| | |
|
| |
|
|
| |
Simplify internal structure & adjust var naming.
|
| |
|
|
|
| |
This simplifies the function and is more in-line with how the function
is being used.
|
| |
|
|
|
| |
To avoid confusion, the packages should no longer be referred to
as 'seasons'.
|
| |
|
|
|
|
|
|
|
| |
Since the original `seasons` package is now called just `exts`,
it makes sense to migrate all season-specific definitions out into
a separate module.
This module now contains everything relating to 'new' seasons, i.e.
just branding tooling.
|
|
|
It is believed that this is now a more logical name for the package,
as extensions no longer bind to seasons.
Internally, packages are still grouped into seasonal sub-packages.
There are quite a few, and it makes sense to group them by a common
theme that inspired their functionality.
|