Workspace (or how to call it)

[triplus]

Why do we need to have an active container? Can't we just simply drag and drop to different containers for assembling?.

Active container is needed if you want to have the ability to automatically put things into one. Without user need to drag and drop things in it manually. And this is PartDesign related and not directly Assembly related piece of functionality.

[DeepSOIC]

For me, when I build my devices, I'll want to use fusion and stuff or PartDesign body to produce discrete parts, to be 3D printed, milled or whatever. At this stage, no App::Part is involved. Then during the assembly stage,

Sometimes you might need to do assembly first, then do some more modeling.

Imagine you are designing an optical instrument. You may be starting with optical path. Then add mirrors. Then you design stands for the mirrors. That's already an assembly. And now you need to model a baseplate with pins and screw holes to mount all the mirror stands. That's when you need to use assembly to drive a modeling process.

[realthunder]

Imagine you are designing an optical instrument. You may be starting with optical path. Then add mirrors. Then you design stands for the mirrors. That's already an assembly. And now you need to model a baseplate with pins and screw holes to mount all the mirror stands. That's when you need to use assembly to drive a modeling process.

Oh, that's a good one. It just occurred to me that I sort of used same process in my design before, although without the container feature back then, I was forced to design my part at the assembly position, then move to different file later. I am surprised that I forgot about this. It's been a while back, and I guess I was so used to the work around approach I forgot how awkward it is at the beginning.

[ickby]

both! But I haven't yet established how to implement it all. I originally planned to make workspace very similar to Container, to derive from ContainerBase. But it looks like it may not work.

Than I have to admit I don't understand the concept. What is the purpose of the workspace? I don't see any added value compared to the current object structure. Most likely I miss something, but lets go through your points:

This example has two workspaces.
One is root, formed by Document, and contains Object1, Group, Object2, and Part.
Other is formed by Part, and contains Object3, Group2 and Object4.

Workspace 2 is excactly the same as geofeaturegroup. For workspace one there is no additional object, ok, but its the top level, so why is one needed?

Selection limiting means that if I have selected two objects and applied Part Fuse, the selection will check that all objects are in workspace of active container, and return nothing if it isn't the case. That is, Part Fuse will be grayed out if I select two objects from different workspaces.

Works exactly the same when checking for the active geofeaturegroup.

Transform computation is for helping out tools that are aware of Parts and Bodies. For example ShapeBinder.
Transforms create implicit dependencies. Workspace-aware fusion of Cube1 from Part1 and Cube2 from Part2 makes the fusion depend on placements of Part1 and Part2. This must be reflected in dependency graph to ensure correct order of computation.

Works exactly the same when done with geofeaturegroups

Part contains some objects. Part also has Placement property.
What happens when Part has non-zero Placement? Visual representations of everything contained by Part is moved according to Part.Placement. That's all, as of now.

That statement is wrong. If a part is moved the things contained in it shall not change, as they are defined in the local coordinate system defined by the part. Everything is correct, they change their global placement without doing any change in their placement property. The problem is only that currently tools do not recognize the notion of local coordinate systems. Hence they must be made aware. I think this is why you like to introduce the workspace. But if it must be done anyway, there is no benefit of doing it with the workspace compared to just using geofeaturegroup. One can simply add a function to geofeaturegroup to calculate the global placement (I have done that in my branch)

Currently I think that all you intend to do with workspace can be done with geofeaturegroup, all the intended API calls etc. can be added to it. Actually this is why I got to such great lengths to create a universally usable primitive for that, so that it is used universally for those kind of things. Not to talk about the hassle for the user for yet another hard to explain object in his tree.

[ickby]

One additional note: I did not look into master a while and worked in my branch, It may be the case in current master, that geofeaturegroup does not hold all children, for example if they are in a grou within the geofeaturegroup. this is changed in my branch, as a geofeaturegroup must directly llink everyything that is within this geofeaturegroup, meaning all objects and groups, and objects within groups. Only the content of other geofeaturegroups must not be linked directly.

see https://github.com/ickby/FreeCAD_sf_mas ... sion.h#L37

Maybe thats the reason why I don't see a benefit in a workspace, because we tackled the same issue?

[realthunder]

Currently I think that all you intend to do with workspace can be done with geofeaturegroup, all the intended API calls etc. can be added to it. Actually this is why I got to such great lengths to create a universally usable primitive for that, so that it is used universally for those kind of things. Not to talk about the hassle for the user for yet another hard to explain object in his tree.

There is one significant limitation in geofeaturegroup. And we've been over this many times, that an object cannot appear in different groups. This limitation is caused by the simplistic grouping of children viewprovider root nodes under group's node. I have a solution for that, and it is proven in my Link branch. When App::Link links to a geofeaturegroup, it creates internal link to all group's children by replacing those children viewprovider's root node. As the author of geofeaturegroup, I'd like to ask you for permission to change geofeaturegroup's viewprovider to do the same. This shall lift the one parent group only limitation.

[DeepSOIC]

this is changed in my branch, as a geofeaturegroup must directly llink everyything that is within this geofeaturegroup, meaning all objects and groups, and objects within groups. Only the content of other geofeaturegroups must not be linked directly.

That means I have to exclude Group from being a container, and then I can't activate a group to receive new objects.

Another problem here is that I want non-moveable bodies. That is, Bodies that act like a group in that they allow free cross-linking, but in all other respects function like PartDesign Body. Now if a Part contains a few bodies, I might want to use all bodies from a part for something (e.g. make a Compound from Part's bodies). Now if the part also links to every feature in every Body, I will have a hard time automating this.

[ickby]

There is one significant limitation in geofeaturegroup. And we've been over this many times, that an object cannot appear in different groups.

And this has been an design desicion. In the beginning I intended to do this differently too, but in many long discussion we than decided to not allow a object in multiple containers, but instead go for instance objects.

That means I have to exclude Group from being a container, and then I can't activate a group to receive new objects.

Why? Does that not only means that one need to ensure in "addObject" that the oject is not only added to the group, but also to the groups parent geofeaturegroup.

Another problem here is that I want non-moveable bodies. That is, Bodies that act like a group in that they allow free cross-linking, but in all other respects function like PartDesign Body. Now if a Part contains a few bodies, I might want to use all bodies from a part for something (e.g. make a Compound from Part's bodies). Now if the part also links to every feature in every Body, I will have a hard time automating this.

But this handling needs to happen in the respective addObject calls anyway, I don't see any hard thing there.

Again, the reasons seem very minor for introducing such an object with all the hassle that comes from it.

[DeepSOIC]

Not to talk about the hassle for the user for yet another hard to explain object in his tree.

Workspace isn't in tree!! It's an API thing, a mean to deal with the structure of document objects, a mean to easily obtain transforms, placement stack, filter selections... Just like my Container is. And having it applicable directly t Document as well makes it easier about reducing the number of ifs in code that uses it. Because these ifs generate a lot of bugs and code unreadability.

[ickby]

Workspace isn't in tree!!

Oh, than I missinterpreted the idea. Well, not making it harder for the user was my only concern and if it helps making a unified API I'm all for it. Sorry for the hassle.