Fixes https://github.com/zed-industries/zed/issues/33257
Previously, the scale-factor-change-handling logic relied on
`SetWindowPos` enqueuing a `WM_SIZE` window event. But that does not
happen when the window is maximized. So when the scale factor changed,
maximized windows neglected to call their `resize` callback, and would
misinterpret the positions of mouse events.
This PR adds special logic for maximized windows, to ensure that the
size is updated appropriately.
Release Notes:
- N/A
This PR doesn't change any logic, it just cleans up some naming and
style in the windows platform layer.
* Rename `WindowsWindowStatePtr` to `WindowsWindowInner`, since it isn't
a pointer type.
* Move window event handler methods into an impl on this type, so that
all of the `state_ptr: &Rc<WindowsWindowInner>` parameters can just be
replaced with `&self`.
* In window creation, use a `match` instead of a conditional followed by
an unwrap
There's a lot of whitespace in the diff, so view it with `w=1`.
Release Notes:
- N/A
This PR adds more fine-grained handling of the `WM_SETTINGCHANGE`
message.
Plus, we now only trigger the `appearance_changed` callback when the
actual window appearance has changed, rather than calling it every time.
Release Notes:
- N/A
Implements a workaround which removes the `WS_EX_LAYERED` style from the
window right before closing it which seems to fix the window close
animation not playing.
Release Notes:
- N/A
Closes#21700
Release Notes:
- Added caps lock support and show a warning if the user is entering an
SSH password with Caps Lock enabled
---------
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com>
Co-authored-by: 张小白 <364772080@qq.com>
These `if` condition checks were removed in #30828, and this PR adds
them back. This is especially important in the handling of
`WM_NCHITTEST`, where all the calculations are based on the assumption
that `hide_title_bar = true`.
Release Notes:
- N/A
Allows setting element as window control elements which consist of
`Drag`, `Close`, `Max`, or `Min`. This allows you to implement
dynamically sized elements that control the platform window, this is
used for areas such as the title bar. Currently only implemented for
Windows.
Release Notes:
- N/A
This PR improves key handling on Windows by moving the
`TranslateMessage` call from the message loop to after we handled
`WM_KEYDOWN`. This brings Windows behavior more in line with macOS and
gives us finer control over key events. As a result, Vim keybindings now
work properly even when an IME is active. The trade-off is that it might
introduce a slight delay in text input.
Release Notes:
- N/A
Closes#22656
Part of #29144, this PR completely rewrites the key handling logic on
Windows, making it much more consistent with how things work on macOS.
However, one remaining issue is that on Windows, we should be using
`Ctrl+Shift+4` instead of `Ctrl+$`. That part is expected to be
addressed in #29144.
Release Notes:
- N/A
Closes#29117
This makes `window_min_size` work by using the `WM_GETMINMAXINFO` window
message.
Release Notes:
- N/A
---------
Co-authored-by: 张小白 <364772080@qq.com>
While building my own application using GPUI, I found that the `key_up`
event doesn't fire on Windows or macOS, with each platform failing for
different reasons. These events aren't used anywhere in Zed yet, so it
makes sense that the issue hasn't already been caught.
I don't have a Linux machine set up right now, so I don't know if these
events fire correctly on Linux or not.
---
Without this fix, a simple layout like the following:
```rust
div()
.on_key_down(cx.listener(|_, event, _, _| println!("Key down: {:?}", event)))
.on_key_up(cx.listener(|_, event, _, _| println!("Key up: {:?}", event)));
```
...would result in the following logs if the 'a' key was pressed:
```text
Key down: KeyDownEvent { keystroke: Keystroke { modifiers: Modifiers { control: false, alt: false, shift: false, platform: false, function: false }, key: "a", key_char: Some("a") }, is_held: false }
<eof>
```
With this fix, the `key_up` event fires correctly, resulting in the
following logs:
```text
Key down: KeyDownEvent { keystroke: Keystroke { modifiers: Modifiers { control: false, alt: false, shift: false, platform: false, function: false }, key: "a", key_char: Some("a") }, is_held: false }
Key up: KeyUpEvent { keystroke: Keystroke { modifiers: Modifiers { control: false, alt: false, shift: false, platform: false, function: false }, key: "a", key_char: None } }
<eof>
```
---
I've made the assumption that the `key_char` field shouldn't be set on
the `key_up` event since, unlike the `key_down` event, it's not an event
that may produce a character.
Happy to make any changes to this PR as required. If it would be
preferable to test this on Linux as well before it's merged, let me know
and I'll sort something out.
Hopefully this makes the experience of building new applications on GPUI
smoother, and potentially saves the Zed team some time if this event is
ever used in the future.
Release Notes:
- N/A
Closes#4461
Take 2 on https://github.com/zed-industries/zed/pull/25040.
Fixes panic caused due to using `setHiddenUntilMouseMoves` return type
to `set` cursor on macOS.
Release Notes:
- Now cursor hides when the user is typing in editor. It will stay
hidden until it is moved again. This behavior is `true` by default, and
can be configured with `hide_mouse_while_typing` in settings.
---------
Co-authored-by: Peter Tripp <peter@zed.dev>
Co-authored-by: Thomas Mickley-Doyle <thomas@zed.dev>
Co-authored-by: Agus <agus@zed.dev>
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Co-authored-by: Agus Zubiaga <hi@aguz.me>
Co-authored-by: Angelk90 <angelo.k90@hotmail.it>
This reverts commit a8610fbd13.
I've been seeing some reports of segmentation faults that appear to
point to this change as the culprit.
Closes#25366.
Release Notes:
- Community: Reverted #25040, so remove the corresponding entry from the
release notes.
This is second part needed for #17819.
There is already binding in default bindings: `"menu":
"editor::OpenContextMenu",` (but won't work on windows without this
change)
Release Notes:
- Handle "menu" key in windows
Closes https://github.com/zed-industries/zed/issues/4461
This PR improves the coding experience by hiding the mouse while the
user is typing so it does not accidentally get in their way, making it
challenging to ready characters in the editor.
Release Notes:
- The following PR hides the cursor when the user is typing by adding a
new cursor style called `None`.
- Assuming the user does not move the mouse, it will stay hidden until
it is moved again.
https://github.com/user-attachments/assets/6ba9f2ee-b9f3-4595-81e4-e9d986da4a39
---------
Co-authored-by: Agus <agus@zed.dev>
Co-authored-by: Peter Tripp <peter@zed.dev>
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Closes#24744
and should also fix#17819
The change is split into two commits, first one adds F10 handling (it
needs to be handled inside `parse_syskeydown_msg_keystroke`, the second
one properly handles `Alt+Fn` combinations, this also needs to happen in
`parse_syskeydown_msg_keystroke` and is similar to a fragment inside
`parse_keydown_msg_keystroke`
Release Notes:
- Fixes F10 and Alt+Fn handling on windows
I recently noticed that on my Windows 11 machine, Zed no longer receive
the `WM_DWMCOLORIZATIONCOLORCHANGED` message when the system theme
changes. This functionality was present in the past. While this change
might be unexpected, it's understandable given Microsoft's history of
system updates.
This pull request proposes an alternative approach using the
`WM_SETTINGCHANGE` message to handle theme changes.
Release Notes:
- N/A
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 PR renames the constants and functions previously introduced in
PR#23283. Since the changes are within the GPUI crate, I renamed these
from `**_ZED_**` to `**_GPUI_**`.
Release Notes:
- N/A
Closes#22653
After some investigation, I found this bug is due to that sometimes
`foreground_task` is not dispatched to the main thread unless there is
user input. The current Windows implementation works as follows: when
the `WindowsDispatcher` receives a `foreground_task`, it adds the task
to a queue and uses `SetEvent(dispatch_event)` to notify the main
thread.
The main thread then listens for notifications using
`MsgWaitForMultipleObjects(&[dispatch_event])`.
Essentially, this is a synchronous method, but it is not robust. For
example, if 100 `foreground_task`s are sent, `dispatch_event` should
theoretically be triggered 100 times, and
`MsgWaitForMultipleObjects(&[dispatch_event])` should receive 100
notifications, causing the main thread to execute all 100 tasks.
However, in practice, some `foreground_task`s may not get a chance to
execute due to certain reasons.
As shown in the attached video, when I don't move the mouse, there are
about 20-30 `foreground_task`s waiting in the queue to be executed. When
I move the mouse, `run_foreground_tasks()` is called, which processes
the tasks in the queue.
https://github.com/user-attachments/assets/83cd09ca-4b17-4a1f-9a2a-5d1569b23483
To address this, this PR adopts an approach similar to `winit`. In
`winit`, an invisible window is created for message passing. In this PR,
we use `PostThreadMessage` to directly send messages to the main thread.
With this implementation, when 100 `foreground_task`s are sent, the
`WindowsDispatcher` uses `PostThreadMessageW(thread_id,
RUNNABLE_DISPATCHED)` to notify the main thread. This approach enqueues
100 `RUNNABLE_DISPATCHED` messages in the main thread's message queue,
ensuring that each `foreground_task` is executed as expected. The main
thread continuously processes these messages, guaranteeing that all 100
tasks are executed.
Release Notes:
- N/A
Closes#22578
Currently, the `hovered` boolean in the window state is only updated by
the `WM_MOUSELEAVE` event, which fires when the mouse cursor leaves the
window's working area. This means that when the user moves the cursor
from the window to the title bar, `hovered` is set to `false`. Later in
the code, this flag is used to determine the cursor style and check if
the cursor is over the correct window.
The `hovered` boolean should remain active even when the mouse is over
non-client items, such as the title bar or window borders. This PR fixes
that by using `WM_NCMOUSELEAVE` event, which is triggered when the mouse
leaves non-client items. This event is used to update the `hovered`
boolean accordingly.
Now, `hovered` is `true` when the mouse is over the window's working
area, as well as non-client areas like the title bar.
More context:
- Existing: `dwFlags: TME_LEAVE` tracks window area mouse leaves, which
is used in `handle_mouse_move_msg` func.
- New: `dwFlags: TME_LEAVE | TME_NONCLIENT` tracks non-client mouse
leaves, which is used in `handle_nc_mouse_move_msg` func.
Preview:
https://github.com/user-attachments/assets/b319303f-81b9-45cb-bf0c-535a59b96561
Release Notes:
- Fix cursor style not changing on hover over items in the title bar on
Windows
Closes#22366
This PR fixes the issue of crashing when minimizing a window on Windows
11. And this PR supersedes #22366.
The main change in this PR is to stop rendering the window when it is
minimized. Additionally, I’ve made some modifications to the code in
#21756 to improve clarity (I think...).
cc @mgsloan
Release Notes:
- N/A
