WIP Experiment - Including Relevant Parameters in Keymap Names

Today for a bit of a challenge, I've been playing around with the keymaps editor UI to try and get it to display more helpful names for operators. As anyone who's played with this knows, it's not terribly helpful right now when you're faced with a list of 10 items in a row labelled "Context Enum Toggle" and each with different hotkeys ;)

DISCLAIMER: The following screenshots merely demonstrate a highly proof-of-concept hack aimed at establishing techniques for successfully extracting the necessary info out of the PyAPI. In practice, this has been much less cooperative than I'd have liked, so the ways that these things are actually presented is less than optimal.




Without further ado, here are the screenshots:

As can be seen, I've tried to get the operator name labels displaying a bit more interesting/relevant information about each operator, by digging into their properties and trying to extract some of the more interesting aspects. Specific things I've done:

• Special handlers for all the WM_OT_context_set/toggle/cycle/etc. operators which can be used to assign hotkeys to particular properties. The main idea here is to display the name of the property (ideally one that users see, instead of the property identifier as shown here) along with the type of operation (toggle/set/cycle) the hotkey performs on that property. For example, "proportional_edit_falloff Cycle Values" or "Toggle use_proportional_edit" operators in the first screenshot
  
• Show name of menu for WM_OT_call_menu operator, instead of the vague "Call Menu" label currently used. This has proved much harder than anticipated to get the desired results, since there doesn't seem to be any way to look up menu types from their C-Style identifiers (i.e. "VIEW3D_MT_transform"). Examples here include "VIEW3D_MT_object_specials Menu" in the screenshot above.
• Show properties specified for other operators - examples include the "Add Rigidbody" operators, "Subdivision Set" operators, and "Select Hierarchy" operators. 
• I'm not entirely satisfied with the way these look yet, but, for single properties (e.g. Subdivision Set) it's starting to take shape. 
• Ideally, ENUM properties would be shown using their UI names instead of the identifier names. Again though, the PyAPI is a bit of a pain here, and spews out truckloads of warnings for operators such as GROUP_OT_remove and so forth which use dynamically generated enums.
• Also note though, that there are severe limitations on what can be done here - notably, the "(De)Select All" labels cannot magically transform into "Toggle Select All" and "Invert Selection" (respectively), as there's simply no way to do this automatically given the labels that we have available. Any other labels seen for these in the menus are actually hand-coded hacks used for those specific places, with the potential for different places to need different labels accordingly (i.e. different grouping/space available results in different presentation constraints)

As mentioned, there are currently quite a few pitfalls in the PyAPI for doing this. Some of these are blocking issues, while others can probably be worked around, but would require quite a bit of convoluted code:

• Cannot easily look up user-visible names for operator properties and enum-values. From the looks of things, it should be possible to do this by poking around in the right places for the rna typeinfo, but it's still quite nasty. Unfortunately, as the API was kindof designed to act quite "native" in places (for property access), it makes it harder to retrieve specific information you require at times.
• No way to look up menus given a menu identifier. There's an API function internally, but this hasn't been exposed in RNA yet; trying to expose this raises the question of where it should go!
• No way to set tooltips on UI widgets created using UI Layout engine stuff. We have 2 sets of widgets in Blender, the base widgets (which are still directly used in some places), and those created by the UI Layout engine/system which are based on those base widgets. Only the UI Layout ones are exposed to Python. Unfortunately, one of the things the UI Layout API lacks is the ability to pass tooltips down the grapevine. Previously I've hacked other things into this system, but if you've seen what it takes to get icons/labels down to the bottom, it ain't pretty!
• Macro Operators pose a nasty challenge - Unlike standard operators, their "properties" are references to instances of the OperatorProperties class, within which the actual interesting properties may/may not reside. If you're not careful, even trying to extract properties out of a KeyMapItem can thus be quite a struggle.

As a result, although I do have a patch of these hacks, I'll currently refrain from posting this until I've managed to make a few further passes over it to make it less hacky, and perhaps to have resolved some more of these issues first.

In addition to these woes, I've duly noted a number of minor/low-level quirks in the keymap editor. Many others have already noted many more pressing issues with it (in terms of querying and conflict indication) which should probably get attention first/before these issues are tackled :)

• The panel expanders have an annoying 1-2px shift when in the expanded state due to the extra padding from the box outline. This however means that users cannot quickly toggle the expanded state of the item as the button is now just out of mouse-range
• The wrong types of layout techniques are used in the wrong places, resulting in too much padding being inserted around/inside widgets which don't need the extra space, while critical widgets don't expand enough
• Ideally, the settings on the LHS sidebar would be in a separate region which doesn't scroll with the rest of the content. Same goes for the addons section
• Ideally, the textbox for specifying the operator used would actually be linked to a "Path Builder" tree widget/popup (similar to what the rna_path fields for KeyingSets and Drivers should be). However, coding such a tree-region for these things within the underlying toolkit is also a non-trivial exercise. Otherwise, I'd have done this already several years ago!