Relevance of "Feature is not in a part" error message

[ickby]

You guys are perfectly correct that most of the stuff is work in progress, and that it is in a strange state now. I think the general ideas, on which the code is based, are still valid, but if the implementation is correct is mostly driven by how to go on with assemblies. And also some stuff I implemented may be not be the whole truth

I still think having a single freecad entity to define a local CS, or container like deepsoic calls it, is the way to go. So the extensions as they are now imho seem good. Just the way how they interact with the user must be fleshed out and revised (or better: finished).

This is mostly a ideologic discussion as many people have different ideas on how it should work and how it should be implemented... that makes it super hard to work on it. As you headed already in the thread deepsoic and myself have different conceptions, and even if I'm pretty sure both would work in the end, working together without settling the discussion first is super hard.

So either someone writes down how it should be and alignment is created by discussion, or it will be settled by someone finishing the implementation that is just used afterwards.

[abdullah]

Especially as you have expressed some plans to work on PartDesign workbench in the future.

I think you misunderstood me, or I expressed myself very poorly. I meant I was going to fix bugs from the tracker until before end-of-year/release. Then life got in the middle.

I have my place in the Sketcher, and it is probably large enough shoes for me.

Sorry if I disappointed you

I have just seen ickby's post while submitting.

Ickby had an overall idea and the part that got implemented, got merged. DeepSOIC did an effort with ActiveContainer branch and it got "lost". Now there is also realthunder's assembly branch.

While the last two lines of ickby's post will always hold, there is a huge risk of working on something that will get lost and never used (as triplus also points out). IMO settling the discussion is the only reasonable way forward. Also because it touches different functionalities, workbenches and how they should interact. But in any case, as I was saying too big shoes for me...

[saso]

Ok, this is a nice start

[chrisb]

I still think having a single freecad entity to define a local CS, or container like deepsoic calls it, is the way to go. So the extensions as they are now imho seem good. Just the way how they interact with the user must be fleshed out and revised (or better: finished).

I full agree with this. To me this is a sound concept, and with some extensions Werner made it is for me already in its current state very well usable.

[NormandC]

While this discussion is interesting, it does not answer the topic at hand, which is: why is this error message even occurring? It is confusing, and wrong. IMO it should be removed, or commented out.

[nodavahoro]

Especially as you have expressed some plans to work on PartDesign workbench in the future.

I think you misunderstood me, or I expressed myself very poorly. I meant I was going to fix bugs from the tracker until before end-of-year/release. Then life got in the middle.

I have my place in the Sketcher, and it is probably large enough shoes for me.

Sorry if I disappointed you

I have just seen ickby's post while submitting.

Ickby had an overall idea and the part that got implemented, got merged. DeepSOIC did an effort with ActiveContainer branch and it got "lost". Now there is also realthunder's assembly branch.

While the last two lines of ickby's post will always hold, there is a huge risk of working on something that will get lost and never used (as triplus also points out). IMO settling the discussion is the only ascensori Piacenza. Also because it touches different functionalities, workbenches and how they should interact. But in any case, as I was saying too big shoes for me...

Dear abdullah, a huge risk of working on something that will be lost and never used (as also emphasized by Triplus) does not seem to me to be done. Always hoping that the workers will make it grow but not as the IMO that establishes the discussion is the only reasonable way to follow. Also because it touches on different functionalities, workbenches and how they should interact.

[abdullah]

Dear abdullah, a huge risk of working on something that will be lost and never used (as also emphasized by Triplus) does not seem to me to be done. Always hoping that the workers will make it grow but not as the IMO that establishes the discussion is the only reasonable way to follow. Also because it touches on different functionalities, workbenches and how they should interact.

I am at lost to understand this fully.

Discussion is not the only way to settle anything. I still think that it is the only reasonable one. The reason is that it does not lead to segmentation, which is a suboptimal solution. PD is possibly the most important WB of FreeCAD from a user perspective and it has no active leading developer. We ought to reflect on how we arrived there. Maybe with a timely discussion we could have arrived to a different reality (worthless today unless we learn something from it). Maybe there is something we can do today to arrive to a better future reality.

[wmayer]

While this discussion is interesting, it does not answer the topic at hand, which is: why is this error message even occurring? It is confusing, and wrong. IMO it should be removed, or commented out.

Today I had a look at this function again. When looking at the steps to reproduce this odd behaviour then a user may think it's the sketch that is assumed to be inside a Part container. But according to the source code it is not, it's the Body object that is assumed to be in the Part. And this is not clearly told to the user so that he does the totally wrong things in the hope to fix it.

The assumption may have been introduced with ickby's restriction that objects cannot be mixed from different Part containers. But since for now we have weaken this restriction there is no need to pop-up the error message. Instead it works to directly invoke the Reference dialog and create a copy inside the Body so that the pad, pocket, ... whatsoever succeeds.

If the sketch is in a different Part or no Part at all the warning "Links go out of the allowed scope" in the Output window is shown. If Body and Sketch are inside the same Part container no warning is shown.
git commit 1a8d3a703

[wmayer]

IIRC originally, ickby was enforcing the out of scope rule. I believe wmayer made it more lax before the v0.17 release, or it would have been very, very painful for many users used to mix Part and PartDesign.

Indeed. It appeared that more and more functions outside of PD suffered from this hard restriction and refused to work. So, instead of raising a (C++) exception that would stop all the affected functions I replaced it with a warning. This way we gain some more time until we decide/know how to handle all this. And since we don't have an Assembly module at the moment it's safe to weaken this restriction.

Also, after all I dislike the idea to implement a hard restriction due to some difficulties that affects basically all other modules, too. We should at least try to add this restriction to the Assembly module only (in case we can't find a proper solution or a workaround).

[NormandC]

git commit 1a8d3a703

Thanks!