emilk / emilk/egui

`egui::Response` "finished"/"complete" predicate

Open
#3,752 5 comments 2 reactions 0 assignees View on GitHub
Dominant language
Rust
Stars
30.6k
Forks
2.1k
Avg merge
1d 12h
Merged PRs (30d)
67

Description

**Is your feature request related to a problem? Please describe.**
Some widgets have a way to detect when the input is "finished," the exact meaning of which is contextual to the widget. Single-line text fields have `response.lost_focus()`, `DragValue` has `.update_while_editting(false) .... .changed()`, buttons have `.clicked()`, but many do not - Multiline textfields, sliders, and color pickers, for example, and there is no consistent way to construct this from the returned `Response` without digging into the source for the widget and knowing what each `response` predicate corresponds to - and there is no guarantee that such info can be derived at all, in the case of the color pickers.

This is useful for when a value-in-flux should be used differently then the crystalized value, for example a cheap preview for a changing value and an expensive full-quality version when the interaction is finished, or submitting a history state only for finished values. (my exact usecases!)

**Describe the solution you'd like**
Response could have an additional `.finished()`/`.completed()`/`.ended()`, ect. predicate to report the end of these contextual interactions, explicitly provided by the widget logic - it is not possible to derive from the other fields of the response.

**Describe alternatives you've considered**
I have written a [`latch` wrapper](https://github.com/Fuzzyzilla/fuzzpaint/blob/416e9a59f30f83f8ce56aa009f1461db4948ac8d/src/ui.rs#L990) providing this functionality (and a bit more) manually, however it involves lots of boilerplate for use at the callsite and still requires a way for user code to query whether an interaction is "ongoing" in the context of the relevant widget - not always possible, in the context of the color picker and others, resulting in bad hacks to check (eg, global mouse button state).

**Additional Context**
This isn't always meaningful for every widget with a response, but the response API has such fields already - a label has no concept of "finished" but it also doesn't have a concept of "dragged," alas the latter is still provided.

I would be willing to implement this for existing widgets, if it is agreed that this isn't a horrible idea! :3

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.