App.ActiveContainer

[triplus]

And one additional question.

Is there a real need to have PartDesign BOA commands (and some other too) or Part BOA commands (and counterparts) could be used instead in PartDesign NEXT workbench? The reason i ask is PartDesign BOA commands are a fork of Part BOA commands? And forks usually lead to duplicating the effort on the long run.

[NormandC]

Like triplus I wish the matter of containers could be simplified for end users. It's going to be confusing as hell for them and we'll have to explain again and again when to use a Part container and when to use a Body container. Not to mention the fact the Body can only hold a single solid, or that Part can contain multiple objects including bodies, therefore it's more like an assembly...

But I understand it may not be easy to accomplish.

The heart of this topic is way too technical for me. Mainly I wanted to comment on this:

In addition, it allows to deploy another container-like system I plan to call Workspace

Will this workspace container be exposed to end users?

I just want to point out that plenty of end users misplace the use of workspace for workbench. Two such examples.

If "workspace" is to be used as a container name in the UI, it will bring yet another level of confusion...

[DeepSOIC]

Will this workspace container be exposed to end users?

Not very much, it's more of an abstract thing.

Sorry for not replying, we moved to village (summer has come). Lots of small duties.

I'll try to explain what is workspace and why I don't like calling it coordinate system or reference frame, later. Let's stay on topic.

I doubt creating and maintaining such list makes much sense. There i guess should be a mechanism and developers...

There is a mechanism, just read the first paragraph:

From now on, the recommended way of creating new objects is:
App.ActiveContainer.newObject(...)
Doing so, you are specific about that you are creating an object into active container. If you for whatever reason want to create an object into any other container, use:
App.Containers.Container(App.ActiveDocument.Group).newObject(...)

All calls to App.ActiveDocument.addObject(...) are implicitly redirected to App.ActiveContainer.newObject(...). You can use App.ActiveDocument.newObject if you want to ignore active container.

[DeepSOIC]

P.S. What could be a bit troublesome (too me) is all this double click action needed to change containers. It's slowing down the workflow.

+1. We could have a bit of automation here, but I don't have a clear idea hw to improve that.
As you may know, in Part-o-magic I added leave and enter commands to complement double-click activation. Sometimes, the container to put new object to can be better figured out from selection. For example, doing Part Union, you would likely want to place the fusion into the container of the originals. Yet for Clone, that isn't the case. So suggestions are welcome.

I think, in the near future I will try out limiting selection to active workspace (i.e. if you press Part Union, it will see only the stuff selected within active container). So the Union button will be grayed out if you select things from different workspaces. That will cause lots of questions... so I am thinking of how to provide the feedback on why the command is grayed out. And I have some experiments in Part-o-magic in that direction.

[triplus]

Sorry for not replying, we moved to village (summer has come). Lots of small duties.

East Village?

I'll try to explain what is workspace and why I don't like calling it coordinate system or reference frame, later.

Fair point. Note that my proposal would come down to Coordinate System. And in addition there wouldn't be distinction between Part/Body or Part/Workspace anymore. From the user point of view. The same Coordinate System feature would be used and only based on the usage the distinction would be made. Without the end user need to understand anything beyond the fact Coordinate System feature was added. A stand alone one (Body/Workspace) or if added in another Coordinate System (Part).

There is a mechanism, just read the first paragraph:

Good.

+1. We could have a bit of automation here, but I don't have a clear idea hw to improve that.

I am thinking selection could play a role? Selecting something in the Tree View or in the 3D View could automatically activate corresponding "container". And for special use cases have a "Lock" flag user can enable and for active flag not to change based on the selection?

I think, in the near future I will try out limiting selection to active workspace (i.e. if you press Part Union, it will see only the stuff selected within active container). So the Union button will be grayed out if you select things from different workspaces. That will cause lots of questions... so I am thinking of how to provide the feedback on why the command is grayed out. And I have some experiments in Part-o-magic in that direction.

I guess we need to understand first what will be the predominant workflow. And if hiding something makes sense in it or not. Do what you feel is appropriate and listen on how pleased or annoyed the end users will be.

[ickby]

I think those changes work really well. It makes the changes work more seamlessly.

One thing that should be changed IMHO is the error when something is not accepted by the container. For example adding a Part::Box when the body is active. I think best would be to add it then automatically to the parent container, and going upwards till it is possible (in the document it always is). The reason for this are the many workbenches that can use e.g. Body. If you work on a body and like to make a FEM analysis or PAth, you would need to deactivate the body first. That is a bit annoying.

Like triplus I wish the matter of containers could be simplified for end users. It's going to be confusing as hell for them and we'll have to explain again and again when to use a Part container and when to use a Body container.

I'm not entirly sure where that confusion is coming from. Many workbenches work like that, Fem needs an analysis object, Path a job, Drawing a Page, and PartDesign a Body. I think the general workflow of having a parent object is a known thing. Maybe if we move the Part Object out of PartDesign and make a global toolbar for it the confusion gets lifted? Than it is more apparent that this is not a modeling entity, but a general one.

[ickby]

@DeepSOIC: I have a question regarding the single active container. I think in the future more containers will see the light of the word, for example the FEm and Path objects may use the default Group object. Wouldn't it than not make sense to have different active types? So one active body, on active Path job, one active Drawing Page etc.?

[DeepSOIC]

for example the FEm and Path objects may use the default Group object. Wouldn't it than not make sense to have different active types? So one active body, on active Path job, one active Drawing Page etc.?

One thing that should be changed IMHO is the error when something is not accepted by the container. For example adding a Part::Box when the body is active. I think best would be to add it then automatically to the parent container, and going upwards till it is possible (in the document it always is).

I don't think so. You can't create Part Box when editing a sketch, because sketch can't accept it. Same here. I want active container to be somewhat similar to what editing mode is. With this concept, having multiple active containers doesn't make sense.

As I already noted, I didn't take down the viewer's active object system. It can still be used for more active containers that work in parallel. For example, if we ever make Layer functionality, it is a perfect candidate for being a parallel system of active objects. FEM and Path are not worth the parallelism, IMO.

Yes, single active container requires you to do some extra clicks, but it reduces confusion IMO.

Another reason for having a single active container is visibility automation. Activating a container can instantly bring one into the right context, and switch on the right workbench. With multiple containers, it becomes too complicated IMO.

[wmayer]

I'm not entirly sure where that confusion is coming from.

Especially in PartDesign we have two container objects: Part and Body where it's not obvious when to use what. Furthermore both terms are translated as Körper in the German translations which completes the confusion.

Another somewhat annoying behaviour is that when loading a project file you always have to explicitly activate a body before you can continue. Some commands at least pop-up an error and some other commands like creating datum geometries just don't do anything.

[DeepSOIC]

Sounds like Part container should be renamed.
Any ideas?
Same things come to mind... container, workspace, coordinate system, reference frame... Maybe name it "Group", but differentiate it from the old group as "moveable group" in context menu? or "geometric group" maybe, which is very much like what it's called in code.