Non-streamlined context menu Property View

[pieterhijma]

Non-streamlined context menu Property View

[yorikvanhavre]

I would suggest even more: Let's add some cool UI stuff to the property editor to do that. For ex:

• A "+" button somewhere, for ex here:

• That button opens the "add dynamic property" dialog

• That dialog maybe needs some rework, some options are IMHO a but unclear for new users

• Dynamic (removable) properties should be somehow marked in the properties view, and indeed an easy way, but less obvious than a "-" button, to remove them (right-click?) offered.

• But there are dynamic properties added by workbenches, which should not be removed by the user (although they in theory are), and user-added properties, which should be easy to remove. How to differentiate them?

[pieterhijma]

I would suggest even more: Let's add some cool UI stuff to the property editor to do that. For ex:

• A "+" button somewhere, for ex here:

Cool idea, I'm not sure whether that is possible/wanted because of the fact that that space is reserved for tabs.

[pieterhijma]

• That dialog maybe needs some rework, some options are IMHO a but unclear for new users

Yes, I agree.

• Dynamic (removable) properties should be somehow marked in the properties view, and indeed an easy way, but less obvious than a "-" button, to remove them (right-click?) offered.

Yes, I think a right-click makes sense.

• But there are dynamic properties added by workbenches, which should not be removed by the user (although they in theory are), and user-added properties, which should be easy to remove. How to differentiate them?

Hm, good question. @yorikvanhavre, do you have a concrete example of a dynamic property added by a workbench that shouldn't be removed? @FlachyJoe figured out something with property status in this comment.

By the way, I in my humble opinion, the name "dynamic" for properties is not so useful for users. Doesn't it simply come from the fact that dynamic properties are added to objects at run-time, meaning that statically (in the code, at compile-time) no information is available about them. If this is the real differentiator between dynamic properties and non-dynamic properties, then I think we shouldn't bother users with this term. I think we don't even have to make a distinction in that case. For a user it is enough that some properties are hardcoded and cannot be removed and some can.

[FlachyJoe]

@pieterhijma unfortunately getPropertyStatus returns 21 for all dynamically added properties, user and python ones.

My user property list displays FEM objects 😢

[pieterhijma]

Right, that is a pity...

[FlachyJoe]

Found the LockDynamic status to prevent the dynamically added property to be removed.
I'm making a PR to add this status to FEM object's.
EDIT: #13687

[FlachyJoe]

Expression... (I would be totally ok to remove this one altoghether)

Not OK, it's the only way to set an expression to non-numeric properties.

[pieterhijma]

Found the LockDynamic status to prevent the dynamically added property to be removed. I'm making a PR to add this status to FEM object's. EDIT: #13687

Great! @yorikvanhavre and @FlachyJoe, what do you think? Should it become a convention for workbenches to distinct the properties that they deem important to mark them as such?

[pieterhijma]

Expression... (I would be totally ok to remove this one altoghether)

Not OK, it's the only way to set an expression to non-numeric properties.

Yes, you're right. I figured that out myself as well. I never used it, so if you want to use an expression to set a boolean for example, you have to use this. It's a bit of a pity that the expression system only supports numeric values and strings.

[pieterhijma]

I've submitted draft PR #13691 that rearranges the menu, keeping the "Expression..." item. For me, this would totally suffice, but an add button that @yorikvanhavre suggests, would be nice too.

[yorikvanhavre]

an add button that @yorikvanhavre suggests, would be nice too.

This would of course be matter for another PR. No need to do all at once :)