there are lots of users using the asm3 branch, it have been tested, this however cant be compared as it is a cherrypicked subset that is merged into master. it ought to have more issues then in the link3/asm3 branch. and you know very well that the asm3 users are hanging out in the user and assembly part of the forum.
App::Link: the big merge
Forum rules
Be nice to others! Read the FreeCAD code of conduct!
Be nice to others! Read the FreeCAD code of conduct!
Re: App::Link: the big merge
-
- Veteran
- Posts: 2190
- Joined: Tue Jan 03, 2017 10:55 am
Re: App::Link: the big merge
Finally, I can reproduce your problem. It only happens with some unusual settings. You disabled preselection in 3D view, but still enabled preselection in treeview. This is now fixed. The renaming problem is because you enabled both TreeView and ComboView, so there are actually two tree views conflicting each other. It is fixed also. And so is the Draft path link array. I also fixed property ordering problem, since nobody has any opinion about it yet. It can be easily undo if there is any reason against it.
Re: App::Link: the big merge
users that actually understand how this should work and how the concepts behind it should work and users that actually do meaningful projects with it and not users that after two years of clicking around are only able to say "it looks interesting, but i don't really understand all of this and i also don't really understand how a proper assembly should work...". there are also "lots" of users that use part design and asm2+ and are "happy" with it and at the same time complain why some things are not working, while refusing to accept that some of the concepts behind them make absolutely no sense. stop fulling yourself and everyone else by "hoping" that this is now the right solution, engineering does not work on hopes and prayers.fosselius wrote: ↑Sat Aug 17, 2019 4:59 am there are lots of users using the asm3 branch, it have been tested, this however cant be compared as it is a cherrypicked subset that is merged into master. it ought to have more issues then in the link3/asm3 branch. and you know very well that the asm3 users are hanging out in the user and assembly part of the forum.
Re: App::Link: the big merge
For assembly projects the current recommendation is to use FreeCAD and A2plus module. Therefore saying there must be something wrong with App::Link, as people aren't using Assembly 3 for their production work, that is in my opinion not rationale thinking. People are being rational about it and use FreeCAD and A2plus module for now in such projects, as recommended. In addition App::Link functionality is more of a multi-feature and multi-document management piece of functionality. Therefore one use case is using it for assembly purposes, but this is still far from having an actual assembly module capability.
Over the years, from the App::Link conception, a plethora of tech-savvy users did actually get involved in discussions, as a result App::Link effort matured substantially in areas like partial loading to name one. What did lack a bit was not tech-savvy users getting involved, but tech-savvy developers getting involved. If that would happen, maybe more emphasize would be put on shape/shapeless nature of the Link feature and things like that. Topics around selection changes and working with Link feature "geometry" would likely be talked more often too. It was advised to get involved on multiple occasions, but that didn't happen. This will therefore happen after App::Link gets upstreamed and that is why in my opinion there should be no more Assembly 3 related functionality upstreamed in FreeCAD 0.19 development cycle. As tech-savvy developers will now be confronted with App::Link and some feedback will likely still need to get acknowledged.
As for "a leap of faith", that comment went in the direction, we can't expect Werner to now grasp everything and to be responsible for everything in a months time. As post merge development is still expected and that is perfectly normal. We did the same with PartDewsign NEXT and only now, with App::Link introduction, things are starting to evolve again. Like some restrictions and design decisions getting revised and things like that. If we wouldn't do PartDesign NEXT then, we should have waited until this App::Link PR, or as some suggest to wait longer? That doesn't make much sense in my opinion.
For App::Link i feel that high enough level of consensus and maturing was achieved to proceed with upstreaming. As for features such as dynamic properties. I wasn't involved in discussions and don't know how mature that functionality is. Being able to add dynamic properties to C++ features, and not only to Python based ones, is a guess a good thing.
Over the years, from the App::Link conception, a plethora of tech-savvy users did actually get involved in discussions, as a result App::Link effort matured substantially in areas like partial loading to name one. What did lack a bit was not tech-savvy users getting involved, but tech-savvy developers getting involved. If that would happen, maybe more emphasize would be put on shape/shapeless nature of the Link feature and things like that. Topics around selection changes and working with Link feature "geometry" would likely be talked more often too. It was advised to get involved on multiple occasions, but that didn't happen. This will therefore happen after App::Link gets upstreamed and that is why in my opinion there should be no more Assembly 3 related functionality upstreamed in FreeCAD 0.19 development cycle. As tech-savvy developers will now be confronted with App::Link and some feedback will likely still need to get acknowledged.
As for "a leap of faith", that comment went in the direction, we can't expect Werner to now grasp everything and to be responsible for everything in a months time. As post merge development is still expected and that is perfectly normal. We did the same with PartDewsign NEXT and only now, with App::Link introduction, things are starting to evolve again. Like some restrictions and design decisions getting revised and things like that. If we wouldn't do PartDesign NEXT then, we should have waited until this App::Link PR, or as some suggest to wait longer? That doesn't make much sense in my opinion.
For App::Link i feel that high enough level of consensus and maturing was achieved to proceed with upstreaming. As for features such as dynamic properties. I wasn't involved in discussions and don't know how mature that functionality is. Being able to add dynamic properties to C++ features, and not only to Python based ones, is a guess a good thing.
Re: App::Link: the big merge
Hello!
Many many thanks for your work and fast fixes.
Greetings
user
I compiled the fix and all work with charm.
I know that i have unusal settings. Because the preselection in the 3D view FreeCAD always calculates the coordinates of the cursor. And on (larger) assemblies the CPU struggles with that. When i switch off the preselection, FreeCAD runs on my laptop with larger assemblies (100 parts) quite fluently. And i always want to see the treeview and i need the task tab. And the task tab is only in the combo tab (out of the box) included. So i have two treeviews in the session, but use only one. The "good" thing of the unusual settings seems that are good for tests .....realthunder wrote: ↑Sat Aug 17, 2019 6:33 am It only happens with some unusual settings. You disabled preselection in 3D view, but still enabled preselection in treeview
...
The renaming problem is because you enabled both TreeView and ComboView
Many many thanks for your work and fast fixes.
Greetings
user
Re: App::Link: the big merge
Hello!
Found another bug. When you link between two files, like part and assembly, and what to modify the part, an error raises.
Screencast is here:
Log:
Version (now in master):
Greetings
user
Found another bug. When you link between two files, like part and assembly, and what to modify the part, an error raises.
Screencast is here:
Log:
Code: Select all
Traceback (most recent call last):
File "<string>", line 4, in <module>
<class 'TypeError'>: get_all_dependent() takes 2 positional arguments but 3 were given
ViewProviderSketch::setEdit: visibility automation failed with an error:
Version (now in master):
Code: Select all
OS: Debian GNU/Linux 10 (buster) (X-Cinnamon/lightdm-xsession)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.17798 (Git)
Build type: Release
Branch: master
Hash: 7e60631239109c632a8f6cca83f6e7e5502e43a1
Python version: 3.7.3
Qt version: 5.11.3
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: English/UnitedStates (en_US)
user
Re: App::Link: the big merge
finally it is merged Compiles and runs on my Debian Buster, unit tests run fine.
I have no problems so far. But I have used FC only for an hour. Ahh and I did not do something related to this Link. I even do not know what it is about
I have no problems so far. But I have used FC only for an hour. Ahh and I did not do something related to this Link. I even do not know what it is about
Re: App::Link: the big merge
That is actually good because the SW must handle unusual settings correctly.
Is the behaviour the same between (old) master and Link3?And on (larger) assemblies the CPU struggles with that. When i switch off the preselection, FreeCAD runs on my laptop with larger assemblies (100 parts) quite fluently.
Re: App::Link: the big merge
Be careful what you're saying... Now you get a lot of difficult questions about assemblies and FEM
Re: App::Link: the big merge
A valuable explanation can be found at https://github.com/realthunder/FreeCAD_ ... i/Concepts