The mapping feature is a bit unintuitive. It maps settings and stores them for later reuse, even after the panel has been destroyed. Developers and users are forced to use this (anti-)feature as there is no way to turn it off without breaking it. Every SWT Chart UI action will internally update the mappings:
Consumer of SWT Chart are allowed to change the values, but cannot update the mapping, leaving the chart labels in a buggy state where it causes inconsistencies when mixing settings which are mapped and ones that aren't.
I propose to simply make the mapping API public, so developers have the full flexibility whether to map or not in that situation instead of mapping in functions like setDescription.
The mapping feature is a bit unintuitive. It maps settings and stores them for later reuse, even after the panel has been destroyed. Developers and users are forced to use this (anti-)feature as there is no way to turn it off without breaking it. Every SWT Chart UI action will internally update the mappings:
https://github.com/eclipse/swtchart/blob/a6dda0bbfa38934a5a9c6324bcf94bc24687fbd9/org.eclipse.swtchart.extensions/src/org/eclipse/swtchart/extensions/menu/legend/SetDescriptionAction.java#L81-L83
Consumer of SWT Chart are allowed to change the values, but cannot update the mapping, leaving the chart labels in a buggy state where it causes inconsistencies when mixing settings which are mapped and ones that aren't.
I propose to simply make the mapping API public, so developers have the full flexibility whether to map or not in that situation instead of mapping in functions like
setDescription
.