Tested just now, I'm noticing some big but maybe easy to fix issues with bones:

• In Pose Mode, Object Constraints are not visible
• When attempting to add bone constraints, it seems to try to add it as an object constraint instead, not sure what's going on exactly but it fails to draw:

• Existing bone constraints don't show up anywhere.

In D7499#195153, @Demeter Dzadik (Mets) wrote:

Tested just now, I'm noticing some big but maybe easy to fix issues with bones:

Thanks for testing! That's what I was referring to in my previous comment about being stumped. But you may have given me a good clue to solve it.

Awesome, glad to be of use! More pain awaits!

• Source panel seems to have the constraint header thingie on it, and fails to draw, error in console:

• On Limit Distance, the Reset Distance button is aligned with the Distance slider:

Reproducible Crash 1

• Add single bone, enter pose mode
• Add pose constraint
• Add object constraint
• Delete pose constraint
• Switch to object constraint tab
• Crash

Reproducible Crash 2

• Add single bone
• Enter pose mode
• Add object constraint
• Crash

Not so reproducible crash 3
One time I set my undo steps to 2 since that was something I remembered causing some crashes in the past, and then furiously clicked adding and moving and deleting constraints. This time I got a segfault when deleting a bone constraint:

Great work! With all of that out of the way, I have a suggestion that's more subjective and design related, but I feel quite strongly about it.

I think use_property_decorate=True is a bad idea here. I'm guessing it's being used to follow some sort of UI guidelines, but I think surely we should ask ourselves how often certain properties get animated before making the ability to do so take up space in the UI.

The purpose of the dots is to let users know that these properties can in fact, be animated, which is a noble goal of course. My issue is, users don't care, because there is no use case for keyframing 99% of these values (Influence makes up the 1%). In exchange for this discoverability, the dots add a lot of noise and distraction to an area of Blender that is already very intimidating. So for this reason I think it's a bad tradeoff, and I advocate for use_property_decorate=False, and only setting it to True where it can be sufficiently justified.

In D7499#195778, @Demeter Dzadik (Mets) wrote:

Great work! With all of that out of the way, I have a suggestion that's more subjective and design related, but I feel quite strongly about it.

I think use_property_decorate=True is a bad idea here. I'm guessing it's being used to follow some sort of UI guidelines, but I think surely we should ask ourselves how often certain properties get animated before making the ability to do so take up space in the UI.

The purpose of the dots is to let users know that these properties can in fact, be animated, which is a noble goal of course. My issue is, users don't care, because there is no use case for keyframing 99% of these values (Influence makes up the 1%). In exchange for this discoverability, the dots add a lot of noise and distraction to an area of Blender that is already very intimidating. So for this reason I think it's a bad tradeoff, and I advocate for use_property_decorate=False, and only setting it to True where it can be sufficiently justified.

Heh.. Yeah, it's mainly consistency. If we don't have them here, then why do we have them somewhere else, etc.
I like consistency-- I don't really know why constraints should be different than other areas of Blender. For example, we just added them to materials in properties editor.
That said, I don't have a strong feeling about their value here, so I'll page @William Reynish (billreynish) for his opinion here.

I used to not like them too but they have grown on me as I got used to the change.

Thanks again for the review!

(Edit: Removed my question, I misread your comment)

I'm pretty sure pinning doesn't work yet, Hans might be aware of this but I'll post my findings anyways, maybe it will be useful.

Repro steps for funky object constraint pinning:

• Add 3 unique object constraints; Copy Loc/Rot/Scale.
• Duplicate object
• Enable pinning in the Properties Editor
• Delete top-most constraint (Copy Loc)
• Select the other object
• It's now displaying the constraints of the active object instead of the pinned one, but only displays as many of them as there are on the pinned object. So it displays the first two; Copy Loc and Copy Rot. So, whatever value it's using to figure out how many constraints to display is correct. It's just the object whose constraints are being displayed is wrong.

Bone Constraints seem to have a different problem. It just always shows the constraints of the active bone, regardless of having pinned another. However, the armature and bone names at the top of the Properties Editor do display the pinned object and bone's names correctly.

I think we clearly should include the decorators. The purpose it to communicate the state of the controls (keyframed, animated, driven, overridden, etc) and almost all these properties can have these states. We only disable decorators for sections where those things don't work.

Hmmm, I tried. And I may return to this topic in the future, outside this patch, since it affects the modifier panel too.

But, I think at least you'll agree these keyframing buttons are in the way or confusing:

• On Stretch To, the Volume Min/Max rows, the keyframing button keyframes the checkbox instead of the float value that's actually next to it. It's confusing, but I'm not sure how best to handle. It's nice that the checkbox is next to the float value, so it'd be a shame to lose that just because of this. I hope it's possible to simply make the keyframing button affect the slider instead of the checkbox. But if not, ohwell, it's the smallest of the problems.
• IK constraint, might be still a TODO, I'm not sure, but seems a bit messy atm, in no small part thanks to the 3 keyframing dots in the middle of it.
• On Copy Loc/Rot/Scale/Transforms, if an armature is selected as the target so the bone selector and head/tail slider show up, the head/tail slider has an ugly keyframing button in between properties:
  
  It would also make sense to put the toggle button to the left of the slider, and gray out the slider when it's off. Then the slider can have its keyframing button in the usual place, and the toggle button can live without a keyframing button.

Before committing I went through and dealt with all the problematic decorators. I also did a small pass for consistency on all the layouts and fixed the things @Demeter Dzadik (Mets) mentioned.

@Hans Goudey (HooglyBoogly) sorry for being late to the party, but I have some bad news. It seems to me like any subpanel of any constraint is just empty with this patch. The options in the Transform Constraint are also completely gone (also in the code as far as I can see).

In D7499#196276, @Henrik Dick (weasel) wrote:

@Hans Goudey (HooglyBoogly) sorry for being late to the party, but I have some bad news. It seems to me like any subpanel of any constraint is just empty with this patch. The options in the Transform Constraint are also completely gone (also in the code as far as I can see).

No worries, crisis averted! rBa089286d7b96

Thanks

Yes seems fixed. Good work. (Now I also figured out how those subsections are filled, so nevermind my inline comment on the transform constraint 😅)