workspace: Make title bar pickers render nearby the trigger when mouse-triggered#45361
Merged
danilo-leal merged 4 commits intomainfrom Dec 19, 2025
Merged
workspace: Make title bar pickers render nearby the trigger when mouse-triggered#45361danilo-leal merged 4 commits intomainfrom
danilo-leal merged 4 commits intomainfrom
Conversation
This was referenced Dec 30, 2025
danilo-leal
added a commit
that referenced
this pull request
Jan 5, 2026
This PR essentially removes the logic I introduced in #45361 to position workspace modals based on the pointer click coordinates. All of this code has become unnecessary given in #45924 we made the remote, project, and branch modals use popovers when triggered with a pointer, which already handle all the anchored positioning based on the trigger (much better). Release Notes: - N/A
rtfeldman
pushed a commit
that referenced
this pull request
Jan 5, 2026
…e-triggered (#45361) From Zed's title bar, you can click on buttons to open three modal pickers: remote projects, projects, and branches. All of these pickers use the modal layer, which by default, renders them centered on the UI. However, a UX issue we've been bothered by is that when you _click_ to open them, they show up just way too far from where your mouse likely is (nearby the trigger you just clicked). So, this PR introduces a `ModalPlacement` enum to the modal layer, so that we can pick between the "centered" and "anchored" options to render the picker. This way, we can make the pickers use anchored positioning when triggered through a mouse click and use the default centered positioning when triggered through the keybinding. One thing to note is that the anchored positioning here is not as polished as regular popovers/dropdowns, because it simply uses the x and y coordinates of the click to place the picker as opposed to using GPUI's `Corner` enum, thus making them more connected to their triggers. I chose to do it this way for now because it's a simpler and more contained change, given it wouldn't require a tighter connection at the code level between trigger and picker. But maybe we will want to do that in the near future because we can bake in some other related behaviors like automatically hiding the button trigger tooltip if the picker is open and changing its text color to communicate which button triggered the open picker. https://github.com/user-attachments/assets/30d9c26a-24de-4702-8b7d-018b397f77e1 Release Notes: - Improved the UX of title bar modal pickers (remote projects, projects, and branches) by making them open closer to the trigger when triggering them with the mouse.
rtfeldman
pushed a commit
that referenced
this pull request
Jan 5, 2026
This PR essentially removes the logic I introduced in #45361 to position workspace modals based on the pointer click coordinates. All of this code has become unnecessary given in #45924 we made the remote, project, and branch modals use popovers when triggered with a pointer, which already handle all the anchored positioning based on the trigger (much better). Release Notes: - N/A
LivioGama
pushed a commit
to LivioGama/zed
that referenced
this pull request
Jan 20, 2026
…e-triggered (zed-industries#45361) From Zed's title bar, you can click on buttons to open three modal pickers: remote projects, projects, and branches. All of these pickers use the modal layer, which by default, renders them centered on the UI. However, a UX issue we've been bothered by is that when you _click_ to open them, they show up just way too far from where your mouse likely is (nearby the trigger you just clicked). So, this PR introduces a `ModalPlacement` enum to the modal layer, so that we can pick between the "centered" and "anchored" options to render the picker. This way, we can make the pickers use anchored positioning when triggered through a mouse click and use the default centered positioning when triggered through the keybinding. One thing to note is that the anchored positioning here is not as polished as regular popovers/dropdowns, because it simply uses the x and y coordinates of the click to place the picker as opposed to using GPUI's `Corner` enum, thus making them more connected to their triggers. I chose to do it this way for now because it's a simpler and more contained change, given it wouldn't require a tighter connection at the code level between trigger and picker. But maybe we will want to do that in the near future because we can bake in some other related behaviors like automatically hiding the button trigger tooltip if the picker is open and changing its text color to communicate which button triggered the open picker. https://github.com/user-attachments/assets/30d9c26a-24de-4702-8b7d-018b397f77e1 Release Notes: - Improved the UX of title bar modal pickers (remote projects, projects, and branches) by making them open closer to the trigger when triggering them with the mouse.
LivioGama
pushed a commit
to LivioGama/zed
that referenced
this pull request
Jan 20, 2026
…ries#46047) This PR essentially removes the logic I introduced in zed-industries#45361 to position workspace modals based on the pointer click coordinates. All of this code has become unnecessary given in zed-industries#45924 we made the remote, project, and branch modals use popovers when triggered with a pointer, which already handle all the anchored positioning based on the trigger (much better). Release Notes: - N/A
LivioGama
pushed a commit
to LivioGama/zed
that referenced
this pull request
Jan 20, 2026
…e-triggered (zed-industries#45361) From Zed's title bar, you can click on buttons to open three modal pickers: remote projects, projects, and branches. All of these pickers use the modal layer, which by default, renders them centered on the UI. However, a UX issue we've been bothered by is that when you _click_ to open them, they show up just way too far from where your mouse likely is (nearby the trigger you just clicked). So, this PR introduces a `ModalPlacement` enum to the modal layer, so that we can pick between the "centered" and "anchored" options to render the picker. This way, we can make the pickers use anchored positioning when triggered through a mouse click and use the default centered positioning when triggered through the keybinding. One thing to note is that the anchored positioning here is not as polished as regular popovers/dropdowns, because it simply uses the x and y coordinates of the click to place the picker as opposed to using GPUI's `Corner` enum, thus making them more connected to their triggers. I chose to do it this way for now because it's a simpler and more contained change, given it wouldn't require a tighter connection at the code level between trigger and picker. But maybe we will want to do that in the near future because we can bake in some other related behaviors like automatically hiding the button trigger tooltip if the picker is open and changing its text color to communicate which button triggered the open picker. https://github.com/user-attachments/assets/30d9c26a-24de-4702-8b7d-018b397f77e1 Release Notes: - Improved the UX of title bar modal pickers (remote projects, projects, and branches) by making them open closer to the trigger when triggering them with the mouse.
LivioGama
pushed a commit
to LivioGama/zed
that referenced
this pull request
Jan 20, 2026
…ries#46047) This PR essentially removes the logic I introduced in zed-industries#45361 to position workspace modals based on the pointer click coordinates. All of this code has become unnecessary given in zed-industries#45924 we made the remote, project, and branch modals use popovers when triggered with a pointer, which already handle all the anchored positioning based on the trigger (much better). Release Notes: - N/A
LivioGama
pushed a commit
to LivioGama/zed
that referenced
this pull request
Feb 15, 2026
…e-triggered (zed-industries#45361) From Zed's title bar, you can click on buttons to open three modal pickers: remote projects, projects, and branches. All of these pickers use the modal layer, which by default, renders them centered on the UI. However, a UX issue we've been bothered by is that when you _click_ to open them, they show up just way too far from where your mouse likely is (nearby the trigger you just clicked). So, this PR introduces a `ModalPlacement` enum to the modal layer, so that we can pick between the "centered" and "anchored" options to render the picker. This way, we can make the pickers use anchored positioning when triggered through a mouse click and use the default centered positioning when triggered through the keybinding. One thing to note is that the anchored positioning here is not as polished as regular popovers/dropdowns, because it simply uses the x and y coordinates of the click to place the picker as opposed to using GPUI's `Corner` enum, thus making them more connected to their triggers. I chose to do it this way for now because it's a simpler and more contained change, given it wouldn't require a tighter connection at the code level between trigger and picker. But maybe we will want to do that in the near future because we can bake in some other related behaviors like automatically hiding the button trigger tooltip if the picker is open and changing its text color to communicate which button triggered the open picker. https://github.com/user-attachments/assets/30d9c26a-24de-4702-8b7d-018b397f77e1 Release Notes: - Improved the UX of title bar modal pickers (remote projects, projects, and branches) by making them open closer to the trigger when triggering them with the mouse.
LivioGama
pushed a commit
to LivioGama/zed
that referenced
this pull request
Feb 15, 2026
…ries#46047) This PR essentially removes the logic I introduced in zed-industries#45361 to position workspace modals based on the pointer click coordinates. All of this code has become unnecessary given in zed-industries#45924 we made the remote, project, and branch modals use popovers when triggered with a pointer, which already handle all the anchored positioning based on the trigger (much better). Release Notes: - N/A
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
From Zed's title bar, you can click on buttons to open three modal pickers: remote projects, projects, and branches. All of these pickers use the modal layer, which by default, renders them centered on the UI. However, a UX issue we've been bothered by is that when you click to open them, they show up just way too far from where your mouse likely is (nearby the trigger you just clicked). So, this PR introduces a
ModalPlacementenum to the modal layer, so that we can pick between the "centered" and "anchored" options to render the picker. This way, we can make the pickers use anchored positioning when triggered through a mouse click and use the default centered positioning when triggered through the keybinding.One thing to note is that the anchored positioning here is not as polished as regular popovers/dropdowns, because it simply uses the x and y coordinates of the click to place the picker as opposed to using GPUI's
Cornerenum, thus making them more connected to their triggers. I chose to do it this way for now because it's a simpler and more contained change, given it wouldn't require a tighter connection at the code level between trigger and picker. But maybe we will want to do that in the near future because we can bake in some other related behaviors like automatically hiding the button trigger tooltip if the picker is open and changing its text color to communicate which button triggered the open picker.Screenshot.2025-12-19.at.10.17.mp4
Release Notes: