By default, `Windows` can now cover already added panels. For instance:
in the egui demo app (egui.rs), windows can now cover the side-panels
and top bar.
To get the old behaviour, use
`window.constrain_to(ctx.available_rect())`.
Sometimes we need to fix the current state of the application in the
moment when you open the context menu, to save it, and to use it during
creation of context menu and response handling. Making some structs,
related with menu creating, allow us to create functions for this cases.
For example,
```rust
pub fn context_menu_custom<'a, T>(
response: &Response,
//variable for fixing state in the moment when you open context menu
state: &mut T,
//function which allow to get some king of state.
//In this case state depends on cursor position, in other cases it may depend on system time or something else
get_state: impl FnOnce(Pos2) -> T,
//set contents of menu depending on state
set_contents: impl 'a + FnOnce(&T) -> Box<dyn 'a + FnOnce(&mut Ui)>,
) -> Option<InnerResponse<()>> {
let menu_id = Id::new("__egui::context_menu");
let mut bar_state = BarState::load(&response.ctx, menu_id);
let root = &mut bar_state;
let menu_response = MenuRoot::context_interaction(response, root);
if let egui::menu::MenuResponse::Create(p, _) = &menu_response {
*state = get_state(*p);
};
let add_contents = set_contents(&state);
MenuRoot::handle_menu_response(root, menu_response);
let inner_response = bar_state.show(response, add_contents);
bar_state.store(&response.ctx, menu_id);
inner_response
}
```
The example of using such function you may see in [`my
repository`](https://github.com/sor-ca/context_menu)
It is very simple example, and is this case, the problem may be solved
without fn context_menu_custom, but in more complex situations, it may
be very useful
Related issue: https://github.com/emilk/egui/issues/4162
<!--
Please read the "Making a PR" section of
[`CONTRIBUTING.md`](https://github.com/emilk/egui/blob/master/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 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!
-->
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
All `Area`s now have a quick fade-in animation. You can turn it off with
`Area::fade_in` or `Window::fade_in` .
The `Window` fade-out animation is now nicer: it fades all elements of
the window, not just the frame.
It can be controlled with `Window::fade_out`.
* Closes https://github.com/emilk/egui/issues/4582
User-story: there are multiple icons in a row, and the user wants them
explained. They hover over one until the tooltips appears. They then
move on to the next and don't want to wait for that tooltip again.
These functions will always show a tooltip under the widget when called,
even if the user is not hovering the widget.
This can be useful for tutorials and notification and similar.
* Closes https://github.com/emilk/egui/issues/890
If you change your code for what is contained in a menu, tooltips,
combobox etc, it is helpful if egui will recompute the size of that Area
next frame. Now it will!
The user-chosen size of a `Window` is still persisted via other means.
- Closes https://github.com/emilk/egui/issues/4060 - no longer aligned
to top
- Closes https://github.com/emilk/egui/issues/4479 - `canvas.style` is
not set anywhere anymore
- Closes https://github.com/emilk/egui/issues/2231 - same as #4060
- Closes https://github.com/emilk/egui/issues/3618 - there is now one
`<input>` per `eframe` app, and it's removed transitively by
`WebRunner::destroy -> AppRunner::drop -> TextAgent::drop`
This PR improves the text agent to make fewer assumptions about how
`egui` is embedded into the page:
- Text agent no longer sets the canvas position
- There is now a text agent for each instance of `WebRunner`
- The input element is now moved to the correct position, so the OS can
display the IME window in the correct place. Before it would typically
be outside of the viewport
The best way to test this is to build & server the web demo locally:
```
scripts/build_demo_web.sh && scripts/start_server.sh
```
Then open the EasyMark editor, and try using IME to input some emojis:
http://localhost:8888/#EasyMarkEditor
To open the emoji keyboard use:
- <kbd>win + .</kbd> on Windows
- <kbd>ctrl + cmd + space</kbd> on Mac
Tested on:
- [x] Windows
- [x] Linux
- [x] MacOS
- [x] Android
- [x] iOS
## Migration guide
The canvas no longer controls its own size/position on the page. This
means that those properties can now be controlled entirely via HTML and
CSS, and multiple separate `eframe` apps can coexist better on a single
page.
To match the old behavior, set the `canvas` width and height to 100% of
the `body` element:
```html
<html>
<body>
<canvas></canvas>
</body>
</html>
```
```css
/* remove default margins and use full viewport */
html, body {
margin: 0;
width: 100%;
height: 100%;
}
canvas {
/* match parent element size */
width: 100%;
height: 100%;
}
```
Note that there is no need to set `position: absolute`/`left: 50%;
transform: translateX(-50%)`/etc., and setting those properties may
poorly affect the sharpness of `egui`-rendered text.
Because `eframe` no longer updates the canvas style in any way, it also
means that on mobile, the canvas no longer collapses upwards to make
space for a mobile keyboard. This should be solved in other ways:
https://github.com/emilk/egui/issues/4572
* Part of https://github.com/emilk/egui/issues/4535
* Closes https://github.com/emilk/egui/issues/3974
This adds a special `sizing_pass` mode to `Ui`, in which we have no
centered or justified layouts, and everything is hidden. This is used by
`Area` to use the first frame to measure the size of its contents so
that it can then set the perfectly correct size the subsequent frames.
For menus, where buttons are justified (span the full width), this
finally the problem of auto-sizing. Before you would have to pick a
width manually, and all buttons would expand to that width. If it was
too wide, it looked weird. If it was too narrow, text would wrap. Now
all menus are exactly the width they need to be. By default menus will
wrap at `Spacing::menu_width`.
This affects all situations when you have something that should be as
small as possible, but still span the full width/height of the parent.
For instance: the `egui::Separator` widget now checks the
`ui.is_sizing_pass` flag before deciding on a size. In the sizing pass a
horizontal separator is always 0 wide, and only in subsequent passes
will it span the full width.
* Closes#4473
This PR introduce `Style::wrap_mode`, which adds support for text
truncation in addition to text wrapping. This PR also update some width
calculation of the ComboBox.
#### Core
- Add `egui::TextWrapMode` (pure enum with `Extend`, `Wrap`, `Truncate`)
- Add `Style::wrap_mode: Option<tTextWrapMode>`
- **DEPRECATED**: `Style::wrap`, use `Style::wrap_mode` instead.
- Add `Ui::wrap_mode()` to return the wrap mode to use in the current
ui. If specified in `Style`, return it. Otherwise, return
`TextWrapMode::Wrap` for vertical layout and wrapping horizontal layout,
and `TextWrapMode::Extend` otherwise.
- **DEPRECATED**: `Ui::wrap_text()`, use `Ui::wrap_mode` instead.
#### Widget
- Update the width calculation of the `ComboBox` button (_not_ its popup
menu).
- Now, `ComboBox::width()` (defaulting to `Spacing::combo_width`) is
always considered a minimum width and will extend the `Ui`, regardless
of the selected text width and wrap mode.
- Introduce `ComboBox::wrap_mode`, which overrides `Ui::wrap_mode` for
the selected text layout.
- Note: since `ComboBox` uses `ui.horizontal` internally, the default
wrap mode is always `TextWrapMode::Extend`, regardless of the caller's
`Ui`'s layout.
- The `ComboBox` button no longer extend to `ui.available_width()` with
wrapping is enabled.
- **BREAKING**: `ComboBox::wrap()` no longer has a `bool` argument and
is now a short-hand for `ComboBox::wrap_mode(TextWrapMode::Wrap)`.
- Added `ComboBox::truncate()` as short-hand for
`ComboBox::wrap_mode(TextWrapMode::Truncate)`.
- Update `Label`
- Add `Label::wrap_mode()` to specify the text wrap mode.
- **BREAKING**: `Label::wrap()` no longer has a `bool` argument and is
now a short-hand for `Label::wrap_mode(TextWrapMode::Wrap)`.
- **BREAKING**: `Label::truncate()` no longer has a `bool` argument and
is now a short-hand for `Label::wrap_mode(TextWrapMode::Truncate)`.
- Update `Button`
- Add `Button::wrap_mode()` to specify the text wrap mode.
- **BREAKING**: `Button::wrap()` no longer has a `bool` argument and is
now a short-hand for `Button::wrap_mode(TextWrapMode::Wrap)`.
- Added `Button::truncate()` as short-hand for
`Button::wrap_mode(TextWrapMode::Truncate)`.
#### Low-level
- **BREAKING**: `WidgetText::into_galley()` now takes an
`Option<TextWrapMode>` instead of a `Option<bool>` argument.
- **BREAKING**: `WidgetText::into_galley_impl(()` now takes a
`TextWrapping` argument instead of `wrap: bool` and `availalbe_width:
f32` arguments.
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
<!--
Please read the "Making a PR" section of
[`CONTRIBUTING.md`](https://github.com/emilk/egui/blob/master/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 add commits to your PR.
* Remember to run `cargo fmt` and `cargo cranky`.
* 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 introduces the boolean field force_current_scroll_area to
InputState which will be set when scroll_with_delta is called, causing
the ScrollArea to skip the check whether it is focused and always
consume the smooth scroll delta.
* Closes#2783
* Related to #4295
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
## Summary
This PR introduces a new configuration option `reduce_texture_memory` in
`egui`.
## Changes
- Added `reduce_texture_memory` option in `egui`. When set to `true`,
`egui` will discard the loaded image data after the texture is uploaded
to the GPU, reducing memory usage. This is beneficial when handling a
large number of images and retaining the image data is unnecessary,
potentially saving substantial memory. However, this makes it impossible
to serialize the loaded images or render on non-GPU systems. Default is
`false`.
## Impact
This new configuration option gives users more control over their memory
usage, especially when dealing with a large number or large resolution
of images. It allows users to optimize their applications based on their
specific needs and constraints.
Simply adds a `hint_text_font` (any suggestions for a better name?
hint_text_style seemed misleading as it doesn't only accept `TextStyle`)
method to the TextEdit builder that allows to set the styling
(specifically, a `FontSelection`) for the hint text.
My personal use-case for this was having body-sized hint text in a
heading-sized TextEdit, but I'm sure there's more out there.
The PR shouldn't break compatibility, as it's stored as an `Option` that
defaults to the `font_id` (which was the only behaviour prior to this)
when empty.
It looked too trivial to add something to the actual demo, but I have it
locally, so let me know if I should commit that.
Ran the check script locally, had no complaints.
I wanted to disable the return key functionality on my `TextEdit`, so
that the `TextEdit` doesn't get unfocused whenever the user submits a
command onto my developer console (which is also bound to <kbd>↵
Enter</kbd>).
<!--
Please read the "Making a PR" section of
[`CONTRIBUTING.md`](https://github.com/emilk/egui/blob/master/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 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!
-->
Related to #3482
Not sure what the "best practice" is, to me it seems like one should
import from "the original location" if possible, but now it should at
least be possible to not re-export ahash without any breakage in the
egui code base (but possibly in projects using egui, so one should
probably deprecate it if one would like to go that path). It also seems
like epaint re-exports ahash.
* closes https://github.com/emilk/egui/issues/4525
You can zoom in using ctrl/cmd + scrolling. When using a discreet scroll
wheel, the zoom factor now gets smoothed.
For integrations: just emit `egui::Event::MouseWheel` (like before).
egui will interpret that as zoom or pan.
On the way towards https://github.com/emilk/egui/issues/4401
<!--
Please read the "Making a PR" section of
[`CONTRIBUTING.md`](https://github.com/emilk/egui/blob/master/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 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!
-->
Inspired by:
44d65f41ac/Cargo.toml (L65)
I took the liberty of removing that comment since I *think* that I got
all "relevant" ones (showing up more than once, sort of).
## Summary
This PR modifies `ScrollArea` and `Plot` to disable their interactions
when the UI is disabled.
## Changes
- Interaction with `ScrollArea` in `egui` is disabled when the UI is
disabled.
- Interaction with `Plot` in `egui_plot` is disabled when the UI is
disabled.
- These changes ensure that `ScrollArea` and `Plot` behave consistently
with the rest of the UI, preventing them from responding to user input
when the UI is in a disabled state.
## Impact
This PR enhances the consistency of `egui`'s UI behavior by ensuring
that all elements, including `ScrollArea` and `Plot`, respect the UI's
disabled state. This prevents unexpected interactions when the UI is
disabled.
Closes#4341
resolves https://github.com/emilk/egui/issues/4081 (see discussion
starting from
https://github.com/emilk/egui/issues/3653#issuecomment-1962740175 for
extra context)
this partly restores event-emitting behaviour to the state before #3649,
when shortcuts such as `Ctrl` + `C` used to work regardless of the
active layout. the difference is that physical keys are only used in
case of the logical ones' absence now among the named keys.
while originally I have only limited this to clipboard shortcuts
(Ctrl+C/V/X), honestly it felt like a half-assed solution. as a result,
I decided to expand this behaviour to all key events to stick to the
original logic, in case there are other workflows and hotkeys people
rely on or expect to work out of the box. let me know if this is an
issue.
Removes `egui_assert` etc and replaces it with normal `debug_assert`
calls.
Previously you could opt-in to more runtime checks using feature flags.
Now these extra runtime checks are always enabled for debug builds.
You are most likely to encounter them if you use negative sizes or NaNs
or other similar bugs.
These usually indicate bugs in user space.
<!--
Please read the "Making a PR" section of
[`CONTRIBUTING.md`](https://github.com/emilk/egui/blob/master/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 add commits to your PR.
* Remember to run `cargo fmt` and `cargo cranky`.
* 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!
-->
remove repetitive words
Signed-off-by: hardlydearly <799511800@qq.com>
Motivation: I want to replace `cargo-cranky` with workspace lints, first
available in Rust 1.74.
However, `cargo doc` would hange on `wgpu` and `wgpu-core` on 1.74 and
1.75… so now we're on 1.76.
I think this is fine - when 1.78 is released next week we're still two
versions behind the bleeding edge.
…and the branch name is just wrong 🤦
<!--
Please read the "Making a PR" section of
[`CONTRIBUTING.md`](https://github.com/emilk/egui/blob/master/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 add commits to your PR.
* Remember to run `cargo fmt` and `cargo cranky`.
* 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!
-->
I had to make a couple types not Copy because closures, but it should'nt
be a massive deal.
I tried my best to make the API change as non breaking as possible.
Anywhere a PathStroke is used, you can just use a normal Stroke instead.
As mentioned above, the bezier paths couldn't be copy anymore, but IMO
that's a minor caveat.
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
Added clamp_size_to_monitor_size field on ViewportBuilder, which means
whether clamp the window's size to monitor's size. (default to `true`)
* Closes https://github.com/emilk/egui/issues/3389
### simple example
```rust
pub struct MyApp {}
impl MyApp {
pub fn new() -> MyApp {
MyApp {}
}
}
impl eframe::App for MyApp {
fn update(&mut self, ctx: &Context, frame: &mut eframe::Frame) {
egui::CentralPanel::default()
.frame(Frame::none().fill(Color32::DARK_GRAY))
.show(ctx, |ui| {
if ctx.input(|i| i.key_pressed(Key::Escape)) {
ctx.send_viewport_cmd(ViewportCommand::Close);
}
});
}
}
pub fn main() {
let option = eframe::NativeOptions {
viewport: ViewportBuilder::default()
.with_position([10.0, 10.0])
.with_inner_size([3000.0, 2000.0])
.with_clamp_size_to_monitor_size(false),
..Default::default()
};
eframe::run_native(
"a large window app",
option,
Box::new(|ctx| Box::new(MyApp::new())),
).unwrap();
}
```
It works on my windows (with 3 monitors), but I don't have a test
environment for macos
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
* Closes#4354
Fix: can't repeat input chinese words
AND
For Windows :
ImeEnable
ImeDisable
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
<!--
Please read the "Making a PR" section of
[`CONTRIBUTING.md`](https://github.com/emilk/egui/blob/master/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 add commits to your PR.
* Remember to run `cargo fmt` and `cargo cranky`.
* 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 <https://github.com/emilk/egui/issues/4126>
* Closes <https://github.com/emilk/egui/issues/3006>
Previously, `SidePanel`/`TopBottomPanel` didn't include `inner_margin`
when setting the min width/height of `Frame`. As a result, when your
`Panel` has `inner_margin`, its size doesn't work as expected.
Before
After
### Motivation
We want to offer our users a context menu with `Cut`, `Copy` and `Paste`
actions. `Paste` is not possible out of the box.
### Changes
This PR adds `ViewportCommand::RequestCut`,
`ViewportCommand::RequestCopy` and `ViewportCommand::RequestPaste`. They
are routed and handled after the example of
`ViewportCommand::Screenshot` and result in the same code being executed
as when the user uses `CTRL+V` style keyboard commands.
### Reasoning
In our last release we used an instance of
`egui_winit:📋:Clipboard` in order to get the `Paste`
functionality.
However Linux users on Wayland complained about broken clipboard
interaction (https://github.com/mikedilger/gossip/issues/617). After a
while of digging I could not find the issue although I have found
references to problems with multiple clipboards per handle before
(https://gitlab.gnome.org/GNOME/mutter/-/issues/1250) but I compared
mutter with weston and the problem occured on both.
So to solve this I set out to extend egui to access the clipboard
instance already present in egui_winit. Since there was no trivial way
to reach the instance of `egui_winit::State` I felt the best approach
was to follow the logic of the new `ViewportCommand::Screenshot`.
### Variations
It could make sense to make the introduced `enum ActionRequested` a part
of crates/egui/src/viewport.rs and to then wrap them into one single
`ViewportCommand::ActionRequest(ActionRequested)`.
### Example
```Rust
let mut text = String::new();
let response = ui.text_edit_singleline(&mut text);
if ui.button("Paste").clicked() {
response.request_focus();
ui.ctx().send_viewport_cmd(ViewportCommand::RequestPaste);
}
```
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
<!--
Please read the "Making a PR" section of
[`CONTRIBUTING.md`](https://github.com/emilk/egui/blob/master/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 add commits to your PR.
* Remember to run `cargo fmt` and `cargo cranky`.
* 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 https://github.com/emilk/egui/issues/4356
- Add `Undoer::new()`
- This is necessary to construct an `Undoer` whose `State` parameter
doesn't implement `Default`.
- Add `Undoer::with_settings(...)`
- This is necessary to actually pass settings into the `Undoer`. Without
this, API consumers could construct their own `Settings` but not
actually do anything with it.
I've refrained from adding any kind of builder API for `Settings`
because there are only three options and I don't want to duplicate or
move all the documentation onto the builder methods.
The painter, allocated by `Ui::allocate_painter`, doesn't inherit
properties from the `Ui` object, leading to improper widget rendering in
`egui`.
Specifically, if the `Ui` object is disabled, the corresponding painter
should also be disabled.
<!--
Please read the "Making a PR" section of
[`CONTRIBUTING.md`](https://github.com/emilk/egui/blob/master/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 add commits to your PR.
* Remember to run `cargo fmt` and `cargo cranky`.
* 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!
-->
Adds a flag to ScrollArea that disables animations for the scroll_to_*
functions
Adds support for the ordering of windows passing through to the
underlying area.
Needed for a specific usecase of adding debug tools using windows with
the bevy integration.
At least all those above any interactive widget.
* Closes https://github.com/emilk/egui/issues/4286
I feel there is still more thinking to be done about what is considered
`hovered` and how it relates to `contains_pointer`, but this PR at least
fixes tooltips for uninteractive widgets
This means only one space allocation, which should allow putting it in
more types of layouts (right-to-left, centered, adjusted, …).
It also just makes the code simpler
`clicked_elsewhere` now checks against the clipped `interact_rect` of
the widget instead of the full `rect`.
In practice this shouldn't change much since the function is mostly used
for windows and areas, which aren't clipped.
This is mostly a refactor, but has some performance benefits:
* We (re)use the same tessellator as for everything else, leading to
less allocations
* We cull shapes before rendering them
Adding `RectShape::blur_width` means it can also be used for other
effects, such as glow.
Before, when setting the `zoom_factor`, the website was already
enlarged, but the zoom was ignored when calculating the logical window
size and mouse position, causing an offset between the actual cursor and
selected elements. That is addressed here
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
It would return the causes for repainting again collected this frame,
instead of the cause for repainting the current frame.
* Part of https://github.com/emilk/egui/issues/3931
Previously, putting the cursor in the gap between two menu buttons would
not hover any of the buttons, but the click-sensitive menu itself. Now
the menu is no longer click-sensitive.
This PR allows customizing the return key in the TextEdit widget. Right
now, it's hard-coded to the Enter key, which is problematic in cases
when you want to use the Enter key for something else, and insert the
newline in a different way instead.
* Closes#3987
* Closes#3988
There is a need to prevent egui::Window from becoming larger than the
Viewport.
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
I'm trying to create some custom collapsing headers that add additional
buttons inside the header itself. Because of this, I load the
`CollapsingState` in my special widget manually. But because
`HeaderResponse` owns the `Ui` and the `CollapsingState`, there is no
way for me to open/close the collapsing header based on response of the
inner widget.
Initially, I considered just exposing `state` member of
`HeaderResponse`, but that exposes too much of the API at the wrong
time, in my opinion.
So instead I found it'd be safer to just expose the open/close API to
the response itself, and that's what this PR does.
Not sure about the api, currently I've mapped the whole XWindowType
enum, but maybe there's something more sensible to do?
* Closes <https://github.com/emilk/egui/issues/4150>
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
I believe that the underlying issue that caused the stuck modifier keys
was resolved in the 0.29 winit keyboard refactor.
This probably needs to tested on other desktop platforms however since I
am only able to test this on windows 11.
* Closes <https://github.com/emilk/egui/issues/2332>
* Closes https://github.com/emilk/egui/issues/3444
* Closes https://github.com/emilk/egui/issues/865
On a touch screen, if you press down on a widget and hold for 0.6
seconds (`MAX_CLICK_DURATION`), it will now trigger a secondary click,
i.e. `Response::secondary_clicked` will be `true`. This means you can
now open context menus on touch screens.
This is a refactor on the way to add support for opening context menus
on touch screens via press-and-hold.
This PR changes what `InputState::button_clicked` does (it was ver badly
named before), and also changes `Response::clicked_by` to no longer be
true if clicking with keyboard (i.e. a widget has keyboard focus and the
user presses Space or Enter).
This PR fixes two issues related to `ScrollArea`.
1) When a `ScrollArea` would have `drag_to_scroll` set to `false` (e.g.
because some custom logic is at play or some other reason), it would not
animate to the `target_offset`, effectively making
`Response::scroll_to_me()` ineffective.
2) Single-direction `ScrollArea`s would leak the `scroll_target`'s other
direction. In certain specific circumstances (e.g. an horizontal area
nested in a vertical one, or inversely), this _could_ work as intended,
but in many other cases it could cause unwanted effects. With this PR,
both `scroll_target` directions are consumed by nearest enclosing
`ScrollArea`, regardless of the actually enabled scroll axes.
* Closes#3846
* Closes#3878
Dear emilk.
Leaving aside other function,
I think this is all you need to fix to patch the panic that occurs when
Shift + TAB.
Thank you, emilk.
Hi!
I'm using egui for the UI of a VST3/Clap plugin, and this kind of
environment is rather picky on performance. I use
[assert_no_alloc](https://crates.io/crates/assert_no_alloc) to make sure
the audio thread is never allocating. The audio thread may request a
repaint of the GUI tho, and this is where a saw that it may allocate
when tracing the repaint reason.
Turns out it's not necessary, `Location::caller` is `'static`, so using
a `&'static str` instead of a `String` in `RepaintCause::file` will just
work, so this PR just does that.
- Introduces `WidgetType::ProgressIndicator` and maps it to the
corresponding AccessKit role.
- A `Spinner` is now exposed as a widget indicating a progress for which
a completion state is not known.
- On the other hand, a `ProgressBar` reports a completion state and can
possibly be labeled. Note that a label is not used if not explicitly
asked by the user, as it would be redundant information. Assistive
technologies prefer the numerical value so they can, for instance, emit
beeps of which the frequency rise as the completion state increase. I
had to call `floor` on the progression as it seems all the ATs I tested
would round the value, hence reporting something different than what is
displayed on the label.
* Closes https://github.com/emilk/egui/issues/4113
Previously the `Id` of the menu `Area` was using the same id as the
thing that was clicked (i.e. the button opening menu), which lead to id
clashes
We plan to store input data for creating automated tests, hence the need
for more serde derives on input related structs.
---------
Co-authored-by: Georg Weisert <georg.weisert@freshx.de>
I often write constants at the top of my widget files, as a "config". I
kept writing stuff like that :
```rust
const DEFAULT_INNER_MARGIN: Margin = Margin { left: 17., right: 17., top: 7., bottom: 7. };
```
So I prefixed constructors for `Margin`, `Rounding` and `Shadow` const.
No code was changed.
I also added a `Shadow::new()` for similar reasons.
Raw mouse movement is unaccelerated and unclamped by screen boundaries,
and does not relate to any position on the screen.
It is useful in certain situations such as draggable values and 3D
cameras, where screen position does not matter.
https://github.com/emilk/egui/assets/1700581/1400e6a6-0573-41b9-99a1-a9cd305aa1a3
Added `Event::MouseMoved` for integrations to supply raw mouse movement.
Added `Response:drag_motion` to get the raw mouse movement, but will
fall back to delta in case the integration does not supply it.
Nothing should be breaking, but third-party integrations that can send
`Event::MouseMoved` should be updated to do so.
Based on #1614 but updated to the current version, and with better
fallback behaviour.
* Closes#1611
* Supersedes #1614
* Closes https://github.com/emilk/egui/issues/3936
* Closes https://github.com/emilk/egui/issues/3923
* Closes https://github.com/emilk/egui/pull/4058
The interaction code is now done at the start of the frame, using stored
`WidgetRect`s from the previous frame.
The intention is that the new interaction code should be more accurate,
making it easier to hit widgets, and better respecting the rules of
overlapping widgets.
There is a new `style::Interaction::interact_radius` controlling how far
away from a widget the cursor can be and still hit it. This helps big
fat fingers hit small widgets on touch screens.
This PR adds a new `Context::read_response` which lets you read the
`Response` of a `Widget` _before_ you create the widget. This can be
used for styling, or for reading the result of an interaction early (to
prevent frame-delay) for a widget you add late (so it is on top of other
widgets).
# ⚠️ BREAKING CHANGES
`Memory::dragged_id`, `Memory::set_dragged_id` etc have been moved to
`Context`.
The semantics for `Context::dragged_id` is slightly different: a widget
is not considered dragged until egui it is sure this is not a
click-in-progress. For a widget that is only sensitive to drags, that is
right away, but for widgets sensitive to both clicks and drags it is not
until the mouse has moved a certain distance.
# TODO
* [x] Fix panel resizing
* [x] Fix scroll hover weirdness
* [x] Fix Resize widget
* [x] Fix drag-and-drop
* [x] Test all of egui_demo_app
* [x] Change `is_dragging` API
* [x] Consistent naming of start/stop or begin/end drag
* [x] Test `egui_tiles`
* [x] Test Rerun
* [x] Document
* [x] Document breaking changes in PR description
* [x] Test one final time
# Saving for a later PR
* [ ] Fix https://github.com/emilk/egui/issues/4047
* [ ] Specify what the response order for e.g. `ui.horizontal` is
I think both these can be fixed if each `Ui` registers themselves as a
`WidgetRect`, with the possibility to interact with it later, as if the
interaction was under all widgets on top of it.
⚠️ Removes `Context::translate_layer`, replacing it with a sticky
`set_transform_layer`
Adds the capability to scale layers.
Allows interaction with scaled and transformed widgets inside
transformed layers.
I've also added a demo of how to have zooming and panning in a window
(see the video below).
This probably closes#1811. Having a panning and zooming container would
just be creating a new
`Area` with a new id, and applying zooming and panning with
`ctx.transform_layer`.
I've run the github workflow scripts in my repository, so hopefully the
formatting and `cargo cranky` is satisfied.
I'm not sure if all call sites where transforms would be relevant have
been handled. This might also be missing are transforming clipping
rects, but I'm not sure where / how to accomplish that. In the demo, the
clipping rect is transformed to match, which seems to work.
https://github.com/emilk/egui/assets/70821802/77e7e743-cdfe-402f-86e3-7744b3ee7b0f
---------
Co-authored-by: tweoss <fchua@puffer5.stanford.edu>
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
This PR short-circuits `Response::interact()` when the `Response` has
already been sufficiently "sensed" already. In some circumstance, this
can avoid unnecessarily registering another widget rect that may mask
some other widget.
One such instance is Rerun's `ListItem`. Calling `context_menu()` on its
response would call `interact` and, in turn, mask its sub-widget
(collapsing triangle, show/hide buttons, etc.).
Despite their being an actual `egui::Margin` struct, Textedit has a
`margin()` builder function that supports only `Vec2` types and thereby
only symmetric margins. This PR changes the function to accept
`egui::Margin` type instead making it more congruent with overall egui
logic as well as supporting asymmetric margins.
P.S: I tried to run all checks but I had to modify `./rust-toolchain` to
1.67.0 to get the checks to run on macOS.
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
<!--
Please read the "Making a PR" section of
[`CONTRIBUTING.md`](https://github.com/emilk/egui/blob/master/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 add commits to your PR.
* Remember to run `cargo fmt` and `cargo cranky`.
* 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 <https://github.com/emilk/egui/issues/3990>
`winit` supports up to F35, so thought it was better to just add them
all.
Exposes support in both glow and wgpu for texture wrap modes
This would be breaking for manual creations of TextureOptions but would
work with the current TextureOptions::NEAREST and LINEAR without change,
keeping those clamp to edge
I wasn't sure how best to expose the options to the user and added
consts for LINEAR_REPEAT LINEAR_MIRRORED_REPEAT NEAREST_REPEAT
NEAREST_MIRRORED_REPEAT
This does not include wrap mode clamp to border as it worked fine with
glow but with wgpu it panics due to Features
Features(ADDRESS_MODE_CLAMP_TO_BORDER) are required but not enabled on
the device, and I thought it was probably best not to try to enable that
feature, but happy to include that functionality also if that is okay to
be toggled
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
* Basic version of https://github.com/emilk/egui/issues/3931
This adds `Context::repaint_causes` which returns a `Vec<RepaintCause>`,
containing the `file:line` of the call to `ctx.request_repaint()`.
If your application is stuck forever repainting, this could be a useful
tool to diagnose it.
* Closes https://github.com/emilk/egui/issues/3941
Workspace dependencies can be annoying.
If you don't set them to `default-features=false`, then you cannot opt
out of their default features anywhere else, and get warnings if you
try.
So you set `default-features=false`, and then you need to manually opt
in to the default features everywhere else.
Or, as in my case, don't.
I don't have the energy to do this tonight, so I'll just revert.
Emil Ernerfeldt
sor-ca
Jan Procházka
Antoine Beyeler
lucasmerlin
Varphone Wong
zaaarf
Doonv
Oscar Gustafsson
YgorSouza
rustbasic
TicClick
hardlydearly
Dennis Schön
Joe Sorensen
lopo
zhatuokun
bu5hm4nn
valadaptive
Alexander Parlett
Juan Campa
Gustav Sörnäs
Justus Dieckmann
/lemon.sh
Zeenobit
Seth Rider
ming08108
Vincent Alsteen
Arnold Loubriat
Georg Weisert
0Qwel
Mike Tsao
Giantblargg
vincent-sparks
Francis Chua
AnotherNathan
Dan Lock