ShapedLines are never wrapped, whereas WrappedLines are optionally
wrapped if they are associated with a wrap width. Originally, when
rewriting GPUI, I tried to combine everything because wrapping is
inherently optional for the Text element, but we have a bunch of APIs
that don't make sense on a line that may wrap, so we need a distinct
type for that case.
This is a precursor to implementing clickable links in markdown. I
noticed multiple places where we were confused about whether or not the
line was wrapped so this felt important.
Release Notes:
- N/A
ShapedLines are never wrapped, whereas WrappedLines are optionally wrapped if
they are associated with a wrap width. I tried to combine everything because
wrapping is inherently optional for the Text element, but we have a bunch of
APIs that don't make sense on a line that may wrap, so we need a distinct type
for that case.
Initially, we imagined registering keyboard handlers in the initialize
phase so we would understand the relationships between focus handles
during the layout pass, which would allow us to assign assign `focus_in`
styles that impact layout.
However, we soon realized that many elements aren't created until paint
time anyway, such as within the uniform list. Since it's impossible to
know prior to paint whether an element contains the focused element, it
makes more sense to eliminate the `focus_in` styling helper.
Release Notes:
- N/A
We need to notify when we set the pending mouse down so we attach the
mouse up event listener before the mouse button is released.
Release Notes:
- N/A
This PR takes a different approach to input handling.
Rather than returning the optional input handler, focus handle pair from
the element trait, we instead allow you to register an input handler
imperatively on the window context with `WindowContext::handle_input`.
You pass a focus handle reference and any implementer of
`PlatformInputHandler`. There's an `ElementInputHandler<V>` that
implements `PlatformWindowHandler` so long as `V` implements
`InputHandler`.
Release Notes:
- N/A
This updates our approach to action registration to make it
static/global.
There are 3 different approaches to creating an action, depending on the
complexity of your action's implementation. All of them involve defining
a data type with the correct trait implementations and registering it,
each a bit more powerful / verbose.
* Define a simple list of unit structs that implement `Action` -
`actions!(Foo, Bar, Baz)`
* Make a more complex data type into an action with `#[action]`. This
derives all the necessary traits and registers the action.
```rs
#[action]
struct MoveLeft {
word: true
}
```
* Implement all traits yourself and just register the action with
`#[register_action]`.
Release Notes:
N/A
Previously, when using rounded corners, the borders would get wider.
Looks like we weren't using the input color values consistently in the
fragment shader. The quad values are raw HSLA and are converted in the
vertex shader.
Release Notes:
- N/A
This required using mpsc channels to invoke frame callbacks on the
main thread and send the receiver to the platform display link.
Co-Authored-By: Julia Risley <julia@zed.dev>
The potential for deadlock and other complexity ended up convincing us
that the benefits of making the app state accessible from any thread
were not worth their cost. We probably could have gone back to the old
executors, but we decided to fix forward and continue to get the
benefits of the new dispatcher.
Nathan Sobo
