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.
![image
(2)](https://github.com/user-attachments/assets/7610f10b-9696-435c-9a2d-a435bee9fadb)
https://github.com/user-attachments/assets/8d19b512-5281-42b9-8abb-ccb9b850061f
This PR is a large refactoring of the layout code to move as much of the
layout state logic as possible into a unified model class, with atoms
and derived atoms to notify the display logic of changes. It also fixes
some latent bugs in the node resize code, significantly speeds up
response times for resizing and dragging, and sets us up to fully
replace the React-DnD library in the future.
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.
![image](https://github.com/user-attachments/assets/79e24617-d609-4554-bdb2-979f810a9b66)
This will ensure that the webview cannot capture the pointer events and
disrupt the drag functionality.
This also fixes an issue where greedy and imprecise bounds calculations
could result in thrashing of the layoutState.pendingAction field, which
could cause the placeholder to flicker.
This also fixes issues where some React Effects that were supposed to be
debounced or throttled were being invoked too much. This is because
useEffect regenerates the callback when it is run, resulting in the
debounce or throttle never taking effect. Moving the throttled or
debounced logic to a separate callback solves this.
Adds the implementation for the "Magnify Block" context menu item. This
will pop a block out of the layout and bring it to the foreground.
This also cleans up some block styling to make radii more consistent.
<img width="814" alt="image"
src="https://github.com/user-attachments/assets/c81521e1-c91f-4bb5-9eec-ff0eda178268">
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 electron-builder, which we will use to package and distribute our
application, same as in the existing app.
Replaces explicit port assignments with dynamic ones, which are then
stored into environment variables.
Adds a ~/.w2-dev folder for use when running a dev build.
The build-helper pipeline from the old repo is included here too, but it
is not updated yet so it will fail.
Also removes some redundant utility functions and cleans up some let vs.
const usage.
The packaging can be run using the `package:prod` and `package:dev`
tasks.
---------
Co-authored-by: sawka <mike.sawka@gmail.com>
Adds resizability to the layout system.
Hovering in the margins of a block will highlight the available resize
handle and show a cursor indicating its resize direction. Dragging will
cause the resizing nodes to blur out and be replaced by an outline.
Releasing the handle will commit the new resize operation and cause the
underlying nodes to update to their new sizes.
We'll want to refactor this in the future to move all layout and resize
logic into a shared model that the TileLayout code can talk to, but
that's a future improvement. For now, this makes some compromises,
mainly that the logic is kind of distributed around.
---------
Co-authored-by: sawka <mike.sawka@gmail.com>
This PR adds support for Outer variants of each DropDirection.
When calculating the drop direction, the cursor position is calculated
relevant to the box over which it is hovering. The following diagram
shows how drop directions are calculated. The colored in center is
currently not supported, it is assigned to the top, bottom, left, right
direction for now, though it will ultimately be its own distinct
direction.
![IMG_3505](https://github.com/wavetermdev/thenextwave/assets/16651283/a7ea7387-b95d-4831-9e29-d3225b824c97)
When an outer drop direction is provided for a move operation, if the
reference node flexes in the same axis as the drop direction, the new
node will be inserted at the same level as the parent of the reference
node. If the reference node flexes in a different direction or the
reference node does not have a grandparent, the operation will fall back
to its non-Outer variant.
This also removes some chatty debug statements, adds a blur to the
currently-dragging node to indicate that it cannot be dropped onto, and
simplifies the deriving of the layout state atom from the tab atom so
there's no longer another intermediate derived atom for the layout node.
This also adds rudimentary support for rendering custom preview images
for any tile being dragged. Right now, this is a simple block containing
the block ID, but this can be anything. This resolves an issue where
letting React-DnD generate its own previews could take up to a half
second, and would block dragging until complete. For Monaco, this was
outright failing.
It also fixes an issue where the tile layout could animate on first
paint. Now, I use React Suspense to prevent the layout from displaying
until all the children have loaded.
I am updating the layout node setup to write to its own wave object.
The existing setup requires me to plumb the layout updates through every
time the tab gets updated, which produces a lot of annoying and
unintuitive design patterns. With this new setup, the tab object doesn't
get written to when the layout changes, only the layout object will get
written to. This prevents collisions when both the tab object and the
layout node object are getting updated, such as when a new block is
added or deleted.