Alright... So you're saying that if I want to create a line (the most basic shape) in SFML (a library centered around GRAPHICS) I have to use another library or create the sf::LineShape class myself?
I'm not saying anything, just showing you alternatives to achieve what you want given SFML's status quo. I haven't implied that the lack of line shapes in SFML is a good thing. So, no need for that cynical tone
Uh, you have a line function returning a ConvexShape - why not recommending that one?
As stated in the documentation:
If you want a more flexible line implementation that can also be changed after creation, look at the thor::Arrow class and its Line style.
thor::Shapes::line() is for simple one-liners. It may be enough in many cases though.
then creating two other rectangles and rotating them at the right angle so they make an arrow. And then having to create two circles or something at the end of the rectangle so that it has smooth ends. Otherwise using a sf::RectangleShape to create this would be bordering on impossible.
[...]
This gets tedious and sf::LineShape is much quicker and easier.
Yes, but what you're talking about is no longer a line. Strictly mathematically speaking, lines don't even have a thickness, it's just a common feature for convenience. Above you're talking about "the most basic shape"; I don't think arrow tips are part of that.
The problem is that the features you're proposing are too broad to fit into the concept of
sf::Shape. Your class is not even a shape, it's multiple shapes (rectangle + 2 circles or triangles for arrow tips). In addition, it's not convex, a requirement for SFML shapes. What should
getPoint() and
getPointCount() return? Is it not totally unintuitive if a line has more than 2 points? Have you tried to implement texturing on those shapes? Furthermore, do lines have fill and outlines like shapes with actual area?
As you see, writing a line class is one thing, but integrating it well into the library is another. We have to solve the above-mentioned problems before
sf::LineShape can be considered. And if it ends up 99% like
sf::RectangleShape, we should rather think about adapting that class. Laurent mentioned this point before, by the way.