-
Notifications
You must be signed in to change notification settings - Fork 3.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gpui: Fix window display on Windows #18705
gpui: Fix window display on Windows #18705
Conversation
This comment was marked as off-topic.
This comment was marked as off-topic.
winit does create windows using the |
I've verified that this fixes the reported problem. I have no idea if it's the correct way to solved it. |
This comment was marked as off-topic.
This comment was marked as off-topic.
Tested is working |
I had the same issue "no Window after Build Process" can confirm that this fix works too. |
still turn on error as below: |
this error is not related to this issue |
Any timeframe for when this gets merged? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have no clue about these changes, but given the previous change got merged and this is tested by others and reported to be fixing the issue, let's merge this and @mikayla-maki can post-review if needed.
Odd that I have never experienced that in my Windows builds.
最近更新编译,在windows下,没办法保存正确的窗口大小,没办法最大化,删除db,也是一样。 大佬能不能增加个兼容一下,老旧设备不支持vulkan的问题呢。 |
I will open a PR to address this tomorrow.
The only possible solution is porting the backend from blade to directX, but zed team rejected my PR of porting to directX. So, I can’t, sorry. |
Closes #18705 (comment) This PR fixes the issue where the Zed window was not displaying correctly on launch. Now, when Zed is closed in a maximized state, it will reopen in a maximized state. On macOS, when a window is created but not yet visible, calling `zoom` or `toggle_fullscreen` will still affect the hidden window. However, this behavior is different on Windows, so special handling is required. Also, since #18705 hasn't been reviewed yet, I'm not sure if this PR should be merged now or if it should wait until #18705 is reviewed first. Release Notes: - N/A
- Closes zed-industries#18610 This PR addresses the same issue as PR zed-industries#18578. After a full day of research and testing, I believe I’ve found the best solution to resolve this issue. With this PR, the window creation behavior on Windows becomes more consistent with macOS: - When `params.show` is `true`: The window is created and immediately displayed. - When `params.show` is `false`: The window is created but remains hidden until the first call to `activate_window`. As I mentioned in zed-industries#18578, `winit` creates hidden windows by setting the window's `exstyle` to `WS_EX_NOACTIVATE | WS_EX_TRANSPARENT | WS_EX_LAYERED | WS_EX_TOOLWINDOW`, which is different from the method used in this PR. Here, the window is created with normal parameters, but we do not call `ShowWindow` so the window is not shown. I'm not sure why `winit` doesn't use a smilliar approach like this PR to create hidden windows. My guess is that `winit` is creating this hidden window to function as a "DispatchWindow" — serving a purpose similar to `WindowsPlatform` in `zed`. To ensure the window stays hidden even if `ShowWindow` is called, they use the `exstyle` approach. With the method used in this PR, my initial tests haven't revealed any issues. Release Notes: - N/A
…s#19124) Closes zed-industries#18705 (comment) This PR fixes the issue where the Zed window was not displaying correctly on launch. Now, when Zed is closed in a maximized state, it will reopen in a maximized state. On macOS, when a window is created but not yet visible, calling `zoom` or `toggle_fullscreen` will still affect the hidden window. However, this behavior is different on Windows, so special handling is required. Also, since zed-industries#18705 hasn't been reviewed yet, I'm not sure if this PR should be merged now or if it should wait until zed-industries#18705 is reviewed first. Release Notes: - N/A
This PR addresses the same issue as PR #18578. After a full day of research and testing, I believe I’ve found the best solution to resolve this issue. With this PR, the window creation behavior on Windows becomes more consistent with macOS:
params.show
istrue
: The window is created and immediately displayed.params.show
isfalse
: The window is created but remains hidden until the first call toactivate_window
.As I mentioned in #18578,
winit
creates hidden windows by setting the window'sexstyle
toWS_EX_NOACTIVATE | WS_EX_TRANSPARENT | WS_EX_LAYERED | WS_EX_TOOLWINDOW
, which is different from the method used in this PR. Here, the window is created with normal parameters, but we do not callShowWindow
so the window is not shown.I'm not sure why
winit
doesn't use a smilliar approach like this PR to create hidden windows. My guess is thatwinit
is creating this hidden window to function as a "DispatchWindow" — serving a purpose similar toWindowsPlatform
inzed
. To ensure the window stays hidden even ifShowWindow
is called, they use theexstyle
approach.With the method used in this PR, my initial tests haven't revealed any issues.
Release Notes: