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
Allow solid colored glyphs have a different colored outline #298
Conversation
@@ -55,6 +55,12 @@ type GlyphStyle struct { | |||
// Radius specifies the size of the glyph's radius. | |||
Radius vg.Length | |||
|
|||
// Width is set, LineColour is used to outline the glyph |
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.
How about using a LineStyle
here? Comment would be:
// LineStyle is the style of the glyph outline.
// If LineStyle.Width is zero no outline is drawn.
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.
Great suggestion, I would like that idea, except for the fact that LineStyle
also includes a Dashes
and a DashOffs
field—they would be effectively unused. I'm happy to switch the patch over to use LineStyle
if that is what people prefer.
PS: Yikes, I need to fix the wording of that comment as well.
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.
There's no reason not to allow dashed outlines for glyphs.
I'm not sure about this. I'm inclined to think the place for this kind of configuration is in the GlyphDrawer implementations rather than in a style. |
Shouldmt the object that holds the full color also hold the line/stroke color? Perhaps I misunderstand? Are you saying the fill color should go in the GlyphStyle object and the line/stroke color should go in the GlyphDrawer object? |
What I'm saying is that you could write an |
Aaah, ok so your suggesting we create either:
That I could also do, that would be more following the spirit of the existing code. Would that get the pull request approved If we go down that route, someone could argue that |
The argument could be made that there is an obvious redundancy if the glyphs are configurable. The issue is that they just work. Functions of similar names that return appropriately configured GlyphDrawers would probably be satisfactory though. All up, this is more complicated than it first looks. I'd like to wait until @eaburns has a chance to comment. |
In summary the choice is between
|
I haven't had a chance to look at the code yet, but from what I've read here, I prefer option 3. |
Great. In the morning I'll fgo ahead and create another patch that it implements option three. Do we want to merge CircleGlyph into RoundGlyph, or visa versa? (Same goes for square/box and Triangle/Pyramid) |
Any news on this? We are trying to clean up our PRs. It seems like a nice simple change, but still has some outstanding comments. Do you plan to address them? If not, we plan to close this soon. |
I am closing this, because we are cleaning up inactive pull requests. See https://groups.google.com/d/topic/gonum-dev/Dr8t8WdvB_4/discussion for more details. |
Here is an initial go at a patch that allows solid coloured Glyphs to have an outline.
A keen observer may note that an update to allow a
PyramidGlyph
to be solid coloured with an outline, is almost the same as if we had allowedTriangleGlyph
to have a fill. (ditto for Box/Square, and Circle,Round).There is probably a case for arguing that we don't need
PyramidGlyph
andTriangleGlyph
as they are both the same except with a different fill or stroke colour, but I don't want such arguments to hold up a useful patch :D Can we patch first and argue how to present the API later?Where in the past we may have done:
We can now do: