* Fix VDom url caching -- use regular requests
* new boilerplate to make writing apps easier
* render-blocking global styles (to prevent render flash)
* bug fixes and new functionality etc.
Lots of quality of life improvements (and bug fixes):
* Class(), ClassIf(), ClassIfElse() methods
* <wave:style> that can use a file vdom:/// url
* UseStateWithFn() to allow for functional setters
* If, IfElse, and ForEach for vdom construction
* batched updates for large updates -- streaming -- to get around packet size issues
* more flexible file sending code, for []byte, io.Reader, fs.File, and a fileName (with optional MimeType)
* fix the vdom:// protocol handler to work with fetch
* updated wshcmd-html for new best practices
Going forward for new installations, config and data files will be
stored at the platform default paths, as defined by
[env-paths](https://www.npmjs.com/package/env-paths).
For backwards compatibility, if the `~/.waveterm` or `WAVETERM_HOME`
directory exists and contains valid data, it will be used. If this check
fails, then `WAVETERM_DATA_HOME` and `WAVETERM_CONFIG_HOME` will be
used. If these are not defined, then `XDG_DATA_HOME` and
`XDG_CONFIG_HOME` will be used. Finally, if none of these are defined,
the [env-paths](https://www.npmjs.com/package/env-paths) defaults will
be used.
As with the existing app, dev instances will write to `waveterm-dev`
directories, while all others will write to `waveterm`.
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>
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
