Hi Roland, isn't this already handled by the 'Inverse Kinematics' panel that appears in the bone constraints area now if you have an IK constraint?

Ah. That's odd, because when I can't find a control, I usually grep through the ui scripts for the appropriate RNA tags. Must not have done it this time.

Actually, though, that points something out to me: the Inverse Kinematics panel is really in the wrong place, and has the wrong show/hide poll. It should be on the bone panel, where I put it. Here's why:

1. Internally, those settings follow the pose bone (pose channel, pchan), not the constraint.

2. The settings are also needed on bones that don't even have the constraint, but are just a part of the IK chain. To expect the user to look in the constraints context when they know a particular bone doesn't have a constraint is in error.

3. These settings also function with targetless and Auto IK, meaning that potentially any bone need these properties at any point, regardless of the existense of an actual IK constraint. In the past, users had to add an IK constraint to their bones just to get these settings to appear. Then, they would make their settings and delete the IK constraint, in order to get the restrictions to function with Auto IK.

Really, these controls should exist in the Bone context and be available at all times, though greyed out whenever the "has_ik" property isn't set.

I find it interesting that my panel which follows (imo) the ui guidelines in the docs on .org looks like crap, while the existing panel in the constraint context eschews the guidelines and looks much nicer. I guess whoever made the panel knows when to break the rules.

I'd recommend moving the Inverse Kinematics panel from the Constraints context to the Bone context, and to change the polling so that it is always available on every pose bone.

Okay, went through the existing code and rearrange and fixed active mode stuff a bit. This appears in the new patch "ik_controls.patch".

This patch moves the IK Restrictions panel from the constraints context to the bone context. Users had to look in the constraints panel to find settings for any bone in the chain, even if that bone itself didn't have a constraint. Pretty counterintuitive. Also, the settings though greyed out in the bone context are now available at all times so that they can be set for effect with Auto IK, which was not possible before.

Additionally, the Legacy/iTaSC toggle has been moved to the armature level, as it is an armature-level setting. The entire iTaSc panel has also been moved to armature level, as, once again, these settings apply to every bone in the armature. Leaving these controls at bone level (or appearing in the constraint panel) gives the false impression to the user that such properties are adjustable on a bone-by-bone basis, while they are not.

I think that this configuration presents a more logical and useful presentation of these controls to the user.

Hi Roland,

In general, I agree with your rationale behind each change.

The points about making it clearer that the IK-solver type is something at armature-level rather than per-constraint is quite logical. However, there is a bit of a risk here that changing these settings becomes the game of cat and mouse that we had with the old Material/Texture buttons split. A primary cause of concern is that the iTaSC panel settings may often need to be tweaked in conjunction to those for the constraints which use it (though having not used it much, I'm not terribly sure how often that is practically required). Secondly, by having this under bone constraints, the panel only needed to be shown/exposed to the user when this solver was actually being used for something, while putting it under armature usually means that we either always show it (even if nothing uses it, confusing the average user) or if it is only shown when the selected bone has an IK-solver then it may flicker in/out too much.

I'm not too sure what's the best direction for this. Any comments Matt?

About showing the IK Restrictions panel to the bone context. Go for it. Looks like we've got a new feature there too which should be a good thing. As long as it's clearly communicated that those restrictions are only effective when the bone is part of an IK chain, then that's good.

It could turn into tail-chasing. I'm no fan of the way that certain settings in the Texture context follow the texture type, while certain others follow the texture slot and there's no way for the user to know this ahead of time from the UI organization.

That said, I really think that the iTaSC settings panel goes at the armature level and should always be visible. I already stated the other reasons, but the kicker for me is Auto IK. You can have situations where someone needs those settings without ever adding an IK Constraint. To have them go looking in the constraints panel when they are potentially only using Auto IK makes less sense than the alternative. Perhaps in situations like this, it would be beneficial to augment the UI for the IK Constraint to include a help string like "iTaSC settings available in Armature Context" or something.

Also, with iTaSC at the bottom of the armature context, and defaulting to closed, I don't think it creates an issue of confusion for less experienced users. It's out of the way, and I think that people new to a certain section of Blender (or any app) are likely to just leave highly technical-looking panels alone rather than just starting to manipulate them without knowledge. They take a look, go "Yikes" then collapse the panel.

Ok, fair enough.

So, unless Matt has any objections, go ahead and commit I guess. :)