wmayer wrote: ↑
Tue Jul 02, 2019 7:13 am
But this makes it harder to find out the root of the problem because you can't easily see any more which feature is causing the actual problem.
chrisb wrote: ↑
Mon Jul 01, 2019 8:04 pm
Independent from what to display I would like to see the error state generalized: If something is in error, then everything depending on it is in error too. This should hold for sketch-feature-body-part as well as for the constructs from Part workbench.
Jee-Bee wrote: ↑
Mon Jul 01, 2019 5:22 pm
Why not just breaking the model.
All features that follow on the broken sketch/ feature don't show up?
Jee-Bee wrote: ↑
Tue Jul 02, 2019 7:55 am
special PartDesign this is easy just the first one.
So for part design i think it is fine to add all resulting errors.
for rest i don't know...
There are two points:
(a) what to show in the tree.
(b) what to show in the 3D View.
The current behaviour in the 3D View I think it is the best choice. It still allows to follow the history of the part. If the model broke because a change in a spreadsheet and this value is used in several features, only the one(s) that break are actually shown as in error, while the others adapt to the new value.
For the behaviour on the tree, setting every single feature depending on the broken in error and showing the very same icon (red exclamation on the top right), I think is not the right call. Many of those features marked in error would execute just fine when the broken thing is fixed. I think it is misleading to show the user that the model is fully corrupted and he has to start over again, when something specific just needs to be fixed.
What needs to be somehow marked, IMO, is to show the fact that something in the body is wrong and this most likely mean the body is wrong. This is way I focused on marking the body.
I tend to agree that if something inside is wrong then the body is wrong. What I do not know is if there are cases where the body itself has a red error exclamation sign on the top right for some body related reason and if "my new flag", relating to the features inside, could collide with it.
The reason for choosing a different position/colour could be to differentiate that a feature is broken, and it is not the body itself the reason. But I am extraordinarily open to any colour and position.
I am not sure which other group extensions are there:
- App::Part (which is not inherited further)
I really have no idea how these other classes would like to have the status represented, whether it makes sense or not... anybody?