* 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.).
After merging PR #4036, build errors occurred in eframe-related
applications:
```log
error[E0432]: unresolved import `winapi::um::winuser`
--> crates\eframe\src\native\app_icon.rs:83:9
|
83 | use winapi::um::winuser;
| ^^^^^^^^^^^^^^^^^^^ no `winuser` in `um`
|
note: found an item that was configured out
--> C:\Users\Varphone\.cargo\registry\src\index.crates.io-6f17d22bba15001f\winapi-0.3.9\src\um\mod.rs:290:37
|
290 | #[cfg(feature = "winuser")] pub mod winuser;
| ^^^^^^^
= note: the item is gated behind the `winuser` feature
For more information about this error, try `rustc --explain E0432`.
error: could not compile `eframe` (lib) due to previous error
warning: build failed, waiting for other jobs to finish...
```
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!
-->
These are the latest versions of memoffset and arboard.
The changes to egui_glow/pure_glow allow downstream crates to not depend
on rwh 0.5, which is only needed for pure_glow (and other projects that
use glutin)
Thanks for your time & work
<!--
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.
This solves a GL_INVALID_ENUM error common on Windows (occurs on my
Windows 10 machine with a GTX 1070 Ti).
<!--
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!
-->
ARB_framebuffer_SRGB is entirely unsupported on WebGL, hence why latest
egui (master branch) doesn't try to disable SRGB framebuffers on wasm32
and this PR's code doesn't even check for ARB_framebuffer_sRGB on
wasm32.
* For <servo/servo#30782>
There was no way to customize this as ScrollArea gets created inside
Table widget, this exposes the functionality, so scroll bars on tables
can be customized.
<!--
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.
* 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!
-->
<!--
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.
* 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!
-->
`glyphon` requires the screen resolution during the `prepare` stage, and
passing that to the callback's `prepare` function seems pretty trivial.
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
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>
At crates\egui_extras\src\layout.rs :
Allocate allocation_rect instead of max_rect.
Go back from this:
```
let response = self.ui.allocate_rect(max_rect, self.sense);
let response = response.with_new_rect(allocation_rect);
return (used_rect, response)
```
to this:
```
let response = self.ui.allocate_rect(allocation_rect, self.sense);
return (used_rect, response)
```
In order to allocate the
Closes <https://github.com/emilk/egui/issues/3956>.
* 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
Francis Chua
Antoine Beyeler
YgorSouza
Dunfan Lu
Varphone Wong
bu5hm4nn
Magnus Larsen
Georg Weisert
njust
Oscar Gustafsson
Magnus Larsen
Richard Hozák
AnotherNathan
rustbasic
StratusFearMe21
Dan Lock
Ivan