davidosterberg wrote: ↑Thu Jan 07, 2021 10:20 pm
abdullah wrote: ↑Thu Jan 07, 2021 8:05 pm
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.
We are equals as men, but due to merit your opinion holds stronger than mine here. Nothing wrong with that.
It should not be that way. I think something is wrong with that. For me the opinion/idea has the merit rather than the person proposing it. Let's debunk it with an example: I propose a new feature that requires a web camera for FreeCAD pointing to the user, and if he or she stops blinking every 5 seconds, FreeCAD will freeze. I would understand that you are of the opinion that that is nuts and a nonsense (although it may lead to better eye health). Do you honestly thing that my such opinion would hold stronger?... maybe for an add-on
We should stop judging people just because of what they have done in the past. There must be merit in the ideas. There must be weight in the arguments. One should be critical of its own ideas (and it is something I have seen you doing to your own ideas, which I find great). It is not easy to defend one's own ideas and at the same time be critical of them, as when one critisises its own, some regard them worthless without evaluation. Nevertheless, to less philosophical matters...
davidosterberg wrote: ↑Thu Jan 07, 2021 10:20 pm
abdullah wrote: ↑Thu Jan 07, 2021 8:05 pm
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.
Why far fetched? It is exacly what it is a the construction line translates into a rotation and a translation, and the length will be used to pre-select a font size. All the information in the sketch is used, 1-1 mapping.
My argument is not whether it serves its purpose. Rather whether it is appropriate. I concede that all the information is used and you have demonstrated it works.
One could modify the pad feature so that it takes a second sketch with a construction line showing the direction of padding and length instead of selecting this information from the feature task list. This is one example that purport to show that one sketch for just one line may not be the most appropriate idea. I would say that, if implemented as other tools are, you would have a drop box with some directions relating to planes or axes and some external reference which could be a datum line.
davidosterberg wrote: ↑Thu Jan 07, 2021 10:20 pm
abdullah wrote: ↑Thu Jan 07, 2021 8:05 pm
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.
The principle of using the sketch as a transformation is already used by the Hole feature. It is not a new category in PD.
I have never took the time to explore this feature, so I may be substantially off here. If understood well, a sketch is intended to support several holes (several transformations). While not consistent with the rest of the tools, my guess is that this support for a plurality of transformations better justifies the use of a Sketch as base for the feature.
davidosterberg wrote: ↑Thu Jan 07, 2021 10:20 pm
abdullah wrote: ↑Thu Jan 07, 2021 8:05 pm
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.
If you read further up in the thread, you will see that I initially argued for a sketch based solution. Almost identical to Hyarion's suggestion. It is therefore weird to sit on this side of the argument,
What was brought up by @chrisb (as I understood him) was that Text was not a natural extension of Sketcher. How ironic that this is now the argument used against having Text in PD
. None the less I agree to the benefits of having text in sketcher. I would welcome a Text tool in sketcher when that becomes available (I might even work on it). But why does it exclude Text in PD, when the feature is so close to be finished? Of course it has to be maintained, but I don't see that as a large task, in comparison to having a user friendly tool now.
Well, maybe it is not. You considered an initial idea (sketch base solution). You evaluated it and did a cost-benefit analysis. You reached an outcome (better go feature). You received feedback. You put forward the arguments used in your cost-benefit analysis. You reevaluate your position with the further feedback. It looks to me pretty much what a very reasonable person would do. For me it holds way much more intrinsic value that shouting out I am right (which thankfully is not your style).
Chrisb has a very good knowledge of what a CAD software should be and should do. He is invaluable in developing a feature... unfollowing my own advise I do look up to Chrisb
Chrisb's comment may be motivated by not finding an appropriate integration between the text tool and rest of the sketcher. Sometimes it is about finding the right integration. Something that seems inconsistent may become cool if a good integration is found.
To the latter question. You are right to point out that a Sketcher text tool does not technically exclude text in PD. As much as a cube primitive (box primitive) does not exclude a padded square/rectangle. But better not open that can of worms, as there are some users that regret the day primitives where added to PartDesign. I do not see a great code maintenance effort associated to it. If I understand other commenters, the question is rather how many tools should we end up having and whether we would consider the PD obsolete if the Sketch based on existed (or not). If (and only if) we want one tool not to confuse the user and we want the PD one obsolete when the Sketcher one appears, then we might have problem.
While I do understand the preference to have a tool "now" (and certainly it is not difficult to salivate with your screenshot for those who ever wanted to put a text in PartDesign and went the Draft-Part-PartDesign route, me included), it may make sense to make a small break to re-evaluate alternatives.
davidosterberg wrote: ↑Thu Jan 07, 2021 10:20 pm
abdullah wrote: ↑Thu Jan 07, 2021 8:05 pm
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).
Initial reaction is that this would be a bigger deviation from current PD. That would be something new.
Currently, my favourite option for text is "option 3" which I am still developing in my head. But I think it is worth pursuing this argument about "option 1".
Almost everytime a general idea is introduced is a ground-shaking idea because flexibility rarely comes without substantial change. I tend to look into the flexibility that a new idea can afford us. Then, the idea can be evaluated fairly with its alternatives and may win or not.
davidosterberg wrote: ↑Thu Jan 07, 2021 10:20 pm
abdullah wrote: ↑Thu Jan 07, 2021 8:05 pm
2. Add the ability to include text in the sketcher.
Yes, why not. As long as it can be done without adding a new switch case to every member of SketchObject.
Thanks for the hints. I will have a look when time allows.
I will try to think/produce a framework within a couple of days (I won't implement the whole feature), but the presence of this framework may help you sway your decision whether you want to pursue a pure PD solution, or you want to implement it sketcher based based on the new framework.