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.Apr 27 2016, 2:22 AM
Brecht Van Lommel (brecht) updated this object.
Brecht Van Lommel (brecht) updated this revision to Diff 6546.
Thomas Dinges (dingto) accepted this revision.

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) accepted this revision.

Nice, thanks @Brecht Van Lommel (brecht).

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

Jonathan Williamson (carter2422) accepted this revision.

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

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

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.