Hiding "Operations" (or job) does not hide operations themselves

[Lupin]

Usually when you set the visibility of an object ("space" or via menu), all the child elements are hidden as well. But if I do the same thing on the "Operations" group, the operations ("profile", "pocket", ...) stay visible. Is that on purpose?

The same with jobs. If I hide them, I still have to hide every single child element (operations, model, stock), for nothing of the job to be visible.

OS: Windows 7 Version 6.1 (Build 7601: SP 1)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.24291 (Git)
Build type: Release
Branch: releases/FreeCAD-0-19
Hash: 7b5e18a0759de778b74d3a5c17eba9cb815035ac
Python version: 3.8.6+
Qt version: 5.15.2
Coin version: 4.0.1
OCC version: 7.5.0
Locale: German/Austria (de_AT)

[chrisb]

Is that on purpose?

It used to be on purpose, and it was never changed. If I remember correctly, the last time this was discussed, sliptonic said, that it might well be changed. So if you have the abilities - go for it .

[freman]

The same with jobs. If I hide them, I still have to hide every single child element (operations, model, stock), for nothing of the job to be visible.

There is a strange kind of logic going on here. Visibility of an operation seems to be job.visibility OR Operations.visibility OR operation.visibility. In practice this seems to mean you might as well hide all jobs as soon as they are created. Then you can toggle each path op.

I would expect job.visibility AND Operations.visibility AND operation.visibility, that would mean you can toggle all the ops in a job hidden at the job level or individually.

Since ops and jobs soon create so much clutter you cannot see what is what, the reality is that you need most ops hidden except the current one or one or two related ones you need to compare.

If you have several jobs it is likely you will need to hide all others to clearly see what you are doing ( jobs may even have different part orientations and origin definitions ).

The ability to hide all ops at the job level would seem to make sense. It's unclear to me what the thinking behind the current logic is.

[sliptonic]

There's a lot of legacy stuff going on here.

When Path was first implemented there was only two levels. The operation and the Job. Both are implemented in the C++ code and have Python interfaces. They both have the job of holding Path commands and producing the corresponding 3D visualization. A single Path object is a Path::Feature and a Path::FeatureCompound does the same thing but also acts like a regular group.

You can play with this to see how it works at a low level:

Code: Select all

>>> import Path
>>> p1 = Path.Path("G1X1")
>>> o1 = App.ActiveDocument.addObject("Path::Feature","path1")
>>> o1.Path=p1
>>> p2 = Path.Path("G1Y1")
>>> o2 = App.ActiveDocument.addObject("Path::Feature","path2")
>>> o2.Path=p2
>>> o3 = App.ActiveDocument.addObject("Path::FeatureCompound","compound")
>>> o3.Group=[o1,o2]

It made sense that you'd want to visualize either individual operations or the whole job. It was also expected that postprocessing would done at the Job/Compound level.

Even now you can get a reference to the Job document object and it has a Path property which is an aggregation of all the underlying operations.

A lot has changed since then.
First the Job got more complicated as a container. It holds the model clone, the stock, the setupsheet, tool controllers and toolbits, etc.

Since the job was holding a lot of stuff that doesn't have Path commands, we introduce the operations group to keep things somewhat tidy. The operations group reused the same Path::FeatureCompound object.

Also the postprocessing process got much more complex. Instead of working at the job level, it iterates over all the individual operations and may add additional code and repeat operations to handle different work coordinate systems. It really isn't using the aggregated Path of the Job at all.

In my opinion, it's no longer necessary for the Job to be based on a Path::FeaturePython object at all. It could probably be based on a simpler PythonFeature object as long as it can still function as a group. That would leave just two levels of rendering which I think is still needed.

[freman]

Thanks for such a detailed explanation, that's a great help.

To clarify, it seems that what we are seeing is different, independent renditions of the same path operation, not multiple objects controlling the visibility of the same rendition. That is why it appears to using OR logic but that is not what is happening.

Is that correct ?

Are we talking about three renditions or two?

thanks.

[sliptonic]

Here's a quick and dirty hack to play with.
This replaces the Path::FeatureCompoundPython object of the job with a simpler Part::Feature object and adds the group extensions.

I'm sure there's implications that I haven't considered but it works enough for someone to take a closer look

https://github.com/sliptonic/FreeCAD/tr ... /nopathjob

[freman]

Thanks. I'm building now. I'll give it a look tomorrow.

[freman]

I'm still seeing what looks like the same behaviour from the user POV.

Whether I see a path op still seems to be job.visibility OR Operations.visibility OR pathOperation.visibility Presumably you were not intending to change behaviour, just the data storage.

So if there are just two renditions now, I'm guessing that toggling job.visiblity is controlling Operations.visibility .

I don't see the need for two renditions of basically the same thing. When toggling job or Operations, why not iterate all paths and render them if they are visibility true?

That provides a different logic:

job.visibility AND Operations.visibility AND pathOperation.visibility

This is what I would expect from the tree view and has always confused me about this visibility thing. Apparently, I am not alone, this feels counter intuitive. Maybe it's just depends on how you are used to working.

Also the postprocessing process got much more complex. Instead of working at the job level, it iterates over all the individual operations and may add additional code and repeat operations to handle different work coordinate systems. It really isn't using the aggregated Path of the Job at all.

Why not apply the same logic to visibility?

Currently jobs are created visible, which is expected since it is the current focus of work.
Path ops are created hidden which is a bit disrouting. If I've just created something I at least want to see it to confirm it is how I want it. If it is likely to clutter what I do next I will click it hidden before creating the next path. I may want to keep for comparison.

In switching between jobs I would like to hide the one I'm leaving, without having to dig down all levels to hide individual paths as well. I think that was the expectation of OP which started this discussion.

[sliptonic]

I'm still seeing what looks like the same behaviour from the user POV.

Whether I see a path op still seems to be job.visibility OR Operations.visibility OR pathOperation.visibility Presumably you were not intending to change behaviour, just the data storage.

The behaviour has changed - quite significantly. In the past, the job visibility was controlling whether or not you were seeing the job's version of the underlying paths. Toggling its visibility had no effect on the children. Now, the job is not rendering the Path at all and toggling its state affects its children (both path objects and others other objects like stock).

The distinction isn't about the visibility based on the state of a node in the tree. It's what happens when you toggle that state. With my branch, the job is now a regular group like other groups in FreeCAD. When you toggle the state of a parent, all the children are toggled as well. Of course, you can open the group and toggle the state of any child. That means you can toggle the state of either the operations group or an individual operation.

However, the operations sub group is NOT a regular FreeCAD group. It's still based on Path::FeatureCompoundPython. Toggling its state has no effect on its children.

I don't see the need for two renditions of basically the same thing.

The operations sub-group backplot is showing the entire path that will be postprocessed (not counting multiple WCS).
Displaying a single op is just that..one op.
Not the same at all.

When toggling job or Operations, why not iterate all paths and render them if they are visibility true?

I don't understand what you mean.

This is what I would expect from the tree view and has always confused me about this visibility thing. Apparently, I am not alone, this feels counter intuitive. Maybe it's just depends on how you are used to working.
...

Why not apply the same logic to visibility?

Because we live in FreeCAD. It's important that Path things look and behave like they do in other areas whenever possible.
The current behaviour of the Path node in the tree is confusing because the group doesn't behave like other groups. The reason for the distinction isn't valid anymore. I think we should fix that.
The same could be argued for the operations sub-group but I think there's value in it showing the whole aggregated path. Reasonable people might disagree with me on that point but let's take this one step at a time.

Currently jobs are created visible, which is expected since it is the current focus of work.
Path ops are created hidden which is a bit disrouting. If I've just created something I at least want to see it to confirm it is how I want it. If it is likely to clutter what I do next I will click it hidden before creating the next path.

This wasn't always the case. In fact creating the individual ops as hidden is a very recent change. It was made so that there's less confusion.

[freman]

When toggling job or Operations, why not iterate all paths and render them if they are visibility true?

I don't understand what you mean.

What I meant was:
3dview.path[n]visibility = job.visibility AND Operations.visibility AND pathOperation.visibility

When you toggle the state of a parent, all the children are toggled as well.

I don't think that is an accurate description of what happens. Probably just a question of language. Toggling ( inverting ) the job, does not invert the child.

See attached FCStd. Toggling hole-job from hidden to visible makes Profile001 visible irrespective of its prior state. This is the OR logic I described above.

Toggling its state has no effect on its children.

Again not what I'm seeing. If Helix and Profile001 are hidden, unhiding Operations makes them visible.

Maybe there is some confusing about what is meant here.

Now, the job is not rendering the Path at all and toggling its state affects its children (both path objects and others other objects like stock).

That is another anomaly. The visibility of the stock is only relevant while the job ( or Operations ) is selected. When I take the focus of hole-job, the stock disappears. Also stock is green when turned on by job but black when toggled itself. Again confusing.

The current behaviour of the Path node in the tree is confusing because the group doesn't behave like other groups. The reason for the distinction isn't valid anymore. I think we should fix that.

I think this is why it is not intuitive. Things are not consistent.

This wasn't always the case. In fact creating the individual ops as hidden is a very recent change.

Yes, thought that was odd but I was not sure whether I simply had not noticed before.

It was made so that there's less confusion.

With respect this was probably not the bit which needed changing.