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.
This makes the sizing pass of an `egui_table` ensure the table uses as
little width as possible.
Subsequently, it will redistribute all non-resizable columns on the
available space, so that a table better follow the parent container as
it is resized.
I also added `table.reset()` for forgetting the current column widths.
<!--
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!
-->
This prevents TextEdit widgets from sending fake primary clicks when a
user types Space / Enter. Small change but having Space / Enter send
`OutputEvent::ValueChanged` instead of `OutputEvent::Clicked` makes more
sense I believe.
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
Marking widgets as disabled was not reflected in the accesskit output,
now the disabled status should match.
---------
Co-authored-by: Wybe Westra <w.westra@kwantcontrols.nl>
This allows users to customize how numbers are converted into strings in
a `DragValue`, as a global default.
This can be used (for instance) to show thousands separators, or use `,`
as a decimal separator.
The default `Plot` formatter now picks precision intelligently based on
zoom level. The width of the Y axis are is now much smaller by default,
and expands as needed.
Also deprecates `Plot::y_axis_with`; replaced with `y_axis_min_width`.
Set `auto_shrink(false)` on `Window`s `ScrollArea`.
This ensures that the scroll bars are always the outermost.
* Closes https://github.com/emilk/egui/pull/4602
* Fixes https://github.com/rerun-io/rerun/issues/6638
* Related? https://github.com/emilk/egui/issues/4563
This improves how an eframe canvas works inside of a larger web page,
and how it works when there are multiple eframe apps in the same page.
`eframe` will set `tabindex="0"` on the canvas automatically, making it
focusable.
It will also set `outline: none` on the CSS, so the focused canvas won't
have an ugly outline.
## Breaking changes
You may wanna add this to your `index.html` to give the canvas focus on
startup:
```js
document.getElementById("the_canvas_id").focus();
```
## Test setup
```sh
./scripts/build_demo_web.sh
./scripts/start_server.sh
open http://localhost:8888/multiple_apps.html
```
Then open the "Input Event History" and "Text Edit" windows
## Tested
* Chromium
* [x] drag-and-drop of files
* Test both when a `TextEdit` is focused and when it is not:
* [x] `Event::Key`
* [x] `Event::Text`
* [x] copy-cut-paste
* [x] Wheel scroll
* [x] `Event::PointerGone`
* [x] Mouse drag
* [x] Mouse click
* [x] Mouse right-click
* [x] Defocus all eframe canvas, and then start typing text
* [x] Firefox (all of the above)
* [x] Desktop Safari (all of the above)
* [x] Mobile Safari
## Future work (pre-existing issues)
* https://github.com/emilk/egui/issues/4723
* https://github.com/emilk/egui/issues/4724
* https://github.com/emilk/egui/issues/4725
* https://github.com/emilk/egui/issues/4726
For a project I am currently attempting to use the acceskit output of
egui to preform end-to-end integration tests of my application. However,
the output is currently quite basic (buttons for example don't report
that they are disabled).
Before adding new features to the acceskit integration, I thought it
would be a good idea to add some testing to egui's accesskit output.
I have started with a simple test for button texts, to get feedback on
whether this is the correct direction to go in.
---------
Co-authored-by: Wybe Westra <w.westra@kwantcontrols.nl>
Emil Ernerfeldt
rustbasic
lucasmerlin
William Zhang
Wybe Westra
Andreas Reich