Assembly3 preview

[realthunder]

Are you doing any architectural changes to the Link implementation?

i guess it has become a bit more "modular" as you have isolated the functionality from all your other code.

I didn't really changed much, just split the things that are Link related, and compress 1K+ commits into just 50 or so. I have logically grouped them with detail comments. The document in my wiki is still relavant, and I did refer to wiki for more details in the comment of the commits.

(the basic Link functionality I would personally like to see in 0.19 but it could probably need some more review... do we really need link groups?)
10. Link

LinkGroup is just a use case of the Link extension, which contains special logic to deal with group, because it must support linking to a group object.

(this should probably wait)
11. Asm3
12. enhanced expression engine

Yes they are left out. Another big thing left out is the topo naming. If the Link can be merged in time, I'll follow it with the topo naming PR, and hopefully get it into 0.19 as well.

[Zolko]

do we really need link groups?

LinkGroup is just a use case of the Link extension, which contains special logic to deal with group, because it must support linking to a group object.

what is the use-case for linking to a group object ? Would it simplify things if this went away ?

Another big thing left out is the topo naming. If the Link can be merged in time, I'll follow it with the topo naming PR, and hopefully get it into 0.19 as well.

I could imagine that the toponaming should be first, even before App::Link. As well as your improvements for STEP import/export. This might make for a "fast" 0.19 with your improvements, and would allow 0.20 to contain App::Link. From a "political" perspective this could be preferable, rather than merging for 0.19 all the App::Link stuff and its 50 000 lines, to avoid the fear of re-creating the PartDesign fiasco.

So my proposal would rather be:

1) make PR for topo-naming
2) make PR for STEP import/export
3) make PR for various other improvements you made
4) go for 0.19, which could drop Python2 and QT4 support
5) target PR for App::Link with 0.20 goal, leaving more time for review

[realthunder]

LinkGroup is just a use case of the Link extension, which contains special logic to deal with group, because it must support linking to a group object.

what is the use-case for linking to a group object ? Would it simplify things if this went away ?

For example, adding a sub assembly (which is a group) through a link. In fact, I consider linking to a group the fundamental requirement of assembling. Both the Link object and the group object need to be aware of each other in order for them to coexist in harmony, hence I put the logic together, with some additional code to support legacy groups.

I could imagine that the toponaming should be first, even before App::Link. As well as your improvements for STEP import/export. This might make for a "fast" 0.19 with your improvements, and would allow 0.20 to contain App::Link. From a "political" perspective this could be preferable, rather than merging for 0.19 all the App::Link stuff and its 50 000 lines, to avoid the fear of re-creating the PartDesign fiasco.

If you are worried about PartDesign situation, then App::Link should go first. Because I design it with backward compatible in mind. If you do not use anything Link related, then everything should just work the same, which is kind of easy to verify. Topo naming is very different, it actually modifies almost all the geometry modeling code. I did try my best to conform to the old behavior, but that's a lot more difficult to verify.

BTW, STEP import/export is included, since it mostly relies on the Link(Group) functionality. Besides, I have left the original importer/exporter untouched, and user can choose which one to use.

[Zolko]

I could imagine that the toponaming should be first, even before App::Link.

Topo naming is very different, it actually modifies almost all the geometry modeling code.

that's why you should include it first: else, people will start to use App::Link, which will be a new way of using FreeCAD and therefore will break some of their habbits, and then you will introduce the new toponaming which will break again all their new models that they have been making with App::Link. You will break the data twice.

If you introduce TopoNaming first, people will instantly see improvement (stability) in their new models, including probably in Asm2+, and when you then introduce App::Link they will se additional functionality that doesn't break their new models and their old models. You will break the data only once. And that breakages is for the good of the people because TopoNaming is a known and abhorrent problem in FreeCAD.

[saso]

Interesting isn't it, why I picked exactly on the link groups...

[realthunder]

that's why you should include it first: else, people will start to use App::Link, which will be a new way of using FreeCAD and therefore will break some of their habbits, and then you will introduce the new toponaming which will break again all their new models that they have been making with App::Link. You will break the data twice.

If you introduce TopoNaming first, people will instantly see improvement (stability) in their new models, including probably in Asm2+, and when you then introduce App::Link they will se additional functionality that doesn't break their new models and their old models. You will break the data only once. And that breakages is for the good of the people because TopoNaming is a known and abhorrent problem in FreeCAD.

You are comparing the the worst possible case of introducing Link first to the best possible case of introducing topo naming first. That's not fair. The truth is, as shown in my branch right now, you aren't going to break all your models most of the time. There is one known case of model breakage when using topo naming, and that is caused by incompatible OCC versions, and it affects upstream FC just the same. The problem is more exposed only because my topo naming requires a complete recompute when loading older model, nothing to do with Link. The problem will show up the same in upstream if you do a complete recompute.

On the other hand, there are special code inside topo naming algorithm (especially for history back tracing and coloring) to deal specifically for external linked object. It will be more difficult to rip out that part of code than the other way round, because I did develop Link first.

If you are worried about user misusing Link, or more specifically, the LinkGroup (like sosa here seem to be), I don't think that has anything to do with introducing topo naming first or not. I obviously prefer LinkGroup over App::Part, but if it really is more confusing for normal user, we can make it less accessible for them, like not showing the action in the menu by default.

[Zolko]

There is one known case of model breakage when using topo naming, and that is caused by incompatible OCC versions, and it affects upstream FC just the same. The problem is more exposed only because my topo naming requires a complete recompute when loading older model, nothing to do with Link. The problem will show up the same in upstream if you do a complete recompute.

yes, I know, and that's the point. But anyway you know better than me, so you decide.

I obviously prefer LinkGroup over App::Part

Huh ? You thought about LinkGroup as a container for parts, as replacement for App::Part ? That's going to be an uphill battle IMHO.

[saso]

Huh ? You thought about LinkGroup as a container for parts, as replacement for App::Part ? That's going to be an uphill battle IMHO.

Yes and this is how it was designed from the beginning, support for Part actually came later and this is exactly my point. I don't actually have much of a problem with the link group functionality as "per se", but more with the fact how the users will use this, we already have several different methods on how users are creating their "assemblies" and this is not fixing or improving some of the needed functionality of the Part but is adding another way of how to model.

If we would go and work together on a large project we could each create possible great individual components but it would all be useless because there would be no head an tail to it. And in my post about the recommended steps I have not recommended to include realthunders STEP improvements because they are not improvements to the existing implementation but a totally different implementation based on the Links. And A2+ folks are also creating their own... If you don't see how crazy this is I really don't have anything to argue about.

And it is actually the users that are continuously asking from the developers new features instead of fixing and improving the existing ones first. If we would be building a house, everyone is focused on the big oled tv, design furniture and cool lighting (and it is fine, I understand users want that eventually) but it is crazy to work on this when you don't yet have all of your foundations, slabs, roofs and main walls finished... And it is users that are asking for all of the Link/Asm3 to get merged in when they don't really understand what it actually is.

[realthunder]

Huh ? You thought about LinkGroup as a container for parts, as replacement for App::Part ? That's going to be an uphill battle IMHO.

Well, I kind of added LinkGroup after the battle, actually. I proposed changes to App::Part, but ickby won't consider it, so I created a new one. App::Part has a restriction that one object can only be in one part group at any time, this simplifies coding a lot, but causes trouble for assembly, precisely because of the link to group situation. When multiple links to the same group are added to a parent group, the same child object of that linked group now appears multiple times. App::Part cannot distinguish that.

[ickby]

but ickby won't consider it

Yeah, that was a quite involved discussion back than... but once the assembly3 links and basic assembly methodologies get merged it of course does not make sense to have duplicated functionalities. The basic "assembly" idea I started with was just largely different, hence the desicions on the current implementation of Part and link scopes, but that should be changed (or completely removed when we talk about link scopes) when realthunders work is merged. There should be consistency in the designs in the end. And most likely it makes more sense to change App::Part to work with realthunders ideas as it is already used and known and hence makes transition easier for assemblies.