Sometimes, the context menu click handlers don't seem to get passed any
window object. Here, I'm sending over the workspace id with the
`contextmenu-show` event so that we can resolve our cached copy of the
object in case the value from the click handler is empty.
Adds a new app menu for creating a new workspace or switching to an
existing one. This required adding a new WPS event any time a workspace
gets updated, since the Electron app menus are static.
This also fixes a bug where closing a workspace could delete it if it
didn't have both a pinned and an unpinned tab.
When a user spams Cmd:T, a WaveTabView might be created but never end up
getting mounted to the window, since another will come along before it
can. In these cases, the WaveTabView is essentially in a bad state and
attempting to switch to it will result in the window becoming
unresponsive. While we could recover it by running waveInit again, it's
easier to just dispose of it and treat it as an unloaded tab next time
it gets switched to.
This adds a timeout to each WaveTabView where once it gets assigned a
tab ID, it has 1 second to respond "ready" or it will be destroyed. This
should help prevent resource leakages for these dead views.
fixes bug with closeTab when the tab didn't exist in the waveWindow cache. also adds Cmd-Shift-W to close a tab (doesn't work for pinned tabs). and restores Cmd-W for killing blocks on pinned tabs
`destroy` bypasses the `close` event and forces the window to close.
This means that we can use it instead of `forceClose` and we don't need
to call it in the `closed` event.
![image](https://github.com/user-attachments/assets/a4072368-b204-4eed-bb65-8e3884687f9a)
This functions very similarly to VSCode's pinned tab feature. To pin a
tab, you can right-click on it and select "Pin tab" from the context
menu. Once pinned, a tab will be fixed to the left-most edge of the tab
bar, in order of pinning. Pinned tabs can be dragged around like any
others. If you drag an unpinned tab into the pinned tabs section (any
index less than the highest-index pinned tab), it will be pinned. If you
drag a pinned tab out of the pinned tab section, it will be unpinned.
Pinned tabs' close button is replaced with a persistent pin button,
which can be clicked to unpin them. This adds an extra barrier to
accidentally closing a pinned tab. They can still be closed from the
context menu.
Updates `DeleteBlock` to close its parent tab if the tab has no more
blocks. This will also cascade to close the workspace if it no longer
has any tabs, same for window.
I had to move some block-related functionality around on the backend.
New context menu options are available in the directory preview to
create and rename files and directories
It's missing three pieces of functionality, none of which are a
regression:
- Editing or creating an entry does not update the focused index. Focus
index right now is pretty dumb, it doesn't factor in the column sorting
so if you change that, the selected item will change to whatever is now
at that index. We should update this so we use the actual file name to
determine which element to focus and let the table determine which index
to then highlight given the current sorting algo
- Open in native preview should not be an option on remote connections
with the exception of WSL, where it should resolve the file in the
Windows filesystem, rather than the WSL one
- We should catch CRUD errors in the dir preview and display a popup
This was causing a crash on Windows because we were destroying a TabView
that was still parented to the window. Not sure why I couldn't repro
this on Mac...
This fixes a bug where closing the active tab would clean up the closed
tab view before switching to an un-closed tab view, putting the window
into an unrecoverable state. This also moves around some of the CloseTab
logic so that it's more standardized and reduces unnecessary
frontend-backend comms and DB writes
* 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
the permissions look scary, but the user still needs to grant them. this just allows the app to ask. this permission set now matches the entitlements in iTerm and other popular terminal programs (before we were too restrictive)
- Fixes updater status not showing on tabs that were previously
unloaded.
- Fixes updater status showing as error when not connected to the
internet
- Adds delay after setting installing status to avoid race condition
with any window close event handlers. This may fix#1167
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`.
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.