Draw axis labels and ticks outside of plotting window

[JohannesProgrammiert]

• ⚠️ BREAKING: egui::widgets::plot::Plot::show_axes renamed to egui::widgets::plot::Plot::show_grid. The origin show_axes API now refers to the axis labels
• Added plot axis labels and the required API to customize them
• Added support for multiple x-axis- and y-axis-labels and -ticks per plot

---

All better known plotting libraries like gnuplot, matlab, and also Implot draw the ticks outside of the plotting window:

egui paints the ticks inside the plotting window, which is unusual and, in my opinion, inconvenient.
In the same region, axis labels should be drawn.

• add a screenshot or gif.
• add a line to the relevant CHANGELOG.md under "Unreleased".
• consider adding a demo for it to egui_demo_lib.
• run cargo fmt and cargo clippy.
• run ./scripts/check.sh.

• Blocks Heatmap Widget for Plots egui_plot#6
• Closes Axis legends for Plots #889

[JohannesProgrammiert]

Support for labels is done. I changed the API for Plot but further information will follow once I managed to move tick labels to the outside.

egui_labels.webm

[JohannesProgrammiert]

[nknotts]

I am testing out this branch. Would you like feedback or wait until you finish developement?

[JohannesProgrammiert]

I would love some feedback if you have time.

However, somebody will have to review this again in 1-2 weeks because I plan to make the axis-API a bit more convenient.

[nknotts]

This has allowed me to make our engineering dashboard with good looking plots!

[JohannesProgrammiert]

./sh/check.sh doesn't work for me.

❯ ./sh/check.sh
+ cargo install cargo-cranky
    Updating crates.io index
     Ignored package `cargo-cranky v0.3.0` is already installed, use --force to override
+ export 'RUSTFLAGS=--cfg=web_sys_unstable_apis -D warnings'
+ RUSTFLAGS='--cfg=web_sys_unstable_apis -D warnings'
+ export 'RUSTDOCFLAGS=-D warnings'
+ RUSTDOCFLAGS='-D warnings'
+ cargo check --all-targets
    Finished dev [optimized + debuginfo] target(s) in 0.30s
+ cargo check --all-targets --all-features
    Checking serde v1.0.143
    Checking tracing v0.1.36
    Checking zerocopy v0.6.1
   Compiling speech-dispatcher-sys v0.7.0
    Checking wgpu-hal v0.14.0
   Compiling zvariant_derive v3.6.0
   Compiling zbus_macros v2.3.2
    Checking resvg v0.23.0
    Checking smithay-clipboard v0.6.6
    Checking web-sys v0.3.60
    Checking sctk-adwaita v0.4.2
    Checking winit v0.27.2
    Checking half v1.8.2
error: failed to run custom build command for `speech-dispatcher-sys v0.7.0`

Caused by:
  process didn't exit successfully: `egui/target/debug/build/speech-dispatcher-sys-511605648ffbec9f/build-script-build` (exit status: 101)
  --- stdout
  cargo:rustc-link-lib=speechd

  --- stderr
  wrapper.h:1:10: fatal error: 'speech-dispatcher/libspeechd.h' file not found
  thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: ClangDiagnostic("wrapper.h:1:10: fatal error: 'speech-dispatcher/libspeechd.h' file not found\n")', $CARGO_HOME/registry/src/github.com-1ecc6299db9ec823/speech-dispatcher-sys-0.7.0/build.rs:22:10
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...  

Everything else seems ok.

[emilk]

Thanks for working on this, and it looks fantastic!

I do like this feature, but one immediate problem I see is how much whitespace it uses up, especially on the X axis. Take a look at these before-and-after pictures from the demo:

Before:

After:

That's basically half as much plot as before.

Perhaps we need to tweak the default. I see no need for the names here ("x" and "y") when they were not explicitly given. And the left side could probably have a thinner default width. Is it configurable?

[JohannesProgrammiert]

Thanks for your feedback.

a thinner default width

Can be changed in the AxisHints::Default trait implementation.

Is it configurable?

The width is configurable by AxisHints::max_digits(usize) for each AxisHints that is passed to Plot::custom_y_axes(). This is, however, more of a 'proof-of-concept'-feature because it does not yet account for different font sizes. It always assumes 12pt per digit.

I didn't figure out how to determine the size of one digit without drawing it first...

one immediate problem I see is how much whitespace it uses up, especially on the X axis

In issue #889 I discussed this and made a proposal for automatically calculated y-axis-width. I am not sure it'd pay off because this feature might introduce some weird edge case behavior and makes the widget layout computation unnecessarily complex.

Perhaps we need to tweak the default. I see no need for the names here ("x" and "y") when they were not explicitly given.

I think plots without axis labels should be the exception, not the other way round. If someone really wants a plot without axis labels it should be specified explicitly. But if you are sure about removing labels by default I'll just do it.

[emilk]

I think plots without axis labels should be the exception, not the other way round. If someone really wants a plot without axis labels it should be specified explicitly. But if you are sure about removing labels by default I'll just do it.

I think this is a user problem. That is: users should name their axes, and we should encourage that (e.g. by always doing so in all examples), but "x" and "y" aren't names. If the user is plotting cpu usage over time, calling the axes "x" and "y" is probably worse than having no names at all.

[nknotts]

I agree with @emilk. Axis labels should be optional, but should be promoted in all examples.

[Malven31]

Hi there =)
I'm quite new to open source merge requests and all that, and quite noob about rust, so my question is for sure going to sound silly : is there any chance this MR gets merged ? I'm trying to compile this by my own (to use eframe with this fork of egui), and struggling like hell...
Sorry to bother !

[jakkos-net]

@Malven31 It may be worth looking into https://github.com/Gip-Gip/egui-plotter while we wait for this to be merged. I haven't tried it myself yet, but it looks promising.

[emilk]

It looks and works great! I left some comments on the code though, but nothing major

[emilk]

It would be nice to add an example of using these new functions to the doctest of Plot (perhaps as a new example)!

[wlwatkins]

This is great work, but i'm confused. Is it possible to keep the axis in old fashion way? it's quite useful for highly compact multiplots.