Idea: fork avoidance system [abandoned]

About the development of the Part Design module/workbench. PLEASE DO NOT POST HELP REQUESTS HERE!
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
User avatar
bejant
Veteran
Posts: 6075
Joined: Thu Jul 11, 2013 3:06 pm

Re: Idea: fork avoidance system [test request]

Post by bejant »

DeepSOIC wrote:I think it's time to ask for testing :mrgreen: .
I just tried to compile and got the following error:

Code: Select all

make
[  0%] Generating ../../../bin/pivy/sogui.py
[  0%] Generating ../../../bin/pivy/__init__.py
[  0%] Generating ../../../bin/pivy/coin.py
Scanning dependencies of target coin
[  1%] Building CXX object src/3rdParty/Pivy-0.5/CMakeFiles/coin.dir/coin_wrap.cpp.o
In file included from /home/myusername/Downloads/FreeCADGit/20150429/FreeCAD-ellipse-PartDesign-ForkAvoidance/src/3rdParty/Pivy-0.5/coin_header_includes.h:145:0,
                 from /home/myusername/Downloads/FreeCADGit/20150429/FreeCAD-ellipse-PartDesign-ForkAvoidance/src/3rdParty/Pivy-0.5/coin_wrap.cpp:3930:
/usr/include/Inventor/elements/SoGLTexture3EnabledElement.h:36:2: error: #error Deprecated: use SoMultiTextureEnabledElement instead
 #error Deprecated: use SoMultiTextureEnabledElement instead
  ^
In file included from /home/myusername/Downloads/FreeCADGit/20150429/FreeCAD-ellipse-PartDesign-ForkAvoidance/src/3rdParty/Pivy-0.5/coin_header_includes.h:190:0,
                 from /home/myusername/Downloads/FreeCADGit/20150429/FreeCAD-ellipse-PartDesign-ForkAvoidance/src/3rdParty/Pivy-0.5/coin_wrap.cpp:3930:
/usr/include/Inventor/elements/SoTexture3EnabledElement.h:36:2: error: #error Deprecated: use SoMultiTextureEnabledElement instead
 #error Deprecated: use SoMultiTextureEnabledElement instead
  ^
In file included from /home/myusername/Downloads/FreeCADGit/20150429/FreeCAD-ellipse-PartDesign-ForkAvoidance/src/3rdParty/Pivy-0.5/coin_wrap.cpp:3930:0:
/home/myusername/Downloads/FreeCADGit/20150429/FreeCAD-ellipse-PartDesign-ForkAvoidance/src/3rdParty/Pivy-0.5/coin_header_includes.h:668:40: fatal error: Inventor/scxml/ScXMLInvoke.h: No such file or directory
 #include <Inventor/scxml/ScXMLInvoke.h>
                                        ^
compilation terminated.
make[2]: *** [src/3rdParty/Pivy-0.5/CMakeFiles/coin.dir/coin_wrap.cpp.o] Error 1
make[1]: *** [src/3rdParty/Pivy-0.5/CMakeFiles/coin.dir/all] Error 2
make: *** [all] Error 2
DeepSOIC wrote:* decision on default behavior
My vote for default is map sketch to newest feature (after all this is for "fork avoidance"!). When users feel the need to do so, they can change their Preference.
triplus
Veteran
Posts: 9471
Joined: Mon Dec 12, 2011 4:45 pm

Re: Idea: fork avoidance system [test request]

Post by triplus »

My vote for default is map sketch to newest feature (after all this is for "fork avoidance"!).
Sketch won't be re-mapped to latest feature. Only the operation itself will be made on Latest Feature instead of on earlier feature the sketch is mapped to.

Anyway i had a thought and will ask. How are cyclic dependencies handled with Support Override property? I will leave the decision on the technical side to be discussed by developers and will test and use proposed solution if it makes it in the master. If there are no big technical downsides i welcome this addition.

In general i would still like to have possibility to create forks if needed and do see use cases where Support Override could be used. I simply don't know if on the long run if it makes sense to have tools in PartDesign that enable multi-part operations. I don't have strong opinion on this i only hope that it will not introduce troubles in the future. As i understand it more appropriate place for multi-part operations is Part WB.

In addition to proposals i made about terminology i would propose additional one. Support Override property should simply be named Support.

About UX. I hope pop-ups won't be implemented and user will instead use Support property to control on what Feature should PartDesign operation be made on. One general setting about default behaviour in preferences should do the job just fine. For everything else there is Property Editor. Regardless of the outcome it's nice to see the possibilities to change the way on how we teach FreeCAD should be used exist and are explored.

Cheers!
User avatar
NormandC
Veteran
Posts: 18587
Joined: Sat Feb 06, 2010 9:52 pm
Location: Québec, Canada

Re: Idea: fork avoidance system [test request]

Post by NormandC »

triplus wrote:I simply don't know if on the long run if it makes sense to have tools in PartDesign that enable multi-part operations. I don't have strong opinion on this i only hope that it will not introduce troubles in the future. As i understand it more appropriate place for multi-part operations is Part WB.
From the little time I spent testing the jriegel/dev-assembly-old branch, A part can have multiple Body containers. So in this branch it is quite possible to work with multi-parts in the Part Design WB. In fact, the Part Boolean icons were added to the Part Design toolbar. You can see an example of such workflow in the PartDesign Bearingholder Tutorial II.

But considering the current discussion in the Assembly forum, I don't know where the project will go, if this will be salvaged...
triplus
Veteran
Posts: 9471
Joined: Mon Dec 12, 2011 4:45 pm

Re: Idea: fork avoidance system [test request]

Post by triplus »

I see. Conceptual difference between PartDesign and Part WB will fade anyway. As devs are a bit hasty lately to work on Assembly WB strategy to merge Assembly WB should probably be made and the devs can start working on it.

But it will probably be hard work and a bit of pressure therefore make realistic plans how the merge should happen. I am not worried all that much about braking stuff. As for example simple drawings i made in FreeCAD 0.14 doesn't work any more in current Master. What the worry should be about is how long will it take to make the merge to behave good.

Anyway this is out of scope regarding this thread. Maybe small suggestion to DeepSOIC. Support and Fork Property in Property View (True/False) instead of pop-ups and general setting in Preferences Always apply operation to the last Part Feature (True/False) seems reasonable to me. But will work with whatever gets merged just fine.

Cheers.
User avatar
DeepSOIC
Veteran
Posts: 7896
Joined: Fri Aug 29, 2014 12:45 am
Location: used to be Saint-Petersburg, Russia

Re: Idea: fork avoidance system [test request]

Post by DeepSOIC »

After taking a look into new partdesign in assembly, I saw that this fork avoidance system is essentially already there. So I abandon this branch.
triplus
Veteran
Posts: 9471
Joined: Mon Dec 12, 2011 4:45 pm

Re: Idea: fork avoidance system [abandoned]

Post by triplus »

- Good thing developers became a bit hasty as we see this already leads to less duplicate work!
- About the other part and feature like "Support Override" already implemented? I didn't test it but i have my doubts about that. ;)
User avatar
DeepSOIC
Veteran
Posts: 7896
Joined: Fri Aug 29, 2014 12:45 am
Location: used to be Saint-Petersburg, Russia

Re: Idea: fork avoidance system [abandoned]

Post by DeepSOIC »

triplus wrote:"Support Override" already implemented?
Yes. And not "override", it doesn't care of sketch support anymore.
triplus
Veteran
Posts: 9471
Joined: Mon Dec 12, 2011 4:45 pm

Re: Idea: fork avoidance system [abandoned]

Post by triplus »

- Therefore operation is always applied to last feature?
- External geometry tool takes geometry from where?

Anyway no point in going into to much details. Will test when ready and hopefully devs know what they are doing. :D

P.S. If not we will just have to cope with it and work around it as we already do some times. Now where is that macro for example, that would temporarily insert cyclic dependency to stop recomputes, when you need one!
User avatar
DeepSOIC
Veteran
Posts: 7896
Joined: Fri Aug 29, 2014 12:45 am
Location: used to be Saint-Petersburg, Russia

Re: Idea: fork avoidance system [abandoned]

Post by DeepSOIC »

triplus wrote:- Therefore operation is always applied to last feature?
Yes, but one can change the "last" feature via a context menu in tree view. Thumbs up, I like it.
triplus wrote: External geometry tool takes geometry from where?
from anything that is part of Part container (any state of history, datum lines and points, sketches, another Bodies of the same Part). That is, almost completely unlimited.
User avatar
DeepSOIC
Veteran
Posts: 7896
Joined: Fri Aug 29, 2014 12:45 am
Location: used to be Saint-Petersburg, Russia

Re: Idea: fork avoidance system [abandoned]

Post by DeepSOIC »

And it has the same bug that my unlimited branch had, that it's impossible to link in two Edge1's from different objects :mrgreen: going to cherry-pick some stuff :mrgreen:
Post Reply