-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Draw bar group if there is text #3164
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Do not remove group when bar has empty area when there is text. The groups 'g.point' contains the path for bars, but also the corresponding text element. Now, the group is made if it should contain text, even when it will not contain a path.
* Fixes bar_attrs_relative test * Decides empty bar based on coordinates before fixpx
.attr('d', | ||
'M' + x0 + ',' + y0 + 'V' + y1 + 'H' + x1 + 'V' + y0 + 'Z') | ||
.call(Drawing.setClipUrl, plotinfo.layerClipId); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then we also need to remove the bar if it later disappears. Off your branch I can do:
Plotly.newPlot(gd,
[{type:'bar',y:[0,1,0,1],text:'hi',textposition:'outside',cliponaxis:false}],
{width: 400, height: 400})
Which looks great:
But then if I do:
Plotly.restyle(gd,'y',[[1,0,1,0]])
The newly-removed bars are still there (with their text moved to the right place):
Hmm. I think I would prefer using the "blank-path" style solution as described in #3115 (comment) |
@@ -9,7 +9,7 @@ | |||
"type":"bar" | |||
}, { | |||
"width":[0.4,0.6,0.8,1], | |||
"text":["Three",2,"inside text",0], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I think we need to figure out how to handle these cases. If I put values in where you put ""
- "zero"
here and "empty"
in the last trace - I get the following unfortunate situation:
I'm not sure why "zero" is showing up below where its bar would have stacked, seems like it should be above and it should push "4" inside the blue bar. "empty" also shows up below where its bar would be if that bar were positive... in an ideal world we might detect that its neighboring bars are negative - in this case only "outside text" to the right, but if it weren't the first bar, perhaps we would require the bar before to also be negative - we treat this as a "negative zero" and move the "empty" label down below the green -1? Anyway that's a pretty weird edge case, I wouldn't worry about it too much, if we could get it to work right with only a "positive zero" I'd be satisfied.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess that the "zero" and " empty" text is showing up near the empty red bars is the new expected behavior. However, textposition: 'auto'
is placing 'zero' below the empty bar and not pushing '4' inside. I'll look around and see if the blank-path solution solves this any better.
That would certainly make the logic easier, no need for a special case on removing a previously-visible bar. |
Closing due to lack of activity. I made a quick attempt at the blank path solution (more in: #3115 (comment)), and I faced the same problems described in #3164 (comment) where the Moving (back) the discussion to #3115 |
Adresses #3115.
The groups
g.point
contains the path for bars, but also the correspondingtext element. Now, the group is made if it should contain text, even
when it will not contain a path.