Horizontally adjacent plots separated by larger margin in v0.23.0
ryanavella opened this issue · 2 comments
Describe the bug
When switching from egui::plot
(v0.22.0) to egui_plot
(v0.23.0), horizontally adjacent plots are now separated by an awkwardly large margin.
To Reproduce
This is an attempt to produce a MRE from my own code, it might be further reducible. For v0.23.0, replace egui::plot
with egui_plot
use eframe::egui::{self};
use egui::plot::{Line, Plot, PlotPoints};
fn main() {
let _ = eframe::run_native("", Default::default(), Box::new(|_cc| Box::new(Foo)));
}
struct Foo;
impl eframe::App for Foo {
fn update(&mut self, ctx: &egui::Context, _frame: &mut eframe::Frame) {
egui::CentralPanel::default().show(ctx, |ui| {
const SIZE: f32 = 200.0;
let v = vec![[0.0, 0.0], [1.0, 1.0]];
ui.horizontal(|ui| {
Plot::new(0).height(SIZE).width(SIZE).show(ui, |ui| {
ui.line(Line::new(PlotPoints::from(v.clone())));
});
Plot::new(1).height(SIZE).width(SIZE).show(ui, |ui| {
ui.line(Line::new(PlotPoints::from(v)));
});
});
});
}
}
Expected behavior
Probably the old behavior from v0.22.0?
Screenshots
v0.22.0
v0.23.0
Desktop (please complete the following information):
- OS: Windows 10
- Browser: Chrome
- Version: v0.23.0
As the axes are now outside the plot viewbox, the widget has to reserve some room for them. This is controlled by the y_axis_width or the custom_y_axes methods.
The code actually has a little diagram explaining how it works.
There doesn't seem to be any way to restore the previous behavior with the axes inside the plot, though (I could be wrong about that, as I haven't kept up with this development and there is a lot of code to read through).
Nice catch! I was quickly comparing 0.22.0 and 0.23.0 side-by-side and didn't notice any API differences, but I totally missed the addition of the new methods Plot::y_axis_width
and Plot::custom_y_axes
.
Applying .y_axis_width(1)
gets me 90% of the way there, but there is one big downside: my plots are dynamically updating so I can't predict with certainty how long the tick labels are. Some tick labels will just be 0
and others might be -1e2
, for example.
One solution could be adding new variants to HPlacement
for inline labels, though I haven't been following development so I don't know how simple it is to bring back the old behavior. If there was a lot of major refactoring between 0.22.0 and 0.23.0 for example, I could see this being a very non-trivial task.