Bug 564143 - AbstractSelectTreeViewer#getLegendImage(String) no longer behaves in the same way
Summary: AbstractSelectTreeViewer#getLegendImage(String) no longer behaves in the same...
Status: NEW
Alias: None
Product: Tracecompass
Classification: Tools
Component: TMF (show other bugs)
Version: unspecified   Edit
Hardware: PC Linux
: P3 normal
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact: Project Inbox CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-06-09 15:58 EDT by Matthew Khouzam CLA
Modified: 2020-06-09 18:40 EDT (History)
2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Matthew Khouzam CLA 2020-06-09 15:58:36 EDT 
Before, there would be a way to get the image from a path like /trace/category/counter. Now it throws an NPE.

The behavior is "desired" but harsh for extenders. I recommend a slight roll-back here.
Comment 1 Genevieve Bastien CLA 2020-06-09 16:12:15 EDT 
Could you please provide some stack traces of that NPE?
Comment 2 Patrick Tasse CLA 2020-06-09 18:40:32 EDT 
I think the problem is as such:

A plug-in extension has a TmfChartView that has its own TreeLabelProvider that gets the legend image by name.

This eventually gets to XYPresentationProvider.getAppearance() which assigns a sequential id to this series appearance in the fStringToId map, and uses this id to put in fYAppearances map.

On the chart side, with the new changes XYPresentationProvider.getSeriesStyle() is called with the real model id. As it doesn't match the id assigned to the tree legend, a new appearance is created, and the color in tree legend and chart do not match.

This can be fixed in the plug-in extension (for example by letting it use the new default DataProviderTreeLabelProvider), but it means that the recent changes introduced in and around https://git.eclipse.org/r/159345 are not backward compatible.