* 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>
* 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.
* Closes https://github.com/emilk/egui/issues/3882
This adds several methods to make drag-and-drop more ergonomic in egui.
In particular, egui can now keep track of _what_ is being dragged for
you (the _payload_).
Low-level:
* `egui::DragAndDrop` hold the payload during a drag
Mid-level:
* `Response::dnd_set_drag_payload` sets it for drag-sources
* `Response::dnd_hover_payload` and `Response::dnd_release_payload`
reads it for drop-targets
High-level:
* `ui.dnd_drag_source`: make a widget draggable
* `ui.dnd_drop_zone`: a container where things can be dropped
The drag-and-drop demo is now a lot simpler:
https://github.com/emilk/egui/blob/emilk/drag-and-drop/crates/egui_demo_lib/src/demo/drag_and_drop.rs
---------
Co-authored-by: Antoine Beyeler <abeyeler@ab-ware.com>
This lets users specify the spacing of the grid lines and the axis
labels, as well as when these start to fade out.
New:
* `AxisHints::new_x/new_y` (replaces `::default()`)
* `AxisHints::label_spacing`
* `Plot::grid_spacing`
If a widgets sense both clicks and drags, we don't know wether or not a
mouse press on it will be a short click or a long drag.
With this PR, `response.dragged` and `response.drag_started` isn't true
until we know it is a drag and not a click.
If the widget ONLY senses drags, then we know as soon as someone presses
on it that it is a drag.
If it is sensitive to both clicks and drags, we don't know until the
mouse moves a bit, or stays pressed down long enough.
This PR also ensures that `response.clicked` and is only true for
widgets that senses clicks.
* Closes https://github.com/emilk/egui/issues/3816
Turn off with `style.interaction.multi_widget_text_select`.
There is an API for this in `LabelSelectionState`, but it's pretty
bare-bones.
This became really hairy implementation-wise, but it works decently
well.
# Limitations
* Drag-select to scroll doesn't work
* A selection disappears if you scroll past one of its end-points
* Only the text of labels and links are selectable
## TODO
* [x] An option to turn it off
* [x] An API for querying about the selected text, and to deselect it.
* [x] Scrolling past selection behaves weird
* [x] Shift-click to select a range
* Closes https://github.com/emilk/egui/issues/3804
Add ability to select the text in labels with mouse-drag, double-click,
and keyboard (once clicked).
Hit Cmd+C to copy the text. If everything of a label with elided text is
selected, the copy command will copy the full non-elided text. IME and
accesskit _should_ work, but is untested.
You can control wether or not text in labels is selected globally in
`style.interaction.selectable_labels` or on a per-label basis in
`Label::selectable`. The default is ON.
This also cleans up the `TextEdit` code somewhat, fixing a couple
smaller bugs along the way.
This does _not_ implement selecting text across multiple widgets. Text
selection is only supported within a single `Label`, `TextEdit`, `Link`
or `Hyperlink`.
## TODO
* [x] Test
<!--
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!
-->
Closes <https://github.com/emilk/egui/issues/THE_RELEVANT_ISSUE>.
This PR replaces an old one with many problems (no collapse icon, the
header background was not funny colored, ugly...). It fixes those
problems.
It implements the highlight of the header to the focused window. And
allows the rest of the application to know the selected window. It
allows, for instance, to display multiple windows with images and some
additional meta information about those images on the side panel of the
main window. The side panel updates itself according to the selected
image window.
* Added a theme color for the selected window header.
* Added a function to retrieve the LayerId of the focused window.
* Implemented a simple demo of this function in the demo app where a
message states if the Option window is focused (at the bottom of the
Options window).
A technical point:
The header color is applied with a transparency of 125 so the
collapsible button becomes visible.
The reason is that the collapsible button is rendered before the rest of
the header and before the header size is known.
We cannot draw the background before knowing this value, so rendering
with transparency is a solution to see the collapsible button through
the header background.
This PR has been sponsored by my company, which left me to do it during
my work time.
This is part of an evil plan to convince them to switch to rust for new
projects :)
---------
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.
* 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!
-->
* Based on #3105 by @vvv.
## Additions and Changes
- Add `TableBuilder::sense()` and `StripBuilder::sense()` to enable
detecting clicks or drags on table and strip cells.
- Add `TableRow::select()` which takes a boolean that sets the highlight
state for all cells added after a call to it. This allows highlighting
an entire row or specific cells.
- Add `TableRow::response()` which returns the union of the `Response`
of all cells added to the row up to that point. This makes it easy to
detect interactions with an entire row. See below for an alternative
design.
- Add `TableRow::index()` and `TableRow::col_index()` helpers.
- Remove explicit `row_index` from callback passed to
`TableBody::rows()` and `TableBody::heterogeneous_rows()`, possible due
to the above. This is a breaking change but makes the callback
compatible with `TableBody::row()`.
- Update Table example to demonstrate all of the above.
## Design Decisions
An alternative design to `TableRow::response()` would be to return the
row response from `TableBody`s `row()`, `rows()` and
`heterogeneous_rows()` functions. `row()` could just return the
response. `rows()` and `heterogeneous_rows()` could return a tuple of
the hovered row index and that rows response. I feel like this might be
the cleaner soluction if only returning the hovered rows response isn't
too limiting.
I didn't implement `TableBuilder::select_rows()` as described
[here](https://github.com/emilk/egui/pull/3105#issuecomment-1618062533)
because it requires an immutable borrow of the selection state for the
lifetime of the `TableBuilder`. This makes updating the selection state
from within the body unnecessarily complicated. Additionally the current
design allows for selecting specific cells, though that could be
possible by modifying `TableBuilder::select_rows()` to provide row and
column indices like below.
```rust
pub fn select_cells(is_selected: impl Fn(usize, usize) -> bool) -> Self
```
## Hover Highlighting
EDIT: Thanks to @samitbasu we now have hover highlighting too.
~This is not implemented yet. Ideally we'd have an api that allows to
choose between highlighting the hovered cell, column or row. Should
cells containing interactive widgets, be highlighted when hovering over
the widget or only when hovering over the cell itself? I'd like to
implement that before this gets merged though.~
Feedback is more than welcome. I'd be happy to make any changes
necessary to get this merged.
* Closes#1519
* Closes#1553
* Closes#3069
---------
Co-authored-by: Samit Basu <basu.samit@gmail.com>
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
This introduces a special `Color32::PLACEHOLDER` which, during text
painting, will be replaced with `TextShape::fallback_color`.
The fallback color is mandatory to set in all text painting. Usually
this comes from the current visual style.
This lets users color only parts of a `WidgetText` (using e.g. a
`LayoutJob` or a `Galley`), where the uncolored parts (using
`Color32::PLACEHOLDER`) will be replaced by a default widget color (e.g.
blue for a hyperlink).
For instance, you can color the `⚠️`-emoji red in a piece of text red
and leave the rest of the text uncolored. The color of the rest of the
text will then depend on wether or not you put that text in a label, a
button, or a hyperlink.
Overall this simplifies a lot of complexity in the code but comes with a
few breaking changes:
* `TextShape::new`, `Shape::galley`, and `Painter::galley` now take a
fallback color by argument
* `Shape::galley_with_color` has been deprecated (use `Shape::galley`
instead)
* `Painter::galley_with_color` has been deprecated (use
`Painter::galley` instead)
* `WidgetTextGalley` is gone (use `Arc<Galley>` instead)
* `WidgetTextJob` is gone (use `LayoutJob` instead)
* `RichText::into_text_job` has been replaced with
`RichText::into_layout_job`
* `WidgetText::into_text_job` has been replaced with
`WidgetText::into_layout_job`
* Closes https://github.com/emilk/egui/issues/3602
You can now zoom any egui app by pressing Cmd+Plus, Cmd+Minus or Cmd+0,
just like in a browser. This will change the current `zoom_factor`
(default 1.0) which is persisted in the egui memory, and is the same for
all viewports.
You can turn off the keyboard shortcuts with `ctx.options_mut(|o|
o.zoom_with_keyboard = false);`
`zoom_factor` can also be explicitly read/written with
`ctx.zoom_factor()` and `ctx.set_zoom_factor()`.
This redefines `pixels_per_point` as `zoom_factor *
native_pixels_per_point`, where `native_pixels_per_point` is whatever is
the native scale factor for the monitor that the current viewport is in.
This adds some complexity to the interaction with winit, since we need
to know the current `zoom_factor` in a lot of places, because all egui
IO is done in ui points. I'm pretty sure this PR fixes a bunch of subtle
bugs though that used to be in this code.
`egui::gui_zoom::zoom_with_keyboard_shortcuts` is now gone, and is no
longer needed, as this is now the default behavior.
`Context::set_pixels_per_point` is still there, but it is recommended
you use `Context::set_zoom_factor` instead.
* Closes#1974
<!--
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 you PR, but my time is limited!
-->
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
