Hiding Jobs / Ops

[IMback!]

Disregarding the troll, do you think a feature request on the mantis tracker regarding the hiding behaviour is appropriate?

[sliptonic]

Comparing the Job visibility to Body isn't quite right. The body has a linear nature and a 'tip' object. The Job is more like a container. With a body, you can have any of the sub-elements visible but only one at a time. With a job, you can have any combination of job and operations visible at the same time.

The current behavior isn't an oversite, it's working as intended. It's not perfect and I find it as annoying as anyone but it's acting very 'freecad-ish' in its own way. There really are two separate things, the job commands and the individual operation commands. If we use job visibility to control visibility of the underlying objects, we lose the ability to see the full job. If we change that behavior, it might be more intuitive but it might also be less intuitive depending on your perspective. Or, as they say, "Where you stand, depends on where you sit"

Of course you can add the feature request to mantis but please be very clear about what you want.
Do you want to change the current behavior or add a new feature?

[IMback!]

here we go issue #0004071

i hope this is understandable, the path wb nomenclature makes the description a bit tough.

[chrisb]

If the job is a container then it should be compared to the part container. In a part container we can have several objects each of them can be visible or hidden. But if the part container is hidden, then everthing inside is hidden too. So changing the behaviour would match the FreeCAD constructs we got with 0.17.

[mlampert]

I think there's a slight oversight in this discussion - and the bug.

The visualisation of the Job is not identical to the sum of the visualisations of all ops. The path of each individual op starts at (0,0,0) - whereas in the Job it starts where the previous op's path ended. Both visualisations have independently value and I would not want to lose one or the other. I would also not want to lose the ability to independently make either one of them visible or invisible.

Having said that I agree with everyone else, the current behaviour is quite annoying.

[chrisb]

Both visualisations have independently value and I would not want to lose one or the other. I would also not want to lose the ability to independently make either one of them visible or invisible.

+1

[IMback!]

I think there's a slight oversight in this discussion - and the bug.

The visualisation of the Job is not identical to the sum of the visualisations of all ops. The path of each individual op starts at (0,0,0) - whereas in the Job it starts where the previous op's path ended. Both visualisations have independently value and I would not want to lose one or the other. I would also not want to lose the ability to independently make either one of them visible or invisible.

Indeed this was an oversight on my part. What in your or others option is the utility of being able to see the path starting from 0,0,0? If eatch operation's own visualization started where the last object in the "Operations" object left off so that the sum of the visualizations of each operation WOULD be the same as the visualization of the Job object right now, issue #0004071 could be implemented.

If being able to see the operation as it starts at 0,0,0 is useful, the usability problem of the hiding behaviour could be solved by removing the visualization from the Job object and having a Visualization object as a child of the Job object, and implementing hiding behaviour as per issue #0004071.

[chrisb]

Nothing should be changed in the paths themselves if other ops are visible or not. The visibility must not be mixed with the Active property. If the first op in the job is deactivated, the second op may start at 0.

[sliptonic]

If eatch operation's own visualization started where the last object in the "Operations" object left off so that the sum of the visualizations of each operation WOULD be the same as the visualization of the Job object right now, issue #0004071 could be implemented.

If being able to see the operation as it starts at 0,0,0 is useful, the usability problem of the hiding behaviour could be solved by removing the visualization from the Job object and having a Visualization object as a child of the Job object, and implementing hiding behaviour as per issue #0004071.

mlampert makes a good point. And you can't assume the path movement follows in a linear motion as described. That's true only if you're using a single fixture and ordering by fixture. If you're ordering by tool or operation the assumption is incorrect. It isn't correct that the tool will be coming from 0,0,0 either but at least there's a visual clue to the user that they're considering an operation in isolation.

The aggregated backplot view of the Job and the individual backplots of the operations are really different things and visualization of both are useful in different contexts so they should both be retained.

That said, we're actually managing visibility at three levels, Job, Operations Node, and individual Operation. The Op node is hidden by default. I don't know if it's possible without a lot of work but I'll throw this out as an idea:

The Job node should not have any aggregated path backplot at all. It should just toggle vis of direct children. Toggling it off would hide everything. Toggling it on would restore previous.

The operations node would have the aggregated backplot and be ON by default. Toggling it off hides itself.

The Individual operation nodes would be the same as now but be OFF by default.

So in the default situation, the user would only have to toggle one thing -- the operations node -- to hide everything but the behavior would still be essentially what it is now. They could also toggle the whole job to hide everything including stock, model, etc.

[IMback!]

I think this would be fine and would solve the feature request on my part.

However on ordering and Operations object, I really think that how the order in the Operations object (witch can be changed by the user) relates to the output order (set in path object) is really confusing atm because there is no indication what order will be output. Im not shure what the differance between "order by fixture" and "order by operation" is even in freecad at this point, because the fixtures in FC are just an object and child of the "operations" object just like every other operation, and the user gets to order those by hand.

maybe (really not shure) it would be better if the tree looked like this :

When ordering by fixture

Code: Select all

Job
|
+-Tool 1
|
+-Tool 2
|
+-Tool 3
|
+-Fixture 1
|	|
|	+-Operation 1
|	|
|	+-Operation 2
|	|
|	+-Operation 3
+-Fixture 2
|	|
|	+-Operation 1
|	|
|	+-Operation 2
|	|
|	+-Operation 3
+-Model
+-Stock

When ordering by tool:

Code: Select all

Job
|
+-Tool 1
|	|
|	+-Operation 1
|	|
|	+-Operation 2
|	|
|	+-Operation 3
+-Tool 2
|	|
|	+-Operation 1
|	|
|	+-Operation 2
|	|
|	+-Operation 3
+-Fixture 1
+-Fixture 2
+-Model
+-Stock

alternatively maybe the output order should allays be as orderd by the user in the "operations" object and if the user wants to order by tool or by fixture he/she will just have to do that by hand in the operations task ui. (maybe with a button that orders by tool or by fixture in the "operations" object task ui)