Add support for labels on-hover for bar plots

[eqbech]

Issue
Resolves #13474

Add support for on-hover labels for bar plots. PlotTools have been updated with a new method that takes care of on-hover labeling and its currently only supported for bar plots, but the template is outlined for different type of plots.

Math Func example

Egg example

[codecov-commenter]

Codecov Report

❌ Patch coverage is 40.81633% with 29 lines in your changes missing coverage. Please review.
✅ Project coverage is 89.92%. Comparing base (7aa972d) to head (9ff29b8).
⚠️ Report is 17 commits behind head on main.
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
...rc/ert/gui/tools/plot/plottery/plots/plot_tools.py	31.42%	24 Missing ⚠️
...ools/plot/plottery/plots/everest_gradients_plot.py	16.66%	5 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #13483      +/-   ##
==========================================
- Coverage   89.95%   89.92%   -0.04%     
==========================================
  Files         459      460       +1     
  Lines       32173    32372     +199     
==========================================
+ Hits        28942    29111     +169     
- Misses       3231     3261      +30     

Flag	Coverage Δ
cli-tests	37.17% <0.00%> (-0.16%)	⬇️
fuzz	44.05% <36.73%> (-0.10%)	⬇️
gui-tests	66.84% <40.81%> (+0.05%)	⬆️
performance-and-unit-tests	78.03% <40.81%> (+0.06%)	⬆️
test	45.61% <36.73%> (-0.17%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
src/ert/gui/tools/plot/plottery/plot_context.py	93.61% <100.00%> (+2.31%)	⬆️
...ools/plot/plottery/plots/everest_gradients_plot.py	16.39% <16.66%> (+0.32%)	⬆️
...rc/ert/gui/tools/plot/plottery/plots/plot_tools.py	72.88% <31.42%> (-17.71%)	⬇️

... and 16 files with indirect coverage changes

[eilskra]

Ref skjermbildet, hva betyr det øverste totallet?

[codspeed-hq]

Merging this PR will not alter performance

✅ 36 untouched benchmarks

---

_{Comparing add-bar-types-to-gradient-plot (36fa2c5) with main (beb9d13)}

[eilskra]

I would add f"value: {val:.3g}" to the value to prevent large numbers. The values can become really big

[eqbech]

Added label to appear on cursor hover position!

[andreas-el]

Regarding this tuple passed into this function, the use of data[0] and data[1] hides the content, making this a bit harder for the reader to understand what is going on.

Can we combine and create this up front instead? Thus avoiding much of the logic later on?

bar_label_pairs: list[tuple[Rectangle, str]] = []
 
 for i, control in enumerate(self.selected_controls):
     color = colors[i % len(colors)][0]
     values = []
     for batch_id in batch_ids:
         batch_data = combined[combined["batch_id"] == batch_id]
         match = batch_data[batch_data["control_name"] == control]
         values.append(
             match[response_key].to_numpy()[0] if not match.empty else 0.0
         )
 
     offsets = pos + (i - n_controls / 2) * bar_width + bar_width / 2
 
     bars = axes.bar(
         offsets,
         values,
         width=bar_width,
         color=color,
         alpha=0.7,
     )
     config.addLegendItem(control, bars[0])
 
     for batch_id, bar in zip(batch_ids, bars):
         bar_label_pairs.append((bar, f"batch {batch_id}\n{control}"))

[eqbech]

I agree it is clunky as it is now, im also thinking we might do something like this for the function signature of labels_on_hover

@staticmethod
def labels_on_hover(
    axes: Axes,
    plot_context: PlotContext,
    figure: Figure,
    **kwargs
) -> None:

As we dont yet know exactly what data the different plot types require and that they will most likely differ.

[eqbech]

Screen.Recording.2026-05-06.at.15.19.48.mov

[jaakson]

Screen.Recording.2026-05-06.at.15.19.48.mov

This looks good to me, with a couple of nitpicky comment-questions:

• If the pink background tint for the hover_box was not chosen for some specific reason (is it?), I propose swapping it out either for a tint that matches the hovered bar or a white tint (which improves legibility). If there is any possibility of really dark colours being used for the bars in the future, then a white tint is the way to go, imo.
• Can we do anything to lengthen the "hit area" around really short bars? My guess is users might be frustrated if they can only see a tooltip if they manage to hover over the tiny handful of pixels over/under the x axis.

[eqbech]

Screen.Recording.2026-05-06.at.15.19.48.mov

This looks good to me, with a couple of nitpicky comment-questions:

• If the pink background tint for the hover_box was not chosen for some specific reason (is it?), I propose swapping it out either for a tint that matches the hovered bar or a white tint (which improves legibility). If there is any possibility of really dark colours being used for the bars in the future, then a white tint is the way to go, imo.
• Can we do anything to lengthen the "hit area" around really short bars? My guess is users might be frustrated if they can only see a tooltip if they manage to hover over the tiny handful of pixels over/under the x axis.

Great Feedback!

I tried changing color from "pink" to "white". I guess its also possible to be more precise by using RGBA if needed. Regarding the "hit area" i agree. We do have a zoom functionality for the plots that may help with this. I think implementing "lengthening" of the bars can be a bit cumbersome. Attached is a screenshot of the smallest bar zoomed in, as well as the new color implemented!

[jaakson]

Attached is a screenshot of the smallest bar zoomed in, as well as the new color implemented!

That looks great! I forgot about the zoom -- that's sufficient, then, no need to mess around with hover hit zones then. 😄

(And I think RGBA would maybe just obfuscate things if we can otherwise go with "white", which is readable to everyone.)

[SAKavli]

I support the color change 🥇