Fixes keyboard shortcuts that use `alt + shift` modifier (distribute
horizontally and vertically fall into this category).
Fixes [#2054](https://github.com/tldraw/tldraw/issues/2054)
### Change Type
- [x] `patch` — Bug fix
### Test Plan
1. Create multiple shapes
2. Use `alt + shift + v / h` to distribute vertically or horizontally.
### Release Notes
- Fixes keyboard shortcuts that use `alt` and `shift` modifiers.
This PR:
1. Adds a `renderingOnly` option to the `Editor.getShapeAtPoint` method.
When true, the method will only hit test against rendering shapes
(shapes that are inside of the current `renderingBounds`) rather than
all shapes on the canvas.
2. Includes some low level improvements to the way that edges find their
nearest point.
3. Includes a fix to circle geometry that could produce NaN values
### Change Type
- [x] `minor` — New feature
### Test Plan
1. Check whether hovering shapes still works as you would expect.
- [x] Unit Tests
### Release Notes
- Improve perf for hovering shapes / shape hit tests
This PR adds an additional migration that fixes a bad (a->a) migration
that I added in the previous version.
### Change Type
- [x] `patch` — Bug fix
### Test Plan
1. On the tldraw app, open a file.
- [x] Unit Tests
Before the geometry change, we'd rely on the browser to tell us which
element was hovered, which meant that when the pointer left the canvas
we'd automatically clear the hovered shape.
Currently, we don't know whether the pointer is over the canvas or not -
so we keep showing the hover indicator for the last shape you had your
pointer over.
This diff adds an `isHoveringCanvas` prop to the instance state (true,
false, or null if the current pointer doesn't support hovering) that we
can use to track this and disable the hover indicator appropriately.
### Change Type
- [x] `minor` — New feature
### Test Plan
1. Create some shapes that go below the UI
2. Move the mouse from the shape to the UI
3. Hover indicator should disappear
This diff removes the UI top center bar from the public API and tweaks
some of the styling around the top bar as a whole. Now, the left and
right bars shrink to fit their content, and the center bar is unstyled
by us. It's also marked `@internal`.
This also exposes `<Spinner />` for internal use.
### Change Type
- [x] `minor` — New feature
### Test Plan
-
### Release Notes
- [BREAKING] removed topBar prop
This PR:
- removes feature flags for people menu, highlighter shape
- removes debugging for cursors
- adds a debug flag for hiding shapes
- changes Canvas to use `useValue` rather than `track`
- removes the default background color on `tl-background`
- in the editor components, makes `Background` null by default
### Change Type
- [x] `minor` — New feature
There are a lot of cases (eg when interacting with the ui) where the
editor loses focus. This check was preventing us from updating the
viewport screen bounds when appropriate. This function is throttled and
pretty cheap anyway (if the viewport is equal its a no-op) so let's just
remove the condition
### Change Type
- [x] `patch` — Bug fix
Frame labels lost their editing outline at some point. 🤷🏼 any idea how
this happened?
## Before
## After
### Change Type
- [x] `patch` — Bug fix
- [ ] `minor` — New feature
- [ ] `major` — Breaking change
- [ ] `dependencies` — Changes to package dependencies[^1]
- [ ] `documentation` — Changes to the documentation only[^2]
- [ ] `tests` — Changes to any test code only[^2]
- [ ] `internal` — Any other changes that don't affect the published
package[^2]
- [ ] I don't know
[^1]: publishes a `patch` release, for devDependencies use `internal`
[^2]: will not publish a new version
### Test Plan
1. Add a step-by-step description of how to test your PR here.
2.
- [ ] Unit Tests
- [ ] End to end tests
### Release Notes
- Add a brief release note for your PR here.
This PR restores the controlled nature of focus. Focus allows keyboard
shortcuts and other interactions to occur. The editor's focus should
always / entirely be controlled via the autoFocus prop or by manually
setting `editor.instanceState.isFocused`.
Design note: I'm starting to think that focus is the wrong abstraction,
and that we should instead use a kind of "disabled" state for editors
that the user isn't interacting with directly. In a page where multiple
editors exit (e.g. a notion page), a developer could switch from
disabled to enabled using a first interaction.
### Change Type
- [x] `patch` — Bug fix
### Test Plan
- [x] End to end tests
This PR improves the dragging interactions on the minimap.
### Change Type
- [x] `patch` — Bug fix
### Test Plan
1. Click and drag the minimap.
2. Click outside of the viewport bounds.
3. Click inside of the viewport bounds.
This PR fixes an issue where images would overflow the shape's true
height or width.
### Change Type
- [x] `patch` — Bug fix
### Test Plan
1. Create an image shape.
2. Resize the image shape and look at the edges.
We got things sliggghhhtly wrong in #1980. That diff was attempting to
fix a bug where the text measurement element would refuse to go above
the viewport size in safari. This was most obvious in the case where
there was no fixed width on a text shape, and that diff fixed that case,
but it was also happening when a fixed width text shape was wider than
viewport - which wasn't covered by that fix. It turned out that that fix
also introduced a bug where shapes would no longer grow along the y-axis
- in part because the relationship between `width`, `maxWidth`, and
`minWidth` is very confusing.
The one-liner fix is to just use `max-content` instead of `fit-content`
- that way, the div ignores the size of its container. But I also
cleared up the API for text measurement to remove the `width` property
entirely in favour of `maxWidth`. I think this makes things much clearer
and as far as I can tell doesn't affect anything.
Closes#1998
### Change Type
- [x] `patch` — Bug fix
### Test Plan
1. Create an arrow & geo shape with labels, plus a note and text shape
2. Try to break text measurement - overflow the bounds, make very wide
text, experiment with fixed/auto-size text, etc.
Fixes an issue with creating arrows. Currently we create an arrow that
has both `start` and `end` handles set to the same point. This causes
`NaN` issues in some of our functions / svg rendering. After this change
we only create the arrow after we start dragging, which ensures the
start and the end handle won't have the same coordinates. This probably
feels the best way to approach it: arrow of length 0 doesn't really make
sense.
Resolves [#2005](https://github.com/tldraw/tldraw/issues/2005)
Before
https://github.com/tldraw/tldraw/assets/2523721/6e83c17e-21bd-4e0a-826b-02fad9c21ec6
After
https://github.com/tldraw/tldraw/assets/2523721/29359936-b673-4583-89c8-6d1728ab338c
### Change Type
- [x] `patch` — Bug fix
- [ ] `minor` — New feature
- [ ] `major` — Breaking change
- [ ] `dependencies` — Changes to package dependencies[^1]
- [ ] `documentation` — Changes to the documentation only[^2]
- [ ] `tests` — Changes to any test code only[^2]
- [ ] `internal` — Any other changes that don't affect the published
package[^2]
- [ ] I don't know
[^1]: publishes a `patch` release, for devDependencies use `internal`
[^2]: will not publish a new version
### Test Plan
1. Create an arrow.
2. You should not see any errors in the console.
---------
Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
Fixes#1996
This fixes a few issues with cloud rendering:
- At small sizes the arcs could get kind of inverted after being
mutated, so you'd end calculating the outline using the large arc
instead of the small arc and it would balloon the size of the bounds
(that was what Mitja was seeing in #1996
- While working on the above I noticed that there are some situations
where we were actually supposed to be using the large arc for rendering
the svg paths but we were using the small arcs instead, making the
bounds appear larger than the cloud shape when in fact the cloud shape
was too small.
- I also fixed some other issues related to rendering clouds with tiny
width/height. It now draws straight lines instead of arcs if the arcs
are essentially flat, and it increases the number of lumps when width or
height are very small to avoid certain kinds of weirdness.
### Change Type
- [x] `patch` — Bug fix
- [ ] `minor` — New feature
- [ ] `major` — Breaking change
- [ ] `dependencies` — Changes to package dependencies[^1]
- [ ] `documentation` — Changes to the documentation only[^2]
- [ ] `tests` — Changes to any test code only[^2]
- [ ] `internal` — Any other changes that don't affect the published
package[^2]
- [ ] I don't know
[^1]: publishes a `patch` release, for devDependencies use `internal`
[^2]: will not publish a new version
### Test Plan
1. Add a step-by-step description of how to test your PR here.
2.
- [ ] Unit Tests
- [ ] End to end tests
### Release Notes
- Improves cloud shape rendering
We were conditionally using hooks, which caused the minified error when
running the prod build of React. We now use hooks before the early
returns.
Fixes [#2001](https://github.com/tldraw/tldraw/issues/2001)
### Change Type
- [x] `patch` — Bug fix
- [ ] `minor` — New feature
- [ ] `major` — Breaking change
- [ ] `dependencies` — Changes to package dependencies[^1]
- [ ] `documentation` — Changes to the documentation only[^2]
- [ ] `tests` — Changes to any test code only[^2]
- [ ] `internal` — Any other changes that don't affect the published
package[^2]
- [ ] I don't know
[^1]: publishes a `patch` release, for devDependencies use `internal`
[^2]: will not publish a new version
This PR prevents certain shapes from being edited while in readonly
mode. It adds `ShapeUtil.canEditInReadOnly` to allow developers to opt
in to editing shapes. It's currently applied only to embed shapes.
### Change Type
- [x] `major`
### Test Plan
1. In a readonly mode, try to edit text / sticky notes / arrow labels
via double click / enter. You should not be able to edit them.
2. Try to edit an embed. You should be able to edit it.
### Release Notes
- Prevent editing text shapes in readonly mode.
@SomeHats I'll leave this assigned to you in case you want to compare
the perf of using consts/lets scoped to the visitor function. Or just do
that anyway regardless of microperf. Either is fine with me.
This PR prevents the escape key from exiting full screen when a shape is
being edited or when shapes are selected. Basically, if the select tool
is going to use the escape key, then don't let it be used for its normal
purpose.
### Change Type
- [x] `patch` — Bug fix
### Test Plan
1. Open a firefox full screen tab.
2. Start editing a text shape.
3. Press escape. It should stop editing.
4. Press escape again. It should deselect the shape.
5. Press escape again. It should exit full screen mode.
This PR hides hovered indicators when using a coarse pointer.
### Change Type
- [x] `patch` — Bug fix
### Test Plan
1. On an iPad or touch device, use the draw tool.
2. Select the select tool.
3. You should not see the hovered indicator on the drawn shape.
### Release Notes
- Hide hovered indicators on mobile / coarse pointer devices.
@steveruizok
I only added one test in the end and then I got distracted by chatting
text stuff
### Change Type
- [x] `tests` — Changes to any test code only[^2]
---------
Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
Closes#1982
When choosing whether to disable the mobile style menu, we now also
check if the select tool is active and whether any shapes have been
selected.
### Change Type
- [x] `patch` — Bug fix
- [ ] `minor` — New feature
- [ ] `major` — Breaking change
- [ ] `dependencies` — Changes to package dependencies[^1]
- [ ] `documentation` — Changes to the documentation only[^2]
- [ ] `tests` — Changes to any test code only[^2]
- [ ] `internal` — Any other changes that don't affect the published
package[^2]
- [ ] I don't know
[^1]: publishes a `patch` release, for devDependencies use `internal`
[^2]: will not publish a new version
### Test Plan
1. On a small screen
2. Choose the select tool
3. Deselect all shapes
4. Click on the disabled style menu button
Expected: Nothing should happen
Actual: The style menu opens
### Release Notes
- When select tool is active, the style menu shouldn't be openable
unless a shape is also selected.
Before/After
<img width="300"
src="https://github.com/tldraw/tldraw/assets/98838967/91ea55c8-0fcc-4f73-b61e-565829a5f25e"
/>
<img width="300"
src="https://github.com/tldraw/tldraw/assets/98838967/ee4070fe-e236-4818-8fb4-43520210102b"
/>
---------
Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
This PR improves pinch events on touch screens.
It tries to avoid zooming unless we're sure that the user is zooming (or
at least, that they've started zooming). It removes behavior that snaps
the pinch to a certain zoom (e.g. 100%, 50%).
### Change Type
- [x] `patch` — Bug fix
### Test Plan
1. On iPad, try to two-finger pan without zooming.
2. Perform a zoom.
3. Perform a two-finger pan, then a zoom.
### Release Notes
- Improve pinch gesture events.
Co-authored-by: Alex Alex@dytry.ch
closes [#1978](https://github.com/tldraw/tldraw/issues/1978)
Text was wrapping on Safari because the measure text div was rendered
differently on different browsers. Interestingly, when forcing the
text-measure div to be visible and on-screen in Chrome, the same
text-wrapping behaviour was apparent. By setting white-space to 'pre'
when width hasn't been set by the user, we can ensure that only line
breaks the user has inputted are rendered by default on all browsers.
### Change Type
- [x] `patch` — Bug fix
- [ ] `minor` — New feature
- [ ] `major` — Breaking change
- [ ] `dependencies` — Changes to package dependencies[^1]
- [ ] `documentation` — Changes to the documentation only[^2]
- [ ] `tests` — Changes to any test code only[^2]
- [ ] `internal` — Any other changes that don't affect the published
package[^2]
- [ ] I don't know
[^1]: publishes a `patch` release, for devDependencies use `internal`
[^2]: will not publish a new version
### Test Plan
1. On Safari
2. Make a new text shape and start typing
3. At a certain point the text starts to wrap without the width having
been set
### Release Notes
- Fix text wrapping differently on Safari and Chrome/Firefox
Before/After
<image width="350"
src="https://github.com/tldraw/tldraw/assets/98838967/320171b4-61e0-4a41-b8d3-830bd90bea65">
<image width="350"
src="https://github.com/tldraw/tldraw/assets/98838967/b42d7156-0ce9-4894-9692-9338dc931b79">
This PR removes the automatic focus events from the editor.
The `autoFocus` prop is now true by default. When true, the editor will
begin in a focused state (`editor.instanceState.isFocused` will be
`true`) and the component will respond to keyboard shortcuts and other
interactions. When false, the editor will begin in an unfocused state
and not respond to keyboard interactions.
**It's now up to the developer** using the component to update
`isFocused` themselves. There's no predictable way to do that on our
side, so we leave it to the developer to decide when to turn on or off
focus for a container (for example, using an intersection observer to
"unfocus" components that are off screen).
### Change Type
- [x] `major` — Breaking change
### Test Plan
1. Open the multiple editors example.
2. Click to focus each editor.
3. Use the keyboard shortcuts to check that the correct editor is
focused.
4. Start editing a shape, then select the other editor. The first
editing shape should complete.
- [x] Unit Tests
- [x] End to end tests
### Release Notes
- [editor] Make autofocus default, remove automatic blur / focus events.
---------
Co-authored-by: David Sheldrick <d.j.sheldrick@gmail.com>
This PR fixes a bug where a touch from a palm received at the start of a
drawing operation, when that operation was the first entry into pen
mode, would cause the line to fail.
### Change Type
- [x] `patch` — Bug fix
### Test Plan
1. On an iPad with a pencil, select the draw tool. Ensure that you're
not yet in pen mode.
2. Place your palm on the iPad and immediately place the pencil on the
screen.
3. Previously, you would get a line between your palm and the pencil
point. Now, you should get only the pencil point.
### Release Notes
- [fix] Accidental palm inputs when using iPad pencil
This PR fixes an issue where the screen bounds could be wrong after
editing text on iOS / mobile.
### Change Type
- [x] `patch` — Bug fix
### Test Plan
1. On iOS, create a text shape at the bottom of the screen.
2. Edit the text shape.
3. Stop editing.
4. Drag a selection box to confirm that the page bounds is still
correct.
This PR has been tested on Mac Chrome, iOS Safari, and Android Chrome.
---
This PR removes 'targeted editing' from text.
This affects when you're:
* using the text tool
* editing a text shape
* editing a text label
* editing an arrow label
When in one of these modes, you were able to click on some other text to
immediately start editing it (as long as that text is the same type).
It was a bit broken with some of the newer changes, so this PR removes
it. The issues included:
* selected text 'flashing'
* caret going to the start of the text
* empty text shapes not disappearing
* inconsistent behaviour when clicking near a shape VS on a shape
It feels a bit simpler now too, I like it... 🤔💭
### Change Type
- [x] `patch` — Bug fix
### Test Plan
- [ ] Unit Tests
- [ ] End to end tests
### Release Notes
- Fixed some cases where text would get selected in the wrong place.
- Changed the behaviour of text selection. Removed 'deep editing'.
---------
Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
This PR fixes some cases where, if a member function (like `onEnter`)
was not an arrow function, it would not run.
### Change Type
- [x] `patch` — Bug fix
This PR makes it so that user preferences can be in a 'null' state,
where we use the default values and/or infer from the system
preferences.
Before this PR it was impossible to allow a user to change their locale
via their system config rather than selecting an explicit value in the
tldraw editor menu. Similarly, it was impossible to adapt to changes in
the user's system preferences for dark/light mode.
That's because we saved the full user preference values the first time
the user loaded tldraw, and the only way for them to change after that
is by saving new values.
After this PR, if a value is `null` we will use the 'default' version of
it, which can be inferred based on the user's system preferences in the
case of dark mode, locale, and animation speed. Then if the user changes
their system config and refreshes the page their changes should be
picked up by tldraw where they previously wouldn't have been.
Dark mode inference is opt-in by setting a prop `inferDarkMode: true` on
the `Editor` instance (and the `<Tldraw />` components), because we
don't want it to be a surprise for existing library users.
### Change Type
- [ ] `patch` — Bug fix
- [ ] `minor` — New feature
- [x] `major` — Breaking change
[^1]: publishes a `patch` release, for devDependencies use `internal`
[^2]: will not publish a new version
closes#1913
Some lines aren't rendering:
<img width="500" alt="shapes"
src="https://github.com/tldraw/tldraw/assets/98838967/bd01bb0f-a967-46ce-9056-a81421224931">
When we begin drawing a line it's nice for the user to be able to see a
dot, so we put down two points. The end point for a new line was set to
the same position as the first point, which was causing a bunch of
divide by zero errors. Offsetting it slightly fixes that.
Now when two handles are too close together we extend the second one
instead of drawing a third. This will probably only ever happen with the
first two points of a line.
### Change Type
- [x] `patch` — Bug fix
- [ ] `minor` — New feature
- [ ] `major` — Breaking change
- [ ] `dependencies` — Changes to package dependencies[^1]
- [ ] `documentation` — Changes to the documentation only[^2]
- [ ] `tests` — Changes to any test code only[^2]
- [ ] `internal` — Any other changes that don't affect the published
package[^2]
- [ ] I don't know
[^1]: publishes a `patch` release, for devDependencies use `internal`
[^2]: will not publish a new version
### Test Plan
1. Select the Line tool and set spline to line and dash to draw
2. Click around the canvas
3. You should now be able to actually see a line
4. Now set spline to cubic and dash to solid
5. shift click around the canvas
6. You should be able to see a line!
### Release Notes
- This PR patches a couple of bugs which led to straight draw lines and
beziered dash lines not rendering on the canvas
Before & After:
<image width="250"
src="https://github.com/tldraw/tldraw/assets/98838967/e0ca7d54-506f-4014-b65a-6b61a98e3665"
/>
<image width="250"
src="https://github.com/tldraw/tldraw/assets/98838967/90c9fa12-1bcb-430d-80c7-97e1faacea16"
/>
---------
Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
