This PR enables cursors for remote participants.
They are shown for 2 seconds when you focus a buffer, and then on hover.
Release Notes:
- Added usernames next to remote cursors
This PR renames the `overflow_hidden_x` and `overflow_hidden_y` methods
to `overflow_x_hidden` and `overflow_y_hidden`, respectively.
This provides consistency with our `overflow_x_scroll` /
`overflow_y_scroll` methods, as well as better matches Tailwind's
naming.
Release Notes:
- N/A
I'm not yet sure whether this is 100% correct, but it seems to alleviate
the following issue:
`When opening a dock, the panel doesn't appear right away. An empty dock
is briefly visible.`
Release Notes:
- Fixed panel layout being incorrect for a brief time after opening
(fixes https://github.com/zed-industries/community/issues/2415)
Also, some fun test helpers
Co-Authored-By: Mikayla <mikayla@zed.dev>
You can now use .debug_selector() to make it possible for tests to find
a given element,
and .debug_bounds() to find the coordinates of where it was painted.
Release Notes:
- (Added|Fixed|Improved) ...
([#<public_issue_number_if_exists>](https://github.com/zed-industries/community/issues/<public_issue_number_if_exists>)).
Adding the typos crate to our CI will take some doing, as we have
several tests which rely on typos in various ways (e.g. checking state
as the user types), but I thought I'd take a first stab at fixing what
it finds.
Release Notes:
- N/A
When the `List` element's state is `ListState::reset()`, it eagerly
trashes it's cached element heights in anticipation of a prompt render.
But, due to the recent `display_layer` changes, that re-render is not
always forthcoming. This is a problem for `ListState::scroll()`, which
depends on these cached elements to correctly calculate the new logical
scroll offset.
Solutions we attempted:
- Cache the element heights and continue the scroll calculation
- This was conceptually incorrect, reset should only be called when the
underlying data has been changed, making any calculation with the old
results meaningless.
- Lazily re-compute the element heights in scroll
- Beyond being a non-trivial refactor, this would probably also cause us
to double-render the list in a single frame, which is bad.
- Cache the scroll offset and only calculate it in paint
- This solution felt awkward to implement and meant we can't supply
synchronous list scroll events.
- Delay resetting until paint
- This means that all of the other APIs that `ListState` supplies would
give temporarily incorrect results, worsening the problem
Given these issues, we settled on the solution with the least
compromises: drop scroll events if the state has been `reset()` between
`paint()` and `scroll()`. This shifts the responsibility for the problem
out of the List element and into consumers of `List`, if you want
perfectly smooth scrolling then you need to use `reset()` judiciously
and prefer `splice()`.
That said, I tested this by aggressively scrolling the Collab panel, and
it seems to work as well as it did before.
This PR also includes some initial testing infrastructure for working
with input from the platform and rendered elements.
Release Notes:
- N/A
Before this change we wouldn't submit all possible primitives of the
same kind that are less-than the max order.
Result was that we would submit, say, 10 paths each in a separate batch
instead of actually batching them.
This was overly strict because even if the order of two different
primitives was the same, we could have still batched the 1st primitive
kind, if its implicit ordering was less than 2nd kind.
Example: say we have the following primitives and these orders
5x paths, order 3
2x sprites, order 3
Previously, we would submit 1 path, 1 path, 1 path, 1 path, 1 path, then
the sprites.
With this changes, we batch the 5 paths into one batch.
Co-authored-by: Antonio <antonio@zed.dev>
Previously, we were using `size_of` but passing the wrong type in
(MonochromeSprite instead of PathSprite). This caused us to read outside
of the `sprites` smallvec and triggered the segfault.
We're occasionally seeing a crash in MetalRenderer::draw.
Looking at the backtrace, it seems almost certainly to be happening in
the call to `ptr::copy_nonoverlapping` on line 604 (see `#Don't Panic!`
channel notes)
As we already have added bounds checking to the destination, it seems
most
likely (however improbable) that somehow we're getting an invalid Ptr
and
length from the SmallVec.
To try and make progress on this, let's try a Vec for a bit lest there
is a subtle issue in SmallVec (though I couldn't spot one).
Release Notes:
- (maybe) Fixes SEGFAULT in MetalRenderer::draw
According to Chromium source, `NSScreen::screens` should always get us
one display.
We made this change because we ran into panics caused by the previous
`unwrap()` when `CGGetActiveDisplayList` might return an empty list.
Previously we called CGGetActiveDisplayList twice: once to get the
number of displays and then to get the displays.
We saw a panic due to no displays being returned here. As a first
attempt to fix the panic, we're reducing the amount of calls to
CGGetActiveDisplayList and just do one with the trade-off being that we
pre-allocate 32 pointers in a Vec.
Now that views are cached, we need to explicitly `.notify()` text
editors when the buffer font size changes.
* [x] Notify editors when settings change, or adjusting buffer font size
* [x] Figure out why non-focused editors still do not re-render when
adjusting buffer font size
* [x] Reset buffer font size adjustment when the size is updated in the
user's settings
