Jason Lee d4ddc4c62c gpui: Fix cx.bounds, cx.open_window position on macOS (#14044)
Release Notes:

- gpui: Fixed `cx.bounds` method to get correct `y` position on macOS.
- gpui: Fixed `cx.open_window` position when macOS Dock is existed.
- Fixed call notification and reopen window position.

## Before


![image](https://github.com/zed-industries/zed/assets/5518/4a435ffd-d7ef-4de7-a7de-44d21db4a719)


https://github.com/zed-industries/zed/assets/5518/ab925779-4253-4b27-9084-01023888087f


## After

<img width="533" alt="image"
src="https://github.com/zed-industries/zed/assets/5518/142e9aaa-ae82-4a72-9acf-04097c545bf0">


https://github.com/zed-industries/zed/assets/5518/8793824a-8b74-4913-8204-7b39649aeeed


---

The case is I have made a Popover by use child window, the coordinate of
the window is always can't placement a right position.

So, I make this example to test the `cx.bounds` and set bounds to
window.

---

By this test, is the `cx.bounds` have a bug?

For example the **Top Left** window, we give it origin (150,150), but it
`cx.bounds()` returns (150,262)

> On the window label, middle line is the `bounds` that we set to the
window, last line is `cx.bounds()` result.

Display 1:

<img width="1512" alt="CleanShot 2024-07-10 at 14 52 26@2x"
src="https://github.com/zed-industries/zed/assets/5518/3adf9e79-f237-431a-a72b-02face7b2361">


---

Or is there something I missed. Is it correct to use `cx.bounds` method
to get the bounds of the current window?

At the same time, I also found that when there are multiple screens, the
information obtained by cx.bounds is very different on different
screens, and it seems that the origin is not relative to the screen.

Display 2:

<img width="2560" alt="SCR-20240710-nkmq"
src="https://github.com/zed-industries/zed/assets/5518/d87d4151-0562-4bf8-b3b3-5da3b4d09d82">
2024-07-10 09:52:33 -06:00
2024-06-14 16:15:13 -06:00
2024-05-15 11:06:05 -06:00
2024-07-05 22:00:18 -04:00
2024-07-09 13:03:53 -07:00
2024-07-09 13:34:32 -06:00
2024-07-09 16:27:55 -04:00
2024-07-09 09:21:42 +02:00
2024-07-01 19:04:58 -04:00
2024-06-25 10:58:11 -04:00
WIP
2023-12-14 09:25:14 -07:00
2024-07-09 09:21:42 +02:00
2024-07-09 09:21:42 +02:00
2024-04-15 14:00:56 -06:00
2024-07-09 14:05:29 -07:00
2024-07-09 09:21:42 +02:00
2024-05-07 09:24:00 -06:00

Zed

CI

Welcome to Zed, a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.


Installation

Packaging status

On macOS and Linux you can download Zed directly or install Zed via your local package manager.

Other platforms are not yet available:

Developing Zed

Contributing

See CONTRIBUTING.md for ways you can contribute to Zed.

Also... we're hiring! Check out our jobs page for open roles.

Licensing

License information for third party dependencies must be correctly provided for CI to pass.

We use cargo-about to automatically comply with open source licenses. If CI is failing, check the following:

  • Is it showing a no license specified error for a crate you've created? If so, add publish = false under [package] in your crate's Cargo.toml.
  • Is the error failed to satisfy license requirements for a dependency? If so, first determine what license the project has and whether this system is sufficient to comply with this license's requirements. If you're unsure, ask a lawyer. Once you've verified that this system is acceptable add the license's SPDX identifier to the accepted array in script/licenses/zed-licenses.toml.
  • Is cargo-about unable to find the license for a dependency? If so, add a clarification field at the end of script/licenses/zed-licenses.toml, as specified in the cargo-about book.
S
Description
GPUI – Community Edition maintained by Oak Team
https://gpui-ce.github.io/
Readme
257 MiB
Languages
Rust 95.5%
WGSL 1.2%
Metal 1.1%
HLSL 1.1%
Python 0.7%
Other 0.3%