Enhance legend label color point when usePointStyle is true

[alfiehopkin]

Allow for users to add in an extra parameter to the label options which changes the size of the legend box separate to the font size. This doesn't affect current functionality, but adds to it.

[benmccann]

This would have to be added to the documentation. I don't quite understand the feature, but haven't spent much time looking at the PR yet. Can you share a jsfiddle, codepen, or screenshot of what this looks like before and after the change to help demonstrate what you're changing?

[alfiehopkin]

Sorry for little information in the previous, and sorry for the delay in reply.

I understand (and agree) that this would have to be added to the documentation.

The reason for this PR is that I often find myself having to build custom legends for charts, even though all I really want to do it have the standard legend, with circles instead of rectangles. This is possible but then you have to deal with the circle being the same size as the font size, where I want to have the ability to customise the size of the circle independently to the font size.

The proposed solution does not break any current usage, instead it just adds the ability to override the default of using the font size with a custom value.

What currently happens:

What I have proposed:

The legend options code would then be as follows (instead of having to create a custom legend, and events):

Removing the circleSize would then default to using the fontSize because we have set usePointStyle: true.

Hope that this helps describe the PR in more detail.

EDIT:
Also circleSize could be changed to pointSize to be more generic.

[benmccann]

+1 to calling it pointSize instead of circleSize

[alfiehopkin]

@benmccann I have changed circleSize to pointSize and added pointSize to the documentation in my recent commits.

Should this now go to review?

[benmccann]

I don't know this section of the code all that well, so I'll let the others review it. My main question is why do we need boxWidth and pointSize? Why not just use boxWidth in both cases? Otherwise it looks good to me

[alfiehopkin]

@benmccann To be honest, I'm not sure why the functionality isn't allowed. There is a function called getBoxWidth which is in place to prevent the use of boxWidth and replace it with fontSize if usePointStyle is true. I don't know the reasoning for this so I just found it best to build on top an override instead of messing with the underlying code.

Can you label this as waiting for review? I can't do this for some reason.

[kurkle]

This getBoxWidth was introduced in #3323 (to fix #3292). But the math was introduced already in the original PR #2902 that introduced usePointStyle.

I think the reasoning behind is to provide good default, when usePointStyle: true (40 would be a bit large in most cases)

IMO this is a configuration resulution issue and boxWidth should be obeyed if user supplied it, regardless of usePointStyle. And secondly the provided default seems a bit large?
The problem is that those defaults get merged to options and we really don't know if it was supplied by user.

So I would not add a new option for this. Instead I would fix the math for better default and honor user provided value over default in any case (this second part might be another PR).
What do others think?

[alfiehopkin]

@kurkle I agree that this could just involve fixing the existing code, I just didn't want to break any existing functionality with this change.

I will look into this in more detail and remove the additional option, and instead work on a fix to allow for the user to override the default with the current boxWidth option.

[simonbrunel]

I agree we shouldn't introduce a new option, though I wouldn't change the default (40), neither try to change the resolution order. To me, the point size should be min(boxWidth, boxHeight) (i.e. the circle inscribed in the label box), so basically min(boxWidth, fontSize).

[alfiehopkin]

@simonbrunel sounds like a better approach again that.

[kurkle]

@simonbrunel I was talking about the default when usePointStyle: true (= the math). I think the font.lineHeight could be even better than font.size (and radius of just half of that?).

Also I don't see why its calculated inside those loops in fit, nothing changes per item.

[simonbrunel]

I'm not sure about font.lineHeight because the line height includes the space between each lines. Here I think we want the point to be the same size as the text, so to me it should be something like:

if (opts.labels && opts.labels.usePointStyle) {
    var radius = Math.min(boxWidth, fontSize) / 2;
    // ...

[alfiehopkin]

@simonbrunel @kurkle in the recent commits, default functionality remains the same when usePointStyle is set to false. When true, the box width is based on min(boxWidth, fontSize). The positioning is accurate and inline on the y axis as should be also.

I have also updated the docs to suit changes.

[kurkle]

A pen to play with (b6acb9f): https://codepen.io/kurkle/full/pGgJMZ

And previous (80f117d): https://codepen.io/kurkle/full/GzopJm

[alfiehopkin]

What is the next step for this PR?

[kurkle]

What is the next step for this PR?

Wait for reviews

[kurkle]

plugins.legend.js is not quite up to the coding standards. So I'll ignore the surroundings on focus on change.

[benmccann]

The current proposed solution seems a bit non-intuitive to me. It seems strange to me that changing the shape should change the size as well. Doing the minimum of the two values also seems weird because it means that boxWidth can only make the point smaller, but you can never make it bigger.

One problem is that boxWidth was really only meant to control the width and now we're trying to use it for the height. Maybe we also need a boxHeight option? The boxHeight could be undefined by default and fall back to fontSize in that case. If set it could control the height regardless of the value of usePointStyle

[benmccann]

@alfiehd you'll need to rebase this PR

[alfiehopkin]

@kurkle @etimberg I had to merge changes with conflicts in the legend.md doc file.

@benmccann I am not familiar with rebasing. I've done some research but is there a specific procedure in this repo?

[benmccann]

@alfiehd it looks like you did the rebase correctly. By rebase I mean merge the latest changes from master to remove any merge conflicts so that we can merge this PR. Thanks!

[alfiehopkin]

@benmccann ahh right! All done, thanks!

[benmccann]

The point looks too high to me in the screenshot in #6006 (comment). Is it possible to vertically center the point?

[alfiehopkin]

@benmccann I’ve already fixed the vertical positioning in the commit 2989223 - Fixed positioning of legend box

[benmccann]

Ok. Would it be possible to update the screenshot?

[alfiehopkin]

@benmccann updated :)

[benmccann]

Thanks for your patience on this one

[simonbrunel]

Thanks @alfiehd

[alfiehopkin]

@benmccann @simonbrunel @kurkle thanks for all of your input on this one. Really glad it's been merged haha. My first PR ever, and with a library that I use on a daily basis and have created many plugins for internal use. I'll get around to sharing those with the community soon also!