Updated the `show_content` method of the `TextEdit` widget so that the
requested text alignment (if any) is also applied to the hint text.
Currently, hint text is always aligned to the top left of the widget,
which may be inconsistent with the actual location of text entered by
the user. I think it's more intuitive for the hint text to be positioned
as if the user had entered the same text themselves.
Here are some comparisons of the difference between how the hint text
and the entered text looks, before and after this change:
### Previous Behaviour
### Updated Behaviour
* [x] I have followed the instructions in the PR template
* [x] I have followed the instructions in the PR template
Clarified that `eframe::run_simple_native()` does in fact save some
state (if persistence is enabled) but does not allow user to save state.
<!--
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 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!
-->
* [x] I have followed the instructions in the PR template (less the
self-review using the script as it's only a single word change).
<!--
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 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!
-->
added return ScrollAreaOutput.
This can be used to monitor the scroll progress of a table(usage
example: custom scroll progress bar or lazy loading table)
* [X] I have followed the instructions in the PR template
<!--
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 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 https://github.com/emilk/egui/issues/3453
* [x] I have followed the instructions in the PR template
I'm fairly new to egui.
I read the code, but I didn't follow the approach mentioned in
https://github.com/emilk/egui/issues/3453#issuecomment-2208255433.
I believe this is an easier way to achieve that, though I'm not certain
if it's the best method.
<img width="760" alt="image"
src="https://github.com/user-attachments/assets/4b3c561f-1c24-446b-9581-a2f4e9858480">
I get really nice svg with this patch.
@emilk Can you please take a look? I really need this!
<!--
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!
-->
I find myself wanting this API quite a lot, and I imagine it'll probably
be useful for others.
# What?
This PR adds `Rect::scale` and `Rect::scale2` functions, which work a
lot like `expand`, but instead multiply by a scale.
i.e.
```rs
rect.scale(2.0); // rect is 2x as big, still in same center
rect.scale2(vec2(1.5, 2.0)); // rect is 1.5x as big on x axis, 2.0x as big on y axis. still in same center
```
# Why?
Before this you either had to write this yourself or use a `expand` in a
cumbersome way:
```rs
rect.expand2(vec2(rect.width() * scale.x / 2.0, rect.height() * scale.y / 2.0));
```
I find myself wanting to scale things up by a factor frequently enough,
and it seems like a useful addition to have a multiply-based variant of
`expand`.
I realise this is pretty minor, but it seems useful enough to me!
---------
Co-authored-by: zkldi <20380519+zkldi@users.noreply.github.com>
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
# Changes
- Adds a new function `egui::Ui::columns_const()`, which is the same as
`egui::Ui::columns()` except that it uses a `const` parameter for the
column count.
- Backed by an array `[Ui; NUM_COL] instead of a `Vec<Ui>`, so fewer
allocations
- Inner closure takes in an array reference, instead of a slice
reference. This makes it possible to use pattern destructuring on the
columns, as shown in the example, and makes it more ergonomic to use
# Example
```rust
// ORIGINAL
ui.columns(2, |cols| {
cols[0].label("one");
cols[1].label("two");
});
// NEW
ui.columns_const(|[a,b]| {
a.label("one");
b.label("two");
});
```
# Checks
- [X] `cargo fmt`
- [X] `cargo clippy`
- [X] `./scripts/check.sh`
- [X] Docs
- [ ] Review
* Closes https://github.com/emilk/egui/issues/1713
I almost went to implement my own undo/redo system, and then found the
egui undoer.
Went to make a small demo to test for myself how it worked, and then
found the linked issue.
So here is a tweaked version of that :)
Co-authored-by: Wybe Westra <w.westra@kwantcontrols.nl>
<!--
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 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!
-->
I added a util function `set_hovered` to change the hovered state of a
row from tables in `egui_extras` which matches the already present
`set_selected` function.
* [x] I have followed the instructions in the PR template
<!--
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 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 https://github.com/emilk/egui/discussions/4670
* [x] I have followed the instructions in the PR template
`egui::Table` has a weirdly specific default `max_scroll_height` set to
800.0. This means that even with `vscroll(true)` and `auto_shrink([_,
false])`, the table will not expend to the full available height. This
PR changes this value to `f32::INFINITY`. This makes it consistent with
the corresponding default value of `ScrollArea::max_size.y`, which is
where that `max_scroll_height` ends up being used.
Improved `change_gl_context()`
**Before:**
Create a new `not_current_glcontext`.
**After:**
If `not_current_glcontext` exists, apply it. Otherwise, create it.
This will make the program smoother when dragging, etc.
In order to make it possible that all buttons can have the same style
with a text and an image I created a `menu_text_image_button`.
It works the same way as all the other menu buttons.
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
Handle the `IME` event first
There is a need to handle the Ime event first.
Fix Issues : When you press `BackSpace`, the entire text is erased, and
when you press another letter, it appears again.
Fix Issues : When you press `Left`, the character being entered will be
copied once more.
Fix Issues : When you press `Enter`, `Enter` with `repeat` set is
entered and `Enter` is entered twice.
Fix Issues : When you press a key in `IME` mode, `repeat` is often set.
Fix Issues : Since you may be selecting something in the IME, this also
disables the `Arrow` keys.
Before, you could accidentally get multiple tooltips if a tooltips was
interactive (e.g. had a link in it) and on the way to interact with it
you would hover another widget with a tooltip.
This PR ensures that each `LayerId` only has one tooltip open at a time.
You can still have a tooltip for an item inside of a tooltip.
PrimmR
Tyler Stevens
Onè
rustbasic
Andreas Reich
Salman Abuhaimed
Simon Niedermayr
frederik-uni
Xavier Lau
zk
Jan Procházka
Emil Ernerfeldt
v0x0g
Wybe Westra
Addis Webb
Antoine Beyeler
Wojciech Muła
Nicolas Bircks
Joe Sorensen
Jonas Wagner
YgorSouza
lucasmerlin