allow multiple "Data Labels" per Series

Scenario / Use Case

It is very common to need multiple Data Labels for a particular set of points. For example, we might find that certain labels belong on the left, while other labels belong on the right, as shown in this image:

which comes from this example spreadsheet: data-labels.gnumeric

Desired Behavior

It would be great if we could simply add multiple Data Labels objects to a given Data Series in the obvious way.

Observed Behavior

The option to add another Data Series object vanishes if there is exactly one already, as shown in the aforementioned image. We would have expected Data Labels to be the top item on the Add menu, but we observe it has vanished.

Workaround

The traditional workaround is to duplicate the Series object as many times as necessary, as exemplified by the "dup points" series in the aformentioned .gnumeric file. We can then add a single Data Labels object to each Series. Typically N-1 of the Series are configured to have no lines and no symbols. This workaround is ugly and unduly laborious, especially when changes must be made to the Series.

Possible Fix + Some Test Results

I don't understand the code well enough to say for sure, but it "might" suffice to apply this simple patch: data-labels.patch

I have tested that this plots the Data Labels correctly, and that writing and re-reading a .gnumeric file works fine. The role_series_labels_can_add() check is static and called from only one place, so my guess is that this patch won't do too much damage, but somebody who understands the code should verify it.

Note that in the aforementioned .gnumeric file the "dup points" Series has a peculiar property: It already has two Data Labels objects, and you can add more — even with an unpatched version of gnumeric — since the existing check, oddly enough, checks for exactly one pre-existing Data Labels object. This may facilitate testing. Also it suggests that .gnumeric files with multiple Data Labels objects will be backwards-compatible with older versions of gnumeric, which is nice.

In other words, AFAICT this issue affects the pull-down Add menu and nothing else.

Tangential remark: FWIW writing and re-reading a .xls or .xlsx file never preserves data labels AFAICT, but that's a separate issue.

Platform

This is apparently platform-independent. Specifically, git-blame indicates that this issue affects all versions of goffice since 2011.