Hiding "Operations" (or job) does not hide operations themselves
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
Hiding "Operations" (or job) does not hide operations themselves
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)
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)
Re: Hiding "Operations" (or job) does not hide operations themselves
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 .
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
Re: Hiding "Operations" (or job) does not hide operations themselves
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.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.
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
- Veteran
- Posts: 3459
- Joined: Tue Oct 25, 2011 10:46 pm
- Location: Columbia, Missouri
- Contact:
Re: Hiding "Operations" (or job) does not hide operations themselves
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:
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.
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]
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.
Re: Hiding "Operations" (or job) does not hide operations themselves
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.
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
- Veteran
- Posts: 3459
- Joined: Tue Oct 25, 2011 10:46 pm
- Location: Columbia, Missouri
- Contact:
Re: Hiding "Operations" (or job) does not hide operations themselves
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
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
Re: Hiding "Operations" (or job) does not hide operations themselves
Thanks. I'm building now. I'll give it a look tomorrow.
Re: Hiding "Operations" (or job) does not hide operations themselves
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.
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.
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.
Why not apply the same logic to visibility?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.
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
- Veteran
- Posts: 3459
- Joined: Tue Oct 25, 2011 10:46 pm
- Location: Columbia, Missouri
- Contact:
Re: Hiding "Operations" (or job) does not hide operations themselves
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.
The operations sub-group backplot is showing the entire path that will be postprocessed (not counting multiple WCS).I don't see the need for two renditions of basically the same thing.
Displaying a single op is just that..one op.
Not the same at all.
I don't understand what you mean.When toggling job or Operations, why not iterate all paths and render them if they are visibility true?
Because we live in FreeCAD. It's important that Path things look and behave like they do in other areas whenever possible.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?
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.
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.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.
Re: Hiding "Operations" (or job) does not hide operations themselves
What I meant was:sliptonic wrote:I don't understand what you mean.me wrote: When toggling job or Operations, why not iterate all paths and render them if they are visibility true?
3dview.path[n]visibility = job.visibility AND Operations.visibility AND pathOperation.visibility
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.When you toggle the state of a parent, all the children are toggled as well.
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.
Again not what I'm seeing. If Helix and Profile001 are hidden, unhiding Operations makes them visible.Toggling its state has no effect on its children.
Maybe there is some confusing about what is meant here.
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.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).
I think this is why it is not intuitive. Things are not consistent.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.
Yes, thought that was odd but I was not sure whether I simply had not noticed before.This wasn't always the case. In fact creating the individual ops as hidden is a very recent change.
With respect this was probably not the bit which needed changing.It was made so that there's less confusion.