Adds new functionality on the backend that will merge any file from the
config directory that matches `<partName>.json` or `<partName>/*.json`
into the corresponding config part (presets, termthemes, etc.). This
lets us separate the AI presets into `presets/ai.json` so that we can
add a dropdown in the AI preset selector that will directly open the
file so a user can edit it more easily. Right now, this will create a
preview block in the layout, but in the future we can look into making
this block disconnected from the layout.
If you put AI presets in the regular presets.json file, it will still
work, since all the presets get merged. Same for any other config part.
There were two type errors after the most recent electron upgrade, but
they're both benign (event handler parameter mismatch) so I am adding
ts-expect-error to both instances.
Removes global atoms dependency from emain by moving WOS to grab the
globalAtoms from window, if present. Also removes interdependency
between wshrpcutil and wps
Also adds showmenubar setting for Windows and Linux
This will take the latest artifact from the waveterm-docs repo and embed
it in the app binary. When the help view is launched, it will be served
from our backend. If the embedded copy doesn't exist, such as in
unpackaged versions of the app or in locally packaged versions, it will
use the hosted site instead.
There is a sibling PR in the docs repository to build the embedded
version of the app (strips out some external links, removes Algolia
DocSearch, updates the baseUrl)
https://github.com/wavetermdev/waveterm-docs/pull/46
This bypasses the Go backend when fetching the settings for the app on first launch. This allows for actions that need to be performed before the app is ready, such as disabling hardware acceleration.
When a user first launches Wave, we will read the updater config and
store the channel as a user setting for use on future launches. This
should ensure that if a user on a beta channel gets updated to a latest
release, they will still be subscribed to beta releases going forward.
If a user manually updates the user setting, it will be honored.
---------
Co-authored-by: sawka <mike@commandline.dev>
## New release flow
1. Run "Bump Version" workflow with the desired version bump and the
prerelease flag set to `true`. This will push a new version bump to the
target branch and create a new git tag.
- See below for more info on how the version bumping works.
2. A new "Build Helper" workflow run will kick off automatically for the
new tag. Once it is complete, test the new build locally by downloading
with the [download
script](https://github.com/wavetermdev/thenextwave/blob/main/scripts/artifacts/download-staged-artifact.sh).
3. Release the new build using the [publish
script](https://github.com/wavetermdev/thenextwave/blob/main/scripts/artifacts/publish-from-staging.sh).
This will trigger electron-updater to distribute the package to beta
users.
4. Run "Bump Version" again with a release bump (either `major`,
`minor`, or `patch`) and the prerelease flag set to `false`.
6. Release the new build to all channels using the [publish
script](https://github.com/wavetermdev/thenextwave/blob/main/scripts/artifacts/publish-from-staging.sh).
This will trigger electron-updater to distribute the package to all
users.
## Change Summary
Creates a new "Bump Version" workflow to manage versioning and tag
creation.
Build Helper is now automated.
### Version bumps
Updates the `version.cjs` script so that an argument can be passed to
trigger a version bump. Under the hood, this utilizes NPM's `semver`
package.
If arguments are present, the version will be bumped.
If only a single argument is given, the following are valid inputs:
- `none`: No-op.
- `patch`: Bumps the patch version.
- `minor`: Bumps the minor version.
- `major`: Bumps the major version.
- '1', 'true': Bumps the prerelease version.
If two arguments are given, the first argument must be either `none`,
`patch`, `minor`, or `major`. The second argument must be `1` or `true`
to bump the prerelease version.
### electron-builder
We are now using the release channels support in electron-builder. This
will automatically detect the channel being built based on the package
version to determine which channel update files need to be generated.
See
[here](https://www.electron.build/tutorials/release-using-channels.html)
for more information.
### Github Actions
#### Bump Version
This adds a new "Bump Version" workflow for managing versioning and
queuing new builds. When run, this workflow will bump the version,
create a new tag, and push the changes to the target branch. There is a
new dropdown when queuing the "Bump Version" workflow to select what
kind of version bump to perform. A bump must always be performed when
running a new build to ensure consistency.
I had to create a GitHub App to grant write permissions to our main
branch for the version bump commits. I've made a separate workflow file
to manage the version bump commits, which should help prevent tampering.
Thanks to using the GitHub API directly, I am able to make these commits
signed!
#### Build Helper
Build Helper is now triggered when new tags are created, rather than
being triggered automatically. This ensures we're always creating
artifacts from known checkpoints.
### Settings
Adds a new `autoupdate:channel` configuration to the settings file. If
unset, the default from the artifact will be used (should correspond to
the channel of the artifact when downloaded).
## Future Work
I want to add a release workflow that will automatically copy over the
corresponding version artifacts to the release bucket when a new GitHub
Release is created.
I also want to separate versions into separate subdirectories in the
release bucket so we can clean them up more-easily.
---------
Co-authored-by: wave-builder <builds@commandline.dev>
Co-authored-by: wave-builder[bot] <181805596+wave-builder[bot]@users.noreply.github.com>
This change shaves ~20 MB off the download size by only copying over the
wavesrv binary that is relevant for whichever architecture we're
currently packaging. This is only relevant for macOS at the moment,
though it can also apply to Windows when we get multi-arch builds
working.
This required renaming our Go binaries from .amd64 to .x64 to comply
with electron-builder's naming conventions.
We only need global Cut/Copy/Paste accelerators on macOS. Linux and
Windows do these automatically. Additionally, having these accelerators
means that we can't use shortcuts like Ctrl+C in the terminal. This PR
removes these accelerators for every platform but macOS.
With this PR, Electron will generate a new authorization key that the Go
backend will look for in any incoming requests. The Electron backend
will inject this header with all requests to the backend to ensure no
additional work is required on the frontend.
This also adds a `fetchutil` abstraction that will use the Electron
`net` module when calls are made from the Electron backend to the Go
backend. When using the `node:fetch` module, Electron can't inject
headers to requests. The Electron `net` module is also faster than the
Node module.
This also breaks out platform functions in emain into their own file so
other emain modules can import them.
This PR updates the window controls overlay code to remove the
dependency on `sharp`, which is a natively-compiled Node library that is
really hard to package for Electron given the way that we strip node
modules after bundling. I've replaced this with `pngjs`, which has a
smaller footprint and is still relatively fast (it doesn't need to be
perfect since it runs on the Node process instead of the browser
process).
The Window Controls Overlay API applies a transparent overlay on
Windows, but not on Linux. This PR addresses this by capturing the area
underneath the overlay, averaging the color of the area, and setting
this as the overlay background color.
It will also detect whether to make the control symbols white or black,
depending on how dark the background color is.
On Linux, this will set both the background color and the symbol color,
on Windows it will just set the symbol color.
<img width="721" alt="image"
src="https://github.com/user-attachments/assets/e6f9f8f8-a49f-41b6-984e-09e7d52c631d">
This PR implements the [Window Controls Overlay
API](https://web.dev/articles/window-controls-overlay) to let us hide
the menu bar on Windows and Linux and directly embed the window controls
in our tab bar. With #239 merged, we no longer need the menu bar on
these platforms.
The overlaid window controls are transparent so they will take on the
background from the app. I've updated the tab bar to flow properly using
the API's CSS environment variables.
At some point, we may want to update the logic around the symbolColor so
that it can ensure a proper contrast between the background and the
symbols in the window controls. For now, setting them to white works for
all the backgrounds we currently support.
https://github.com/user-attachments/assets/8d19b512-5281-42b9-8abb-ccb9b850061f
This improves the app updater so that it doesn't rely on unreliable
system notifications. Now, a banner in the tab bar will display when an
update is available. Clicking this will prompt the user to restart the
app and complete the installation.
This also updates the tab bar to move to the smaller tab size earlier so
we don't need to make the tab bar scrollable as much.
Adds support for window blur via the Vibrancy feature on macOS and the
BackgroundMaterial feature on Windows. The setting has no effect on
Linux. If both transparency and blur are set, transparency will take
precedence.
This adds a new global atom to track whether a window is in full screen.
It also updates the behavior of the tab bar so that it will only add an
extra left indent on macOS windows that are not in full screen.
Otherwise, the indent will be much smaller.
Adds support for building for Linux ARM targets using the new GitHub
Linux ARM64 runners. Adds a new menu item to toggle the visibility of
the menu bar on non-darwin targets,
Adds a new set of configurations for managing whether the app will
automatically check for updates. Ports over the auto update code from
the old app. In this version, the main difference is that updates can be
manually checked for using a menu bar item, even if auto updates are
disabled.
