Assembly3 preview

[fosselius]

I have considered realthunders fork/branch to be the dev branch for 0.18 since before 0.17 was released Would love to see it merged with master. I totally agree that its time to "brick" FreeCAD again now that the "stable" 0.17 is out. I have fond memories of trying to figure out Part Design Next during early development..

Meanwhile in the github project:

Screenshot from 2018-05-21 22-42-32.png (104.49 KiB) Viewed 2201 times

[HarryGeier]

So I figure maybe the main developers are busy at the moment. But, yeah, I think I'll start a new thread and ask them directly, once I

Well, in a different thread i was reading that "the other Part Design developers" are not really active presently, except your with your fork, I think it might make sense to have a discussion thread started about the integration of your work into the master development. If there is no one else doing anything for this part of FreeCAD , it should make most sense that the few ACTIVE developers join their forces and get one approach to a landing...
Or, Part Design development should be freezed for .18 to get it released end of the year, whilst your fork keeps developing for 0.19 integration. This has 2 drawbacks.. the functionality comes later and the integeration might get more difficult. Still, afaik, the question seems to be that license thing ?

[realthunder]

Well, in a different thread i was reading that "the other Part Design developers" are not really active presently, except your with your fork, I think it might make sense to have a discussion thread started about the integration of your work into the master development. If there is no one else doing anything for this part of FreeCAD , it should make most sense that the few ACTIVE developers join their forces and get one approach to a landing...
Or, Part Design development should be freezed for .18 to get it released end of the year, whilst your fork keeps developing for 0.19 integration. This has 2 drawbacks.. the functionality comes later and the integeration might get more difficult. Still, afaik, the question seems to be that license thing ?

I will start a thread about merging early next month. I'll prepare some document regarding my Link implementation to better explain the motivation behind. There is no license issue regarding my work in the forked FC. SolveSpace part only exists as a independent Python extension, and is only used by asm3, which is an external python workbench itself.

[triplus]

Ideally Links effort would resolve the problem of loading geometry from multiple documents (documents opened or closed) in a seamless way. Not only for Assembly purposes but in general. That would be a strong selling point.

[realthunder]

Ideally Links effort would resolve the problem of loading geometry from multiple documents (documents opened or closed) in a seamless way. Not only for Assembly purposes but in general. That would be a strong selling point.

This feature is difficult to implement with the current FC document structure, especially if we want this to be a generic solution. Current FC document does not explicitly store object dependency information. It has to load all the objects first in order to obtain that information. We need to change the core of document saving (explicit dependency graph), and loading (object filtering). The changes may not be small, but they are most likely invisible to other part of FC, so I think I'll delay this after the merging discussion.

PS. for those who have used other CAD that have this capability (external link, partial loading, etc), can you please share how they look like, from a user perspective?

[HarryGeier]

The changes may not be small, but they are most likely invisible to other part of FC, so I think I'll delay this after the merging discussion.

i agree with that . Having done and managed many software projects in my IT life, i know that often projects are never going public , just because the customer does never stop adding features and allways delays release until next feature wish is implemented..This ends in a loop where one site usually stops it after getting bored. On the other side i know in our company we have quite a lot of software in daily use, that was never developed to 100%, but it´s USED and makes sense.

So, just give the users what is ready and make it mature . Then it´s time to continue with new efforts.

[chrisb]

That's what we call the "Salami Tactic": A salami in slices is delicious, but you can't chomp it all (there is only one possibility where you might get it in at once, but you sure won't have it there).

[triplus]

This feature is difficult to implement with the current FC document structure, especially if we want this to be a generic solution. Current FC document does not explicitly store object dependency information. It has to load all the objects first in order to obtain that information. We need to change the core of document saving (explicit dependency graph), and loading (object filtering). The changes may not be small, but they are most likely invisible to other part of FC, so I think I'll delay this after the merging discussion.

If i remember correctly you said Links add a bit of complexity and make it even harder to implement such functionality on top of everything. In my opinion best to figure this out in down stream branch and to mature things further? In addition i could have seen the whole Links effort bringing the mentioned functionality to FreeCAD. But it could be in the end your Links effort isn't about that at all. And therefore that will be a part of another future effort from your or someone else's side.

P.S. Anyway that is just my opinion and for sure gather more opinions and feedback from others to make a good choice after.

[realthunder]

If i remember correctly you said Links add a bit of complexity and make it even harder to implement such functionality on top of everything. In my opinion best to figure this out in down stream branch and to mature things further? In addition i could have seen the whole Links effort bringing the mentioned functionality to FreeCAD. But it could be in the end your Links effort isn't about that at all. And therefore that will be a part of another future effort from your or someone else's side.

P.S. Anyway that is just my opinion and for sure gather more opinions and feedback from others to make a good choice after.

And that is why I said I'll write some document about the Link before starting the merging discussion, which is going to be long I guess.

[triplus]

And what to expect will happen once somebody decides to implement the full multi document geometry management as discussed. Will Links effort in its current form (features like XLink with partial multi document geometry management) need to be rethinked or do you imagine should be easily extended?