* Part of https://github.com/emilk/egui/issues/8180
So far, you've been able to move any `egui::Window` by dragging anywhere
on it. This makes sense on touch screens with thick fingers, but less so
on non-touch-screens.
With this PR, you can now control it with a new enum `WindowDrag`
* Part of https://github.com/emilk/egui/issues/8180
Drag-to-scroll is a must-have on touch-screens, since there is no other
way to scroll.
However, when you are not on a touch screens, it is more surprising than
useful.
* part of #7264
* based on https://github.com/emilk/egui/pull/8152
The resize fix allows use to really simplify how the Window Titlebar is
rendered. Previously it was using some complex flow to calculate and
allocate the height first and then render it later once we knew the
windows final width.
Since now windows can't shrink past their minimum content widths, I can
just show the titlebar inline with the regular content, just outside of
the `Resize` container so that it is always visible.
This does change what the size of a window means. Before, size was just
the size of the contents, while now size (e.g. via min_height) will
include the Frames margin and outline, title bar and the contents.
Also, the window label now truncates as you shrink the window (meaning
windows can now be smaller than their label allows).
---------
Co-authored-by: lucasmerlin <8009393+lucasmerlin@users.noreply.github.com>
This allows the base egui crate to run on platforms without 64 bit
atomics
* Addresses <https://github.com/emilk/egui/issues/7692>, but does not
address the `egui_extras` crate
* [x] I have followed the instructions in the PR template
* Closes part of <https://github.com/emilk/egui/issues/3284>
Add a class system toward a CSS-like styling.
Widget and Ui can implement the trait `HasClasses` which can be used
later by theme engines to compute a style based on the set of classes
the component has.
---------
Co-authored-by: adrien <221212@umons.ac.be>
Co-authored-by: Adrien Zianne <adrien@iq002.ipa.iqrypto.com>
Co-authored-by: lucasmerlin <hi@lucasmerlin.me>
When enabled, trailing whitespace is included in the row width used for
horizontal alignment. This is useful for text editors where hiding
trailing spaces feels wrong when typing.
By default this is `false`, preserving existing behavior where trailing
whitespace is stripped for alignment (so "Hello " centers the same as
"Hello").
* follow up to https://github.com/emilk/egui/pull/8082
## Summary
`next_word_boundary_char_index` calls `char_index_from_byte_index` on
every word-boundary segment. Since `char_index_from_byte_index` scans
from the start of the string each time, this makes the function O(n·m)
where m is the number of segments — effectively O(n²) for large texts.
The fix replaces those repeated scans with a running char counter
maintained as we iterate segments. Same results, O(n) instead of O(n²).
## The problem
Any pointer interaction (click, double-click, drag) inside a `TextEdit`
with a large text buffer triggers `pointer_interaction` →
`select_word_at` → `ccursor_previous_word` →
`next_word_boundary_char_index`. On a 500 KB buffer this takes ~30
seconds, freezing the application.
## Benchmark results
Measured with cursor near end of text (worst case):
| Text size | Before | After | Speedup |
|-----------|--------|-------|---------|
| 1 KB | 147 µs | 38 µs | 3.9x |
| 100 KB | 1.2 s | 3.8 ms | 313x |
| 500 KB | 30 s | 18 ms | 1,636x |
Benchmark source:
[`bench/word-boundary-perf`](https://github.com/hallyhaa/egui/tree/bench/word-boundary-perf)
(separate branch, not part of this PR)
## Changes
- `next_word_boundary_char_index`: replace `char_index_from_byte_index`
calls with a `running_ci` counter (the fix — 6 changed lines)
- New tests for `ccursor_previous_word`, `ccursor_next_word`,
`select_word_at`, and a large-text performance test
---------
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
**Perf: Optimize text selection and navigation performance for large
documents**
#### **Summary**
This PR significantly improves the performance of text selection
(double-clicking) and cursor navigation within `TextEdit` and `Label`
widgets, particularly when handling large documents (e.g., 1MB+ or
logs). It eliminates several $O(N^2)$ bottlenecks and unnecessary memory
allocations in `text_cursor_state.rs`.
#### **Problems Identified**
1. **$O(N^2)$ Word Boundary Scanning:** In
`next_word_boundary_char_index`, `char_index_from_byte_index` was called
repeatedly inside a loop. This caused the entire document to be scanned
from the beginning for every word found, leading to quadratic time
complexity.
2. **Heavy String Allocations:** `ccursor_previous_word` used
`collect::<String>()` and `rev()` to search backwards, causing a full
copy and memory allocation of the text (or line) every time the user
moved the cursor or double-clicked.
3. **Inefficient Line Start Finding:** `find_line_start` performed
global character counts (`text.chars().count()`) and global skips, which
is very slow for large files.
4. **Global Search Scope:** `select_word_at` was performing word
boundary searches across the entire document even for simple
double-click actions.
#### **Key Changes & Optimizations**
1. **Line-Scoped Selection:** Updated `select_word_at` to first identify
the current line and then perform word boundary searches within that
local scope. This reduces the search space from millions of characters
to hundreds.
2. **Linear Time ($O(N)$) Boundary Search:** Refactored
`next_word_boundary_char_index` to use a running cumulative character
counter. This ensures the text is scanned only once.
3. **Zero-Allocation Backwards Search:** Optimized
`ccursor_previous_word` to use `next_back()` on the
`DoubleEndedIterator` provided by `unicode-segmentation`. This removes
all temporary `String` allocations.
4. **Byte-Based Line Search:** Optimized `find_line_start` to use
byte-based reverse scanning (`rfind('\n')`), which is significantly
faster than counting characters from the start of the document.
#### **Performance Impact**
In my tests with large text files (over 10,000 lines / 1MB+):
- **Before:** Double-clicking a word caused a UI freeze for 2–5 seconds.
- **After:** Word selection and navigation are near-instantaneous
(0–1ms), providing a smooth "native-like" experience even in WASM
environments.
A couple improvements to centered and right-aligned text edits:
- Fix text selection in centered and right aligned text edits
(ironically, this broke in #8076)
- Fix cursor movement in centered and right aligned text edits
(horizontal cursor position will be retained on vertical movement)
- Multiline text edit exceeding available width if there are atoms
- Added atoms & alignment options to text edit demo
- Improve how vertical_align and horizontal_align are applied
- Textedit atom is grow now, removing the need for the extra seperate
grow atom
- This allows us to apply the `align` on the text edit atom instead of
the whole AtomLayout
- Fixes https://github.com/emilk/egui/pull/8022
- Fixes https://github.com/emilk/egui/issues/7999
* Closes N/A
* Partially replaces #7983
* Related: #8045
* [x] I have followed the instructions in the PR template
## Details
In #7983, I modified `Memory::request_focus` to interrupt any ongoing
IME composition. This fixed a bug where clicking inside an already
focused `TextEdit` failed to cancel the active composition, resulting in
duplicated text:
https://github.com/emilk/egui/pull/8045#issuecomment-4193310616
To avoid introducing API changes in that PR, I ensured the IME state was
reset by forcing `PlatformOutput::ime` to `None` for at least one frame.
While this works well on desktop platforms, it causes virtual keyboard
flickering on the web:
https://github.com/emilk/egui/pull/8045#issuecomment-4193035008
In this PR, I delegate the responsibility for handling IME composition
interruptions to integrations, allowing each integration to decide how
to interrupt compositions in a flexible manner.
### The new field `should_interrupt_composition` on `IMEOutput`.
Instead of introducing a new `OutputCommand` variant, this PR adds a new
field `should_interrupt_composition` to `IMEOutput`.
Interrupting an active composition is only meaningful when IME remains
allowed. If IME should be disabled altogether, `PlatformOutput::ime` can
simply be set to `None`.
Given this, IMO, it is more appropriate to attach the interrupt signal
to `IMEOutput` (i.e., the type of `PlatformOutput::ime`).
This lets you turn off subpixel horizontal binning of glyphs. The option
is a trade-off between even kerning and sharp text.
* Closes https://github.com/emilk/egui/issues/8034
<!--
Please read the "Making a PR" section of
[`CONTRIBUTING.md`](https://github.com/emilk/egui/blob/main/CONTRIBUTING.md)
before opening a Pull Request!
* Keep your PR:s small and focused.
* The PR title is what ends up in the changelog, so make it descriptive!
* If applicable, add a screenshot or gif.
* If it is a non-trivial addition, consider adding a demo for it to
`egui_demo_lib`, or a new example.
* Do NOT open PR:s from your `master` branch, as that makes it hard for
maintainers to test and add commits to your PR.
* Remember to run `cargo fmt` and `cargo clippy`.
* Open the PR as a draft until you have self-reviewed it and run
`./scripts/check.sh`.
* When you have addressed a PR comment, mark it as resolved.
Please be patient! I will review your PR, but my time is limited!
-->
* Depends on #7967
* Closes#7485
* Should fix#7906 (This issue doesn't seem to have been resolved, but
the author closed it; I personally don't have the environment to verify
whether it is fixed.)
* Replaces #4137, #4896, and partially #7810
* [x] I have followed the instructions in the PR template
This PR started as a fix for #7485, but has since evolved into a broader
rewrite of IME-related logic.
## Overview
This PR primarily introduces a new public method, `owns_ime_events`, on
[`Memory`], and refactors parts of [`TextEdit`] to integrate with it.
Previously, each [`TextEdit`] widget independently determined whether to
handle IME events and stored its own IME-related state. This approach
made ownership-handling fragmented and was therefore error-prone.
With this PR:
- IME event ownership is centralized, ensuring that at most a single
widget owns IME events per frame.
- [`PlatformOutput`]'s `ime` field can be set to `None` for at least one
frame when IME composition is interrupted, allowing the IME to be
properly dismissed.
## Details
Two new public methods are introduced on [`Memory`]:
- `fn owns_ime_events(&self, id: Id) -> bool`: check IME event ownership
for the current frame for the widget with the given `id`.
- `fn interrupt_ime(&mut self)`: interrupt the current IME composition,
if any.
Since the newly added methods on [`Memory`] are public, other widgets
can also participate in IME handling without risking ownership conflicts
of IME events.
I also added an internal (`pub(crate)`) field on [`TextEditState`],
called `cursor_purpose`, to distinguish the role of the [`TextEdit`]
cursor.
Additionally, `egui::ImeEvent::Enabled` and `egui::ImeEvent::Disabled`
have been removed, as they are no longer used anywhere.
## Demonstrations
### Windows: The Korean IME text duplication bug fixed in #4137 does not
reappear.
<table>
<thead>
<tr>
<th></th>
<th>With this PR</th>
<th>Without this PR</th>
</tr>
</thead>
<tbody>
<tr>
<th>Behavior</th>
<td>Correct (no regression)</td>
<td>Correct</td>
</tr>
<tr>
<th>Screencast</th>
<td>
</td>
<td>
</td>
</tr>
</tbody>
</table>
### Windows: Chinese and Japanese IMEs now behave more consistently with
the Korean IME in similar scenarios.
This change does not matter much, as composition is rarely interrupted
mid-process with these IMEs in typical usage.
<table>
<thead>
<tr>
<th></th>
<th>With this PR</th>
<th>Without this PR</th>
</tr>
</thead>
<tbody>
<tr>
<th>Behavior</th>
<td>Composition can be interrupted by clicking (like Korean IMEs)</td>
<td>Composition can not interrupted by clicking</td>
</tr>
<tr>
<th>Screencast (Builtin Chinese IME)</th>
<td>
</td>
<td>
</td>
</tr>
<tr>
<th>Screencast (Builtin Japanese IME)</th>
<td>
</td>
<td>
</td>
</tr>
</tbody>
</table>
### macOS: was buggy, still buggy
Likely due to this upstream bug in `winit`:
https://github.com/rust-windowing/winit/issues/4432
Once `winit` is updated to a version that includes the fix, the behavior
should become correct with this PR.
<table>
<thead>
<tr>
<th></th>
<th>With this PR</th>
<th>Without this PR</th>
</tr>
</thead>
<tbody>
<tr>
<th>Behavior</th>
<td>Buggy as before</td>
<td>Buggy: Characters are duplicated</td>
</tr>
<tr>
<th>Screencast</th>
<td>
</td>
<td>
</td>
</tr>
</tbody>
</table>
### Wayland + iBus: Korean IME duplication bug fixed
<table>
<thead>
<tr>
<th></th>
<th>With this PR</th>
<th>Without this PR</th>
</tr>
</thead>
<tbody>
<tr>
<th>Behavior</th>
<td>Correct</td>
<td>Buggy: Characters are duplicated</td>
</tr>
<tr>
<th>Screencast</th>
<td>
</td>
<td>
</td>
</tr>
</tbody>
</table>
### Wayland + iBus: #7485 is fixed
<table>
<thead>
<tr>
<th></th>
<th>With this PR</th>
<th>Without this PR</th>
</tr>
</thead>
<tbody>
<tr>
<th>Behavior</th>
<td>Correct</td>
<td>Buggy: Only a single ASCII character can be typed after
<code>TextEdit</code> is focused</td>
</tr>
<tr>
<th>Screencast</th>
<td>
</td>
<td>
</td>
</tr>
</tbody>
</table>
### Wayland + iBus: selection is also not broken
This PR does not reintroduce the selection bug fixed in #7973.
<table>
<thead>
<tr>
<th></th>
<th>With this PR</th>
</tr>
</thead>
<tbody>
<tr>
<th>Behavior</th>
<td>Correct</td>
</tr>
<tr>
<th>Screencast</th>
<td>
</td>
</tr>
</tbody>
</table>
### X11 + Fcitx5: IME composition can be interrupted
But due to #7975, the experience is still subpar. (Uncommitted text is
lost after interruption.)
<table>
<thead>
<tr>
<th></th>
<th>With this PR</th>
<th>Without this PR</th>
</tr>
</thead>
<tbody>
<tr>
<th>Screencast</th>
<td>
</td>
<td>
</td>
</tr>
</tbody>
</table>
[`Memory`]: https://docs.rs/egui/latest/egui/struct.Memory.html
[`TextEdit`]:
https://docs.rs/egui/latest/egui/widgets/text_edit/struct.TextEdit.html
[`PlatformOutput`]:
https://docs.rs/egui/latest/egui/struct.PlatformOutput.html
[`TextEditState`]:
https://docs.rs/egui/latest/egui/widgets/text_edit/struct.TextEditState.html
Enable these new clippy lints and fix all warnings:
* `format_push_string` — use `write!` instead of `s += &format!(…)` to
avoid extra allocations
* `ignored_unit_patterns` — use `()` instead of `_` when matching unit
* `missing_fields_in_debug` — ensure manual `Debug` impls account for
all fields
* `needless_raw_string_hashes` — remove unnecessary `r#` on string
literals
* `ref_option` — prefer `Option<&T>` over `&Option<T>` in function
signatures
This PR fundamentally solves the same problem as
https://github.com/emilk/egui/pull/5827 just implemented with a lot less
ambition and api surface on my end. It contains the bare minimum amount
of changes that I need in order to be able to solve my problem.
My Problem:
I am still suffering from the problem that the TypeIdMap blows up over a
very long time when using my application. (The user generally never
turns off the application, it is intended to be just kept running
forever, some users also never restart their computers) My application
generates a lot of content dynamically so it may for some time display
widgets with a certain set of TypeId's + Id's later hiding them. Some of
the elements that were hidden may turn visible again once an external
event occurs, some may forever be discarded.
I do know myself when which sections of the UI have to be purged because
they will never become visible again, so this PR contains the minimum
amount of necessary functions that allow me to implement this
housekeeping logic on my end.
The existing facilities are insufficient to handle this as the type T
which the TypeId and the hash is derived from are sometimes pub(crate)
privates of widget subcrates or even pub(crate) of egui internals
itself, so its impossible to manually remove those from the TypeIdMap
the only build-in method to remove them is to call "clear" on the
TypeIdMap, however that gets rid of everything, even the elements that
are still shown and should still be in the TypeIdMap.
If the changes in this PR are agreeable to you and you want me to write
unit test for the 4 functions that I have added then tell me and I will
write the tests for you.
If you need anything else changed please tell me.
I ran cargo clippy and cargo fmt, but your check.sh does not work on my
computer.
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
Closes#7947
## Problem
`Visuals::interact_cursor` stopped working for buttons after the
`AtomLayout` refactor in commit 6eb7bb6e. Setting `interact_cursor` to
e.g. `CursorIcon::PointingHand` no longer changes the cursor when
hovering over a `Button`.
## Root Cause
When `Button` was rewritten to use `AtomLayout` in #5830, the
cursor-override block at the end of the old `Button::ui` was not carried
over to the new `Button::atom_ui` method.
The old code had:
```rust
if let Some(cursor) = ui.visuals().interact_cursor {
if response.hovered() {
ui.ctx().set_cursor_icon(cursor);
}
}
```
This was the only place `interact_cursor` was checked, so the setting
became entirely non-functional.
## Fix
Re-add the same `interact_cursor` check in `Button::atom_ui`, right
after painting and before `widget_info`, matching the original behavior.
---------
Co-authored-by: easonysliu <easonysliu@tencent.com>
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
feat: Add left_text() to egui::Button
This PR introduces the `left_text()` method to `egui::Button`. It
enables placing additional text content on the left side of the button's
primary label, which is useful for displaying auxiliary information,
labels, and for facilitating left-aligned text within the button.
```rust
let is_selected = true;
let selectable_label_widget = egui::Button::selectable(
is_selected,
"",
).left_text("Left");
let desired_width = ui.available_width();
let desired_height = ui.spacing().interact_size.y;
interaction_response = ui.add_sized(
egui::vec2(desired_width, desired_height),
selectable_label_widget,
);
```
Summary
This PR fixes submenu keyboard parity: pressing Enter/Space on an
already-open submenu button now collapses that submenu (matching
top-level menu button behavior).
What changed
Updated submenu interaction logic to distinguish pointer primary clicks
from keyboard/accessibility-triggered clicks.
Kept pointer/touch behavior unchanged (submenu button clicks still don’t
auto-close submenu).
Added regression tests for:
keyboard open of nested submenu,
keyboard close (second Enter) of nested submenu,
pointer clicks on submenu button keeping submenu open.
Validation
cargo test -p egui_kittest --test regression_tests
Breaking changes
None. Behavior change is limited to keyboard/accessibility activation of
already-open submenu buttons.
* Closes <https://github.com/emilk/egui/issues/7926>
* [ X ] I have followed the instructions in the PR template
---------
Co-authored-by: Lucas Meurer <hi@lucasmerlin.me>
<!--
Please read the "Making a PR" section of
[`CONTRIBUTING.md`](https://github.com/emilk/egui/blob/main/CONTRIBUTING.md)
before opening a Pull Request!
* Keep your PR:s small and focused.
* The PR title is what ends up in the changelog, so make it descriptive!
* If applicable, add a screenshot or gif.
* If it is a non-trivial addition, consider adding a demo for it to
`egui_demo_lib`, or a new example.
* Do NOT open PR:s from your `master` branch, as that makes it hard for
maintainers to test and add commits to your PR.
* Remember to run `cargo fmt` and `cargo clippy`.
* Open the PR as a draft until you have self-reviewed it and run
`./scripts/check.sh`.
* When you have addressed a PR comment, mark it as resolved.
Please be patient! I will review your PR, but my time is limited!
-->
* Closes#7809
* Closes#7876
* Closes#7908
* Supersedes #7877
* Supersedes #7898
* The author of the PR above replaced it with #7914, which additionally
fixes another IME issue. I believe that fix deserves a separate PR.
* Reverts #4794
* [x] I have followed the instructions in the PR template
This approach is better than #7898 (#7914) because it correctly handles
all three major IME types (Chinese, Japanese, and Korean) without
requiring a predefined “IME mode”.
## Environments I haved tested this PR in
<details><summary>macOS 15.7.3 (AArch64, Host of other virtual
machines)</summary>
Run command: `cargo run -p egui_demo_app --release`
Tested IMEs:
- builtin Chinese IME (Shuangpin - Simplified)
- builtin Japanese IME (Romaji)
- builtin Korean IME (2-Set)
</details>
<details><summary>Windows 11 25H2 (AArch64, Virtual Machine)</summary>
Build command: `cargo build --release -p egui_demo_app
--target=x86_64-pc-windows-gnu --features=glow --no-default-features`
(I cannot use `wgpu` due to [this
bug](https://github.com/emilk/egui/issues/4381), which prevents
debugging inside the VM. Anyways, the rendering backend should be
irrelevant here.)
Tested IMEs:
- builtin Chinese IME (Shuangpin)
- Sogou IME (Chinese Shuangpin)
- WeType IME (Chinese Shuangpin)
- builtin Japanese IME (Hiragana)
- builtin Korean IME (2 Beolsik)
</details>
<details><summary>Linux [Wayland + IBus] (AArch64, Virtual
Machine)</summary>
Fedora KDE Plasma Desktop 43 [Wayland + IBus 1.5.33-rc2]
(Not working at the moment because of [another
issue](https://github.com/emilk/egui/issues/7485) that will be fixed by
#7983. It is [a complicated
story](https://github.com/emilk/egui/pull/7973#issuecomment-4074627603).
)
> [!NOTE]
>
> IBus is partially broken in this system. The Input Method Selector
refuses to select IBus. As a workaround, I have to open System Settings
-> Virtual Keyboard and select “IBus Wayland” to start an IBus instance
that works in egui.
>
> The funny thing is: the Chinese Intelligent Pinyin IME is broken in
native Apps like System Settings and KWrite, but works correctly in
egui!
>
> <details><summary>Screencast: What</summary>
>
> 
> </details>
Build command: `cross build --release -p egui_demo_app
--target=aarch64-unknown-linux-gnu --features=wayland,wgpu
--no-default-features`
(The Linux toolchain on my mac is somehow broken, so I used `cross`
instead.)
Tested IMEs:
- Chinese Intelligent Pinyin IME (Shuangpin)
- Japanese Anthy IME (Hiragana)
- Korean Hangul IME
</details>
<details><summary>Linux [X11 + Fcitx5] (AArch64, Virtual
Machine)</summary>
Debian 13 [Cinnamon 6.4.10 + X11 + Fcitx5 5.1.2]
Build command: `cross build --release -p egui_demo_app
--target=aarch64-unknown-linux-gnu --features=x11,wgpu
--no-default-features`
Tested IMEs:
- Chinese Shuangpin IME
- Chinese Rime IME with `luna-pinyin`
- Japanese Mozc IME (Hiragana)
- Korean Hangul IME
Unlike macOS and Linux + Wayland, key-release events for keys processed
by the IME are still forwarded to `egui`. These appear to be harmless in
practice.
Unlike on Windows, however, they cannot be filtered reliably because
there are no corresponding key-press events marked as “processed by
IME”.
</details>
---
There are too many possible combinations to test (Operating Systems ×
[Desktop
Environment](https://en.wikipedia.org/wiki/Desktop_environment)s ×
[Windowing System](https://en.wikipedia.org/wiki/Windowing_system)s ×
[IMF](https://wiki.archlinux.org/title/Input_method#Input_method_framework)s
× [IME](https://en.wikipedia.org/wiki/Input_method)s × …), and I only
have access to a limited subset. For example, Google Japanese Input
refused to install on my Windows VM, and some paid Japanese IMEs are not
accessible to me. Therefore, I would appreciate feedback from people
other than me using all kinds of environments.
## Details
There are two possible approaches to removing keyboard events that have
already been processed by an IME:
* Approach 1: Filter out events inside `egui` that appear to have been
received during IME composition.
* Approach 2: Filter out such events in the platform backend
(terminology [borrowed from
imgui](https://github.com/ocornut/imgui/blob/master/docs/BACKENDS.md#using-standard-backends),
e.g. the `egui-winit` crate or the code under `web/` in the `eframe`
crate.).
Both approaches already exist in `egui`:
* #4794 uses the first approach, filtering these events in the
`TextEdit`-related code.
* `eframe` uses the second approach in its web integration. See:
<14afefa252/crates/eframe/src/web/events.rs (L173-L176)>
Compared to the first approach, the second has a clear advantage: when
events are passed from the platform backends into `egui`, they are
simplified and lose information. In contrast, events in the platform
backends are the original events, which allows them to be handled more
flexibly. This is also why #7898 (#7914), which attempts to address the
issue from within the `egui` crate, struggles to make all IMEs work
correctly at the same time and requires manually selecting an “IME
mode”: the events received by `egui` have already been reduced and
therefore lack necessary information.
A more appropriate solution is to consistently follow the second
approach, explicitly requiring platform backends not to forward events
that have already been processed by the IME to `egui`. This is the
method used in this PR. Specifically, this PR works within the
`egui-winit` crate, where the original `KeyboardInput` events can be
accessed. At least for key press events, these can be used directly to
determine whether the event has already been processed by the IME on
Windows (by checking whether `logical_key` equals
`winit:⌨️:NamedKey::Process`). This makes it straightforward to
ensure that all IMEs work correctly at the same time.
This PR also reverts #4794, which took the first approach. It filters
out some events that merely look like they were received during IME
composition but actually are not. It also messes up the order of those
events along the way.
As a result, it caused several IME-related issues. One of the sections
in the Demonstrations below will illustrate these problems.
## Demonstrations
<details><summary>Changes not included in this PR for displaying Unicode
characters in demonstrations</summary>
Download `unifont-17.0.03.otf` from
<https://unifoundry.com/pub/unifont/unifont-17.0.03/font-builds/>, and
place it at `crates/egui_demo_app/src/unifont-17.0.03.otf`.
In `crates/egui_demo_app/src/wrap_app.rs`, add these lines at the
beginning of `impl WrapApp`'s `pub fn new`:
```rust
{
const MAIN_FONT: &'static [u8] = include_bytes!("./unifont-17.0.03.otf");
let mut fonts = egui::FontDefinitions::default();
fonts.font_data.insert(
"main-font".to_owned(),
std::sync::Arc::new(egui::FontData::from_static(MAIN_FONT)),
);
let proportional = fonts
.families
.entry(egui::FontFamily::Proportional)
.or_default();
proportional.insert(0, "main-font".to_owned());
cc.egui_ctx.set_fonts(fonts);
}
```
(I took this from somewhere, but I forgot where it is. Sorry…)
</details>
[GNU Unifont](https://unifoundry.com/unifont/index.html) is licensed
under [OFL-1.1](https://unifoundry.com/OFL-1.1.txt).
### This PR Fixes: Focus on a single-line `TextEdit` is lost after
completing candidate selection with Japanese IME on Windows (#7809)
<details><summary>Screencast: ✅ Japanese IME now behaves correctly while
Korean IME behaves as before</summary>
</details>
### This PR Fixes: Committing Japanese IME text with <kbd>Enter</kbd>
inserts an unintended newline in multiline `TextEdit` on Windows (#7876)
<details><summary>Screencast: ✅ Japanese IME now behaves correctly while
Korean IME behaves as before</summary>
</details>
### This PR Fixes: Backspacing deletes characters during composition in
certain Chinese IMEs (e.g., Sogou) on Windows (#7908)
<details><summary>Screencast: ✅ Sogou IME now behaves
correctly</summary>
</details>
### This PR Obsoletes #4794, because `egui` receives only IME events
during composition from now on
On Windows, “incompatible” events are filtered in `egui-winit`, aligning
the behavior with other systems.
<details><summary>Screencasts</summary>
Some Chinese IMEs on Windows:
The default Japanese IMEs on Windows:
</details>
The 2-set Korean IMEs handle arrow keys differently. It will be
discussed in the next section.
### This PR Reverts #4794, because it introduced several bugs
Some of its bugs have already been worked around in the past, but those
workarounds might also be problematic. For example, #4912 is a
workaround for a bug (#4908) introduced by #4794, and that workaround is
in fact the root cause of the macOS backspacing bug I have worked around
with #7810. (The reversion of #4912 is out of the scope of this PR, I
will do that in #7983.)
#### It Caused: Arrow keys are incorrectly blocked during typical Korean
IME composition
When composing Korean text using 2-Set IMEs, users should still be able
to move the cursor with arrow keys regardless if the composition is
committed.
##### Correct behavior
<details><summary>Screencasts</summary>
macOS TextEdit:
Windows Notepad:
With #4794 reverted, `egui` also behaves correctly (tested on Linux +
Wayland, macOS, and Windows):
</details>
##### Incorrect behavior caused by #4794
`remove_ime_incompatible_events` removed arrow-key events in such cases.
As a result, the first arrow key press only commits the composition, and
users need to press the arrow key again to move the cursor:
<details><summary>Screencast</summary>
</details>
This is essentially the same issue described here:
https://github.com/emilk/egui/pull/7877#issuecomment-3852719948
#### It Caused: Backspacing leaves the last character in Korean IME
pre-edit text not removed on macOS
<details><summary>Screencasts</summary>
Before this PR:
After this PR:
</details>
### Korean IMEs also use <kbd>Enter</kbd> to confirm Hanja selections,
and will not work properly in the Korean “IME mode” proposed by #7898
(#7914)
<details><summary>Screencast: Korean IME using <kbd>Enter</kbd> and
<kbd>Space</kbd> for confirmation (IBus Korean Hangul IME)</summary>
The screencast below demonstrates that some Korean IMEs handle Hanja
selection in a way similar to Japanese IMEs: the
<kbd>Up</kbd>/<kbd>Down</kbd> arrow keys are used to navigate
candidates, and <kbd>Enter</kbd> confirms the selected candidate.
</details>
<details><summary>Screencasts: Another example</summary>
Using the built-in Korean IME on Windows, I type two lines: the first
line in Hangul, and the second line as the same word converted to Hanja.
Correct behavior in Notepad (reference):
Behavior after applying this PR, which matches the Notepad behavior:
Behavior after applying #7914 with the “IME mode” set to Korean (which
is also the behavior before this PR being applied):
On the second line, each time a Hanja character is confirmed, an
unintended newline is inserted. This mirrors the Japanese IME issues
that are supposed to be fixed by setting the “IME mode” to Japanese.
(These Japanese IME issues are fixed in this PR as mentioned before.)
</details>
* [x] I have followed the instructions in the PR template
This PR have two commits:
* **First commit** - introduction of tests and their canonization image.
Expected behaviour is that `horizontal_wrapped_multiline_row_height`
would match `horizontal_wrapped_multiline_row_height_reference`, but it
doesn't. There is a bug in `horizontal_wrapped` that breaks line height
after using `text_edit_multiline`.
* **Second commit** - fix. You can see that
`horizontal_wrapped_multiline_row_height` now looks like
`horizontal_wrapped_multiline_row_height_reference` (although it's not a
perfect match, upd: found, this is because of this issue:
https://github.com/emilk/egui/issues/4921).
I have used LLM to help me with this PR (codex + claude code).
BTW, I'm using horizontal_wrapped with end_row instead of vertical +
horizontal alternation, because I automatically generate my UI through
some complex interactions between elements in my code, and it's can be
that my `horizontal` starts in one function, and ends in another.
Something like `begin_horizontal`/`end_horizontal`/`get_current_layout`
would be very handy, related to
https://github.com/emilk/egui/issues/1004.
Also, I would like indent to be supported in `horizontal_wrapped`, or
also, to have `indent_start`/`indent_end`. This is why I used
`monospace("| ")` in my example, it simulates my use-case.
<!--
Please read the "Making a PR" section of
[`CONTRIBUTING.md`](https://github.com/emilk/egui/blob/main/CONTRIBUTING.md)
before opening a Pull Request!
* Keep your PR:s small and focused.
* The PR title is what ends up in the changelog, so make it descriptive!
* If applicable, add a screenshot or gif.
* If it is a non-trivial addition, consider adding a demo for it to
`egui_demo_lib`, or a new example.
* Do NOT open PR:s from your `master` branch, as that makes it hard for
maintainers to test and add commits to your PR.
* Remember to run `cargo fmt` and `cargo clippy`.
* Open the PR as a draft until you have self-reviewed it and run
`./scripts/check.sh`.
* When you have addressed a PR comment, mark it as resolved.
Please be patient! I will review your PR, but my time is limited!
-->
This is a fix/improvement that makes all kinds of alignments work in
`TextEdit` when a custom `LayoutJob` with halign is used.
I used the simplest approach possible to avoid unwanted bugs as I wasn't
sure what's safe to change, but there's potentially better ways to
achieve this. In particular, I'm not sure I fully understand the
rationale behind aligning rows in a `Galley` based on the latter's
leftmost border, considering the size is what's ultimately used in
widgets (in `TextEdit` at least).
Regardless, here's a demo of this PR:
https://github.com/user-attachments/assets/5d9801d7-73af-4576-80c5-47f169700462
* [x] I have followed the instructions in the PR template
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
This is necessary to add e.g. buttons as prefix/suffix within the
textedit (so you can read the rect and place the button).
I'm not sure if deref on the AtomLayoutResponse is the right call but it
should make the migration easier and is generally convenient (but might
lead to some confusion).
* Found thanks to https://github.com/emilk/egui/pull/7984
If you put an animated `Panel` inside a `Ui`, then the automatic ids for
following widgets would differ when the panel was collapsed or open.
