It is only used during the build, to generate the CLDR data, no reason to
include it among the runtime dependencies.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
There's no need to include `dfu-util` for every platform in a platform-specific
build, so include only those that match the platform. If the platform has
multiple architectures, we'll include `dfu-util` for all of them, in every build
for the platform.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
We only use `static/cldr` during the build, to pregenerate CLDR data. Do not
include it in packaged builds.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The `cldr` package is only used at compile time, to pre-generate the CLDR
keyboard layout data. There is no reason to include it among the dependencies.
Moving it to `devDependencies` shaves about 20Mb off of the packages built, and
a whole lot more when uncompressed: the cldr package is over 200mb uncompressed.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Our old flashing process suffered from a few shortcomings, biggest of which was
its reliance on timing, and retries being woefully incomplete. In practice, this
meant that if the key to help trigger bootloader mode was not pressed soon
enough, or was released too late, we ended up in a state Chrysalis could not
recover from, because it never tried the reset again.
The new process does away with the separate "bootloaderTrigger" and
"bootloaderWait" steps, and combines them into a single "bootloader" step, which
will take care of retrying the reboot too, whether from normal mode to
bootloader, or the other way around. This also moves the retry logic into the
flasher, out of `@api/focus`.
With the logic in the flasher, it can properly notify the renderer when the
keyboard is in an unexpected state, and the renderer can - and with this patch,
does - display an appropriate message the user can act on.
With retries in place, the flashing process should be more robust, and more
forgiving, and far less reliant on timing.
Fixes#941, and likely a whole lot of other, flashing related issues.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Modeled after the application update mechanism, the firmware file auto-update
works in a similar way: if the feature is enabled (it is disabled by default),
it will check what's the latest version of the firmware on GitHub, and if it's
more recent than the version we ship with, and more recent than whatever we have
previously downloaded (if anything), then it will download the new bundle and
extract it.
The Firmware Update screen will ask the main process for the version, changelog,
and base directory to use for the default firmware. If firmware auto-update is
enabled, the main process will check first try the downloaded files, and only
fall back to the shipped version if we have nothing downloaded yet.
If firmware auto-update is disabled, then we won't even check if there's a new
version, because we'll almost always have an update, and we do not want to spam
notifications on every single startup.
Fixes#952.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The dialog simply displays `static/firmware-changelog.md` rendered into HTML.
The file is read from the main process, for which a generic IPC named
`file.read` was implemented.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
We still import cldr from the renderer process, for
`cldr.extractLanguageDisplayNames`, but that hopefully doesn't expect to be in a
node environment.
If it does, we'll have to push it (along with the cldr data) to the main process.
Fixes#924.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
This replaces the old, fragile, latest version notification on the menubar with
an auto-upgrade mechanism.
While it is the main process that does the update, it is the renderer that
initiates it. We do this so that we have better control over the process, and
can display notifications on the renderer, without race conditions.
The renderer orchestrates the process via the `useAutoUpdate` hook, called by
the `App`. The hook itself will first tell the main process to check for
updates, which in turn will result in an `update-available` event being fired,
if there's an update. That event will get sent forward to the renderer as
`auto-update.update-available`, and the hook will display a toast. We handle the
rest of the upgrade process similarly, the main process pushing new
notifications to the renderer.
Because we don't want to force updates on everybody, the feature is opt-in, and
there's a new section in the User Interface tab of Preferences to enable the
feature.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
We've been using a home-grown, pretty ad-hoc logging setup, which suffered from
a number of issues. It was simply bad, really. Log levels were all over the
place, logging was inconsistent, sometimes we logged to the console directly,
sometimes we only popped up a toast without logging it, and so on and so forth.
This is an overhaul of the whole thing.
We pull in the Winston logging library to help us out. This lets us store logs
in files too, along with logging to the developer console. We'll use this file
during the debug bundle creation, instead of keeping the session's log
in-memory.
Another big benefit of this rework is that I went through every place we log
from, and adjusted log levels to make more sense. I also added missing logging
to a number of places, so we'll get a much more useful, much more complete set
of logs.
With this new setup, we can have different log levels for the file transport,
and another for the console one. This in turn, allows us to turn down the log
level of console logs, while still having debug logs saved to disk.
Setting the log level in preferences now saves that setting, and will not reset
to the default when Chrysalis is started up again next time.
Fixes#881.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
We want to make a few elements stand out a bit more, so we're setting a slightly
darker (or in case of dark mode, slightly lighter) background on body. We set it
on the body so it will be the default background, and we won't have to go to
great lengths to hide the original body background.
Because we need the background color to be theme-dependent, we make use of the
`react-helmet` library, which helps us set properties on elements normally
outside of React's reach - like `body`.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Unfortunately, we fail to build on macOS with Electron 18, so temporarily
downgrade to 17, because that builds on macOS, and printing appears to work on
both Windows and Linux.
We'll bump it back up later, once we figure out how to fix the build.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Another package pulled in transitively by `electron-webpack`. I have no idea how
and where this is used, but updating to 5.1.2 seems to work, so lets make
Dependabot happy.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The `node-forge` package is pulled in by `electron-webpack` via `selfsigned`.
It's not something we use directly or indirectly, and as such, is safe to
upgrade, and that should make Dependabot happy.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
An unused dependeny of avrgirl-arduino depends on an ancient `async` package
Dependabot keeps complaining about. Adjust the dependency to a fixed version.
As we're not using the parts of AvrGirl that make use of this particular version
of async, there should be no issues. The parts we use were already using the 2.6
series.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
