Page MenuHome

Nodes: sort builtin compositor/shader/texture nodes alphabetically in menus

Authored by Brecht Van Lommel (brecht) on Apr 27 2016, 2:22 AM.



This makes the nodes sorted alphabetically both in the add menu in the node editor, and in the node link menu in the material properties. Previously in the material properties the nodes were sorted in random order.

This makes things consistent with constraints and modifier menus for example. It does break muscle memory for those used to the current order, but in my opinion alphabetical order is better. I often find myself scanning the menu up and down unable to find the right node immediately.

For some earlier discussion see here:

This does not affect custom nodes, for example from external renderers. We can't automatically sort them because addons can define arbitrary menus, with separators etc. So that choice is still left to the addons.

Diff Detail

rB Blender

Event Timeline

Brecht Van Lommel (brecht) retitled this revision from to Nodes: sort builtin compositor/shader/texture nodes alphabetically in menus.
Brecht Van Lommel (brecht) updated this object.

Great work, definitely a welcome fix and good improvement!

This revision is now accepted and ready to land.Apr 27 2016, 11:01 AM
Lukas Toenne (lukastoenne) edited edge metadata.

Nice, thanks @Brecht Van Lommel (brecht).

Muscle memory is a valid argument, but IMHO it applies mostly to shorter lists.

Jonathan Williamson (carter2422) edited edge metadata.

Yes! This is a great improvement @Brecht Van Lommel (brecht). Consistency for the win.

Julian Eisel (Severin) accepted this revision.EditedApr 27 2016, 7:19 PM
Julian Eisel (Severin) edited edge metadata.

Nice change! It's usually much easier to form muscle memory for an alphabetical list, so it will help new users and 'old' users should be able to get used to it rather quickly. I wouldn't bother with muscle memory breakage here.

From patch I get it's using case sensitive sorting, I'm wondering if it would be worth to use insensitive sorting though? For cases like "ID Mask" vs "Invert" (fictitious case, just to demonstrate where case sensitive sorting might fail to meet user expectation).

Good point about the case insensitive sorting, I've changed that.

Thanks all for the review.

This revision was automatically updated to reflect the committed changes.