This unblocks work on new debugger UI, where we don't want the
set_active function to be called unconditionally.
Release Notes:
- N/A
---------
Co-authored-by: Anthony Eid <hello@anthonyeid.me>
Part of #27171
Follows-up the change in
https://github.com/zed-industries/zed/pull/22346 to consider the case
where the assistant-panel is disabled via settings (as also noted in
[this
comment](https://github.com/zed-industries/zed/pull/22346#issuecomment-2558372412),
Notably, only the explicit case is considered here. Can extend this
change to also cover the implicit case where the button is disabled if
requested.).
Currently, if the user toggles the right dock, the assistant panel will
be shown even if it is disabled via settings, because it has the highest
priority (see
https://github.com/zed-industries/zed/pull/22346#issuecomment-2564890493).
With this change, the assistant panel is no longer activated when
disabled and the dock with the next highest activation order is
activated instead.
I did not opt in to make the priority configurabe, as I agree with
https://github.com/zed-industries/zed/pull/22346#issuecomment-2564890493
that this will most likely rarely be used (the active panel is only none
on the first toggle of the dock, afterwards it remains set for the
remainder of the session).
Release Notes:
- `workspace::ToggleRightDock` will no longer open the assistant panel
when it is disabled via settings.
In the left hand status bar, there are two groups of buttons. There was
a border between the two hardcoded on the first button of the second
group, however, if all buttons in the first group are hidden, the border
doesn't need to be rendered.
(Not handled in this PR) A potentially better approach would be to
change StatusBar's definition from `left_items` and `right_items` to
`left_groups` and `right_groups`, and render dividers between each group
of items. That seemed like a bigger refactor than I wanted to handle for
now, but is an option for the future.
If you use these settings on `main`, the border will show, but with
nothing to the left of it.
```json
{
"collaboration_panel": {
"button": false
},
"outline_panel": {
"button": false
},
"project_panel": {
"button": false,
},
}
```
Screenshots:
Before:
<img width="117" alt="Screenshot 2025-02-02 at 6 19 24 PM"
src="https://github.com/user-attachments/assets/b3401b47-6172-4392-9277-31aa1affaf7a"
/>
<img width="134" alt="Screenshot 2025-02-02 at 6 20 12 PM"
src="https://github.com/user-attachments/assets/1e8caee6-1da8-47f6-8499-9a93b6d8fa27"
/>
After:
<img width="125" alt="Screenshot 2025-02-02 at 6 19 58 PM"
src="https://github.com/user-attachments/assets/9b9f421c-660b-41cb-80e0-acb774c66054"
/>
<img width="132" alt="Screenshot 2025-02-02 at 6 20 20 PM"
src="https://github.com/user-attachments/assets/87e0e475-084b-44df-b820-573c68728c1a"
/>
Release Notes:
- Conditionally render divider in status bar
---------
Co-authored-by: Danilo Leal <67129314+danilo-leal@users.noreply.github.com>
There's still a bit more work to do on this, but this PR is compiling
(with warnings) after eliminating the key types. When the tasks below
are complete, this will be the new narrative for GPUI:
- `Entity<T>` - This replaces `View<T>`/`Model<T>`. It represents a unit
of state, and if `T` implements `Render`, then `Entity<T>` implements
`Element`.
- `&mut App` This replaces `AppContext` and represents the app.
- `&mut Context<T>` This replaces `ModelContext` and derefs to `App`. It
is provided by the framework when updating an entity.
- `&mut Window` Broken out of `&mut WindowContext` which no longer
exists. Every method that once took `&mut WindowContext` now takes `&mut
Window, &mut App` and every method that took `&mut ViewContext<T>` now
takes `&mut Window, &mut Context<T>`
Not pictured here are the two other failed attempts. It's been quite a
month!
Tasks:
- [x] Remove `View`, `ViewContext`, `WindowContext` and thread through
`Window`
- [x] [@cole-miller @mikayla-maki] Redraw window when entities change
- [x] [@cole-miller @mikayla-maki] Get examples and Zed running
- [x] [@cole-miller @mikayla-maki] Fix Zed rendering
- [x] [@mikayla-maki] Fix todo! macros and comments
- [x] Fix a bug where the editor would not be redrawn because of view
caching
- [x] remove publicness window.notify() and replace with
`AppContext::notify`
- [x] remove `observe_new_window_models`, replace with
`observe_new_models` with an optional window
- [x] Fix a bug where the project panel would not be redrawn because of
the wrong refresh() call being used
- [x] Fix the tests
- [x] Fix warnings by eliminating `Window` params or using `_`
- [x] Fix conflicts
- [x] Simplify generic code where possible
- [x] Rename types
- [ ] Update docs
### issues post merge
- [x] Issues switching between normal and insert mode
- [x] Assistant re-rendering failure
- [x] Vim test failures
- [x] Mac build issue
Release Notes:
- N/A
---------
Co-authored-by: Antonio Scandurra <me@as-cii.com>
Co-authored-by: Cole Miller <cole@zed.dev>
Co-authored-by: Mikayla <mikayla@zed.dev>
Co-authored-by: Joseph <joseph@zed.dev>
Co-authored-by: max <max@zed.dev>
Co-authored-by: Michael Sloan <michael@zed.dev>
Co-authored-by: Mikayla Maki <mikaylamaki@Mikaylas-MacBook-Pro.local>
Co-authored-by: Mikayla <mikayla.c.maki@gmail.com>
Co-authored-by: joão <joao@zed.dev>
This Pull Request introduces a new command `workspace: move focused
panel to next position` which finds the currently focused panel, if such
panel exists, and moves it to the next valid dock position, following
the order of `Left → Bottom → Right` and then starting again from the
left position.
In order to achieve this the following changes have been introduced:
* Add a new default implementation for `PanelHandle`, namely
`PanelHandle::move_to_next_position` which leverages
`PanelHandle::position`, `PanelHandle::position_is_valid` and
`PanelHandle::set_position` methods to update the panel's position to
the next valid position.
* Add a new method to the `workspace` module, `
move_focused_panel_to_next_position`, which is responsible for finding
the currently focused panel, if such a panel exists, and calling the
`move_to_next_position` method in the panel's handle.
* Add a new action to the `workspace` module,
`MoveFocusedPanelToNextPosition`, which is handled by the
`move_focused_panel_to_next_position` method.
Tests have also been added to the `workspace` module in order to
guarantee that the action is correctly updating the focused panel's
position.
Here's a quick video of it, in action 🔽https://github.com/user-attachments/assets/264d382b-5239-40aa-bc5e-5d569dec0734Closes#23115
Release Notes:
- Added new command to move the focused panel to the next valid dock
position – `workspace: move focused panel to next position` .
A recent change in #22730 (to reduce workspace serialization) means that
a dock "forgets" its active panel whenever it is closed. When opened
again, the change in #22346 (which establishes a panel activation order)
takes effect, always opening the highest-priority panel for that dock
instead of the panel the user previously manually activated.
The result is that if you have, say, the outline panel active on the
right dock, and toggle the dock closed and then back open again, the
assistant panel will always appear instead.
This PR reverts part of the change in #22730 to ensure a dock remembers
its active panel when it is closed.
Closes#22923.
Release Notes:
- Fixed an issue where docks did not remember the active panel.
Part of https://github.com/zed-industries/zed/issues/16472
Reduces amount of workspace serialization happening by:
* fixing the deserialization logic: now it does not set panels that are
hidden to active
* cleaning up `active_panel_index` for docks that are closed, to avoid
emitting extra events for such closed docks
* adjusting outline panel to drop active editor subscriptions on
deactivation — this way, `cx.observe` on the dock with outline panel is
not triggered (used to be triggered on every selection change before)
* adjusting workspace dock drag listener to remember previous
coordinates and only resize the dock if those had changed
* adjusting workspace pane event listener to ignore
`pane::Event::UserSavedItem` and `pane::Event::ChangeItemTitle` that
seem to happen relatively frequently but not influence values that are
serialized for the workspace
* not using `cx.observe` on docks, instead explicitly serializing on
panel zoom and size changes
Release Notes:
- Reduced amount of workspace serialization happening
This means that `workspace::ToggleRightDock` will open the assistant if
no right-dock panel has been manually activated, instead of the chat as
before. Also cleans up the `active_panel_index` logic a bit.
cc @nathansobo
Release Notes:
- Make `workspace::ToggleRightDock` open the assistant panel if no
right-dock panel has yet been activated
- Adds the Switch component
- Updates `Selected`, `Selectable` -> `ToggleState`, `Toggleable`
- Adds `checkbox` and `switch` functions to align better with other
elements in our layout system.
We decided not to merge Switch and Checkbox. However, in a followup I'll
introduce a Toggle or AnyToggle enum so we can update
`CheckboxWithLabel` -> `ToggleWithLabel` as this component will work
exactly the same with either a Checkbox or a Switch.
Release Notes:
- N/A
Closes#20593
Release Notes:
- Fixed a bug where it is possible to get in near-unrecoverable panel
state by resizing the panel past the edge of the workspace.
Co-authored-by: Trace <violet.white.batt@gmail.com>
This PR introduces a new parameter for `on_drag` in gpui, which is an
offset from the element origin to the mouse event origin.
Release Notes:
- Fixed rendering of dragged project panel entries
Also change Zed's standard style to use
`.track_focus(&self.focus_handle(cx))`, instead of
`.track_focus(&self.focus_handle)`, to catch these kinds of errors more
easily in the future.
Release Notes:
- N/A
---------
Co-authored-by: Conrad <conrad@zed.dev>
Release Notes:
- Added support for following into the assistant panel.
---------
Co-authored-by: Max <max@zed.dev>
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
Co-authored-by: Nathan <nathan@zed.dev>
In the latest update, panel loading occasionally occurred randomly,
either before or after workspace deserialization due to their
asynchronous nature. This update addresses the issue by ensuring panels
restore their state based on serialized data, synchronizing their
loading with workspace deserialization.
Release Notes:
- Fixed [#9638](https://github.com/zed-industries/zed/issues/9638)
- Fixed [#12954](https://github.com/zed-industries/zed/issues/12954)
This PR makes the `border` methods require an explicit width instead of
defaulting to 1px.
This breaks convention with Tailwind, but it makes GPUI more consistent
with itself. We already have an edge case where the parameterized method
had to be named `border_width`, since `border` was taken up by an alias
for the 1px variant.
### Before
```rs
div()
.border()
.border_t()
.border_r()
.border_b()
.border_l()
.border_width(px(7.))
```
### After
```rs
div()
.border_1()
.border_t_1()
.border_r_1()
.border_b_1()
.border_l_1()
.border(px(7.))
```
Release Notes:
- N/A
This PR includes two relevant changes:
- Platform binds (super, windows, cmd) will now parse on all platforms,
regardless of which one is being used. While very counter-intuitive
(this means that `cmd-d` will actually be triggered by `win-d` on
windows) this makes it possible to reuse keymap files across platforms
easily
- There is now a KeyContext `os == linux`, `os == macos` or `os ==
windows` available in keymaps. This allows users to specify certain
blocks of keybinds only for one OS, allowing you to minimize the amount
of keymappings that you have to re-configure for each platform.
Release Notes:
- Added `os` KeyContext, set to either `linux`, `macos` or `windows`
- Fixed keymap parsing errors when `cmd` was used on linux, `super` was
used on mac, etc.
Also, add a `deferred` function which takes an element to paint after
the current element tree.
Release Notes:
- Improved the size and position of the hitbox for resizing left, right,
and bottom panels.
([#8855](https://github.com/zed-industries/zed/issues/8855))
Co-authored-by: Julia <julia@zed.dev>
Co-authored-by: Nathan <nathan@zed.dev>
See https://zed.dev/channel/gpui-536
Fixes https://github.com/zed-industries/zed/issues/9010
Fixes https://github.com/zed-industries/zed/issues/8883
Fixes https://github.com/zed-industries/zed/issues/8640
Fixes https://github.com/zed-industries/zed/issues/8598
Fixes https://github.com/zed-industries/zed/issues/8579
Fixes https://github.com/zed-industries/zed/issues/8363
Fixes https://github.com/zed-industries/zed/issues/8207
### Problem
After transitioning Zed to GPUI 2, we started noticing that interacting
with the mouse on many UI elements would lead to a pretty annoying
flicker. The main issue with the old approach was that hover state was
calculated based on the previous frame. That is, when computing whether
a given element was hovered in the current frame, we would use
information about the same element in the previous frame.
However, inspecting the previous frame tells us very little about what
should be hovered in the current frame, as elements in the current frame
may have changed significantly.
### Solution
This pull request's main contribution is the introduction of a new
`after_layout` phase when redrawing the window. The key idea is that
we'll give every element a chance to register a hitbox (see
`ElementContext::insert_hitbox`) before painting anything. Then, during
the `paint` phase, elements can determine whether they're the topmost
and draw their hover state accordingly.
We are also removing the ability to give an arbitrary z-index to
elements. Instead, we will follow the much simpler painter's algorithm.
That is, an element that gets painted after will be drawn on top of an
element that got painted earlier. Elements can still escape their
current "stacking context" by using the new `ElementContext::defer_draw`
method (see `Overlay` for an example). Elements drawn using this method
will still be logically considered as being children of their original
parent (for keybinding, focus and cache invalidation purposes) but their
layout and paint passes will be deferred until the currently-drawn
element is done.
With these changes we also reworked geometry batching within the
`Scene`. The new approach uses an AABB tree to determine geometry
occlusion, which allows the GPU to render non-overlapping geometry in
parallel.
### Performance
Performance is slightly better than on `main` even though this new
approach is more correct and we're maintaining an extra data structure
(the AABB tree).
Release Notes:
- Fixed a bug that was causing popovers to flicker.
---------
Co-authored-by: Nathan Sobo <nathan@zed.dev>
Co-authored-by: Thorsten <thorsten@zed.dev>
Fixes: #8050
For some reason that we didn't investigate, if you have view caching
enabled,
and you have non-integer sized bounds, and you are right aligning
things, the
co-ordinates can differ by +/- 1px when using the cached view.
The easiest fix for now is to just not do that.
Co-Authored-By: Antonio <as-cii@zed.dev>
Release Notes:
- Fixed the pane icons flickering
([#8050](https://github.com/zed-industries/zed/issues/8050)).
Co-authored-by: Antonio <as-cii@zed.dev>
Part of #7108
This PR includes just the static runnables part. We went with **not**
having a dedicated panel for runnables.
This is just a 1st PR out of N, as we want to start exploring the
dynamic runnables front. Still, all that work is going to happen once
this gets merged.
Release Notes:
- Added initial, static Runnables support to Zed. Such runnables are defined in
`runnables.json` file (accessible via `zed: open runnables` action) and
they can be spawned with `runnables: spawn` action.
---------
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Co-authored-by: Pitor <pitor@zed.dev>
Co-authored-by: Beniamin <beniamin@zagan.be>
This adds the ability to navigate to/from docks (Terminal, Project,
Collaboration, Assistant) via keybindings.
When using the `ActivatePaneInDirection` keybinding from the
left/bottom/right dock, we check whether the movement is towards the
center panel. If it is, we focus the last active pane.
Fixes https://github.com/zed-industries/zed/issues/6833 and it came up
in a few other tickes/discussions.
Release Notes:
- Added ability to navigate to docks and back to the editor using the
`workspace::ActivatePaneInDirection` action (by default bound to `Ctrl-w
[hjkl]` in Vim mode).
([#6833](https://github.com/zed-industries/zed/issues/6833)).
## Drawback
There's this weird behavior: if you start Zed and no files are opened,
you focus terminal, go left (project panel), then back to right to
terminal, the terminal isn't focused. Even though we focus it in the
code.
Maybe this is a bug in the current focus handling code?
## Demo
https://github.com/zed-industries/zed/assets/1185253/5d56db40-36aa-4758-a3bc-7a0de20ce5d7
---------
Co-authored-by: Piotr <piotr@zed.dev>
In the old world, panel loading happened strictly before workspace
deserialization. Now it's inverted.
Fix this by storing on the dock the serialized state so they can restore
state as panels are loaded.
This PR renames the `h_stack` and `v_stack` to `h_flex` and `v_flex`,
respectively.
We were previously using `h_stack` and `v_stack` to match SwiftUI, but
`h_flex` and `v_flex` fit better with the web/flexbox terminology that
the rest of GPUI uses.
Additionally, we were already calling the utility functions used to
implement `h_stack` and `v_stack` by the new names.
Release Notes:
- N/A
This PR renames the `IconElement` component to just `Icon`.
This better matches the rest of our components, as `IconElement` was the
only one using this naming convention.
The `Icon` enum has been renamed to `IconName` to free up the name.
I was trying to come up with a way that would allow rendering an
`Icon::Zed` directly (and thus make the `IconElement` a hidden part of
the API), but I couldn't come up with a way to do this cleanly.
Release Notes:
- N/A
