davidosterberg wrote: ↑Thu Jan 07, 2021 6:08 pm
abdullah wrote: ↑Thu Jan 07, 2021 4:03 pm
I tend to agree to hyarion in how I would approach this.
Does that mean this PR will not be merged? That is OK, if that is the case. But I would like to know that before putting more effort into it. I think this tool is useful as is in PD.
I do think that the BSplines and the text would be a bit different though (maybe not, my knowledge is shallow). For the text in sketcher approach, all the Part design tools have to see the text as a geometric object. It is all the tools in SketchObject that must not see the text. Perhaps there is a simple way to achieve this.
I do not get to decide whether a PR will not be merged. I am an equal, just have worked for FreeCAD longer. You do not need to look up to me. I am here to help where I can.
Most PD features either involve the transformation of a previous operation or are sketch based. Primitives are a notable exception, but they are not sketch based. The text feature you propose is neither (or a mixture of both, a third category if you wish).
I point out that the feature you propose could be implemented as a primitive, then it would fall under the category of the primitives (a text string primitive). It would obey support attachment as primitives do (if attached). In fact, it appears to me (I may be wrong) that the sketch is only used as a substitution for an attachment (to indicate an location/orientation of the underlying object). You rightly point out that construction lines are used as references in several PD features, but generally it deals with the transformation itself, rather than the location of the object. If you want to argue that the line defines a transformation in the text object, I would reply it is far fetched argument.
I am not convinced that this third category responds to a natural extension or new use case. Rather, shame on me if I am wrong, to the convenience of implementation.
Let's assume for a moment that after reading the above you became convinced that your feature should work as a primitive (i.e. without the Sketch). And I emphasise this is nothing but an assumption for the sake of the following argumentation (I fully respect if you disagree with this assumption). Then the only disadvantage I see is that, as it is the case with primitives in general, they are not 2D shapes and the remaining tools of PD can not be leveraged on them with the flexibility that can be attained with 2D shapes. This point was raised by hyarion.
My post was never meant to warn you it won't be merged, rather to give you my opinion. It may be merged it you want to pursue it.
Regarding alternatives, there are two ideas that pop-out of my mind (without having given them too much regard, to be honest):
1. Create the ability to incorporate 2D objects to PD, where the text is a 2D object. In a very bad implementation that only serves to illustrate the point a TextSketchObject is a class derived from the Sketcher::SketchObject, where the solver is nullified and you get a text at the origin (it may well be the parent class of the Sketcher Part::Part2DObject instead, not thought through).
2. Add the ability to include text in the sketcher.
2.1. I do not think PD works based directly on Part::Geometry, other that maybe FeatureHole. PD works with the profile (the shape of wires build from the Sketch, which is indeed based on Part::Geometry). Take a look at SketchObject::execute(), you will see that the shape is set there.
2.2. You could derive a class from Part::Geometry, Sketcher::TextGeometry or if you are planning for more features like this one, Sketcher::ArbitraryGeometry. Part::Geometry has a pure virtual function toShape() that you will need to implement returning the shape of whatever you decide to include inside. This will be called by Sketch.cpp to produce the profile.
Then, of course, you would need to teach it to draw as objects are drawn in ViewProviderSketch::draw(bool, bool) and define a solver implementation. Here it is where it is very similar to a B-Spline. You could, for example, draw your text along different geometries (along a line, an arc or a b-spline). This geometry (or the poles if a b-spline) would be internal geometry to your Sketcher::TextGeometry. This geometry is what the solver solves and uses to locate the object...
... now thinking... would it be possible to just associate a text/font/XXX via a GeometryExtension (Sketcher::TextGeometryExtension) to any existing geometry of the Sketcher without all of the above...
... it is getting late... let me think about it... maybe the latter becomes a third alternative...