App::Link: the big merge

[fosselius]

If everyone is so sure about this, then I wonder why everyone was not already using asm3 builds before? Where are all the users? Where are all the projects? I would for sure not merge it like this.

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.

[realthunder]

Sure!

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.

Screenshot from 2019-08-17 14-24-03.png (107.17 KiB) Viewed 1140 times

[saso]

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.

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.

[triplus]

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.

[user1234]

Hello!

Finally, I can reproduce your problem.

I compiled the fix and all work with charm.

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

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 .....

Many many thanks for your work and fast fixes.

Greetings
user

[user1234]

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:

link_error.webm

(398.24 KiB) Downloaded 34 times

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)

Greetings
user

[bernd]

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

[wmayer]

I know that i have unusal settings. Because the preselection in the 3D view FreeCAD always calculates the coordinates of the cursor.

That is actually good because the SW must handle unusual settings correctly.

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.

Is the behaviour the same between (old) master and Link3?

[Jee-Bee]

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

Be careful what you're saying... Now you get a lot of difficult questions about assemblies and FEM

[openBrain]

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

A valuable explanation can be found at https://github.com/realthunder/FreeCAD_ ... i/Concepts