Improving UX of active Parts

[peterl94]

DeepSOIC's active container is nice in someways, but abstracting away active part and active body to one active container is going too far, IMO. All that I really want is all geometry objects to go into the active part including new parts. I also find it strange that you can have an active body in a different part than the active one (by activating another part after activating a body).

I propose the following behavior:
1. All new geometry objects, including parts, will be added to the active part if they are not otherwise controlled (draft auto group, path job, etc.).
2. Activating a part will deactivate the body in the previously active part.

Implementation wise, I think there could be too many special cases for one function to decide if a new object should be added to the active part. Therefore, I think it should be up to the code that calls "document.addObject" to decide what to do with the new object. This basically means that all commands that create geometry objects will need to be modified to call an "addToActivePart" function.

What do you think?

[DeepSOIC]

but abstracting away active part and active body to one active container is going too far, IMO.

Is there any actual reason behind this opinion? IMO this role distinction doesn't make any sense at all, and is the whole source of the problem "an active body in a different part than the active one".

There can be more "active" stuff, such as "active layer" for example, that should be in parallel and independent...

If we combine proposals
* datum features should not land into bodies, but into parts
* bodies are made not moveable
* free cross-linking across bodies
... then it starts to make some sense. Still not very much

Implementation wise, I think there could be too many special cases for one function to decide if a new object should be added to the active part. Therefore, I think it should be up to the code that calls "document.addObject" to decide what to do with the new object.

In my activecontainer branch, this is essentially how it is. If the code just uses plain old "document.addObject", it lands into active container. But it can use "document.newObject" to place the object to root, or "aContainer.newObject" if it wants to place it into a container different than the active one. The default was merely to minimize porting of old code.

[peterl94]

Is there any actual reason behind this opinion?

Well, let's say I want to create a part that requires two bodies. I first create the part "part 1" and then create a new body and it is added to "part 1" because it is the active part. After finishing the first body, I add a second body and of course I want it added to "part 1" as well. If there was only one active container, it has to have some logic to add the new body to the parent of the currently active body to avoid the extra step of making "part 1" active again. I guess that is specific to bodies, so the body command could be changed to accommodate this, but why change the way it works now? It would just go from an explicitly active part to an implicitly active part.

Other then that, I guess I don't mind having one active container.

* datum features should not land into bodies, but into parts
* bodies are made not moveable
* free cross-linking across bodies

I agree that bodies are currently too limiting, but I don't want to go down that rabbit hole now.

If the code just uses plain old "document.addObject", it lands into active container.

Yes, that is nice in that everything automatically uses the active container. But if I remember correctly, that is what wmayer didn't like. I think I would rather put in the extra effort to port everything to use active container, rather than change the semantics of document.addObject and break everything that expects the object to be at the document root.

[DeepSOIC]

Yes, that is nice in that everything automatically uses the active container. But if I remember correctly, that is what wmayer didn't like.

Well, he didn't like that, but the final argument for me was that my implementation was architecturally incompatible with techdraw, and other stuff that uses its own rendering (not standard 3d view).

I intended to change the implementation. There were big plans on expanding the support after the merge (__after__, so that I don't spend stupendous amount of effort porting everything, and be left with a non-merged branch for the idea not being acceptable from the beginning).
But it didn't happen because reasons (had no time for that), then serious changes to container nesting happened which I have trouble living with, and I just ... well.. lost passion , and decided to stick with part-o-magic for now.

[triplus]

Yeah. I fear that it will take substantial time for things to be tested extensively, for the momentum on what works good and what could be improved to build and after for somebody to implement something like that as a result.

P.S. In parallel i guess part-o-magic workbench could make sense? There is PartDesign, Part and as we discussed in the past some magic in between would likely make much sense too.