Input port menu in Node Editor does not respect order index

[peter_horvath]

We set the order index of the ports and they are displayed properly in the Attribute Editor, but the input port menu does not respect this and groups and ports are displayed in a "random" order, that does not match the UI and is quite confusing.

Is this a limitation or is there a flag or other attribute we have to set to match the layout of the Attribute Editor?

[ferdinand]

Hey @peter_horvath,

Thank you for reaching out to us. A little bit of code or a DataDescription dump would have went a long way here as what you do is not very clear to me. When you say that you 'set the order index of the ports', I assume that you mean that you set the maxon::nodes::ReqOrderIndex either programmatically in code or indirectly via the resource editor, right?

And you are unhappy about the alpha-numeric sorting in the context menu of the Node Editor, e.g., what is also happening in the attribute group 'Base Properties > Reflection' here for Redshift?

This context menu is effectively being built with a public function, namely maxon::DataDescriptionUIInterface::BuildPopupMenuForDescription. In its implementation, it forcibly sets maxon::DESCRIPTIONMESSAGECHECKFLAGS::SORTSUBMENU for the generated submenu; which then causes the presenter to alpha-numerically sort the entries when it is displaying them.

So, in theory, the node editor is capable of displaying the entries in their maxon::nodes::ReqOrderIndex order, it is just a feature of the Node Editor that they are alphanumerically sorted at the moment (which also strikes as the better choice for long lists). So, to give here a clear answer, no, this is not possible at the moment. But you are free to make a feature request via mail. My hunch would be that the node team will not give this the highest priority but I might be wrong.

Cheers,
Ferdinand

PS: As far as I understand the impl. of BuildPopupMenuForDescription, the same applies for DESCRIPTIONMESSAGECHECKFLAGS::VISIBLE. Ports technically can flags themselves for being invisible, but BuildPopupMenuForDescription also makes everything forcibly visible. But Maxime owns that other subject, maybe he finds out more.

[peter_horvath]

Hi Ferdinand,

Thank you for your reply. Sorry for not being completely clear. Yes, I meant maxon::nodes::ReqOrderIndex. I feel like it would be more natural if the input menu would match the order in the Attribute Editor, instead of listing the items in alphabetical order. Being able to control the behavior via the API could be welcome. I'll make a feature request, just in case. What's the best option to file an API request? Should I use the form in support.maxon.net or the contact form here?

Thanks,
Peter

[ferdinand]

Hey Peter,

you can reach out directly to us via mail. While there is some end-user aspect in this, I think it is best handled by SDK. But thanks for asking and caring about submitting to the right place! I will forward your mail/request to the right places. But as hinted at above, I do not see the Node team being all thrilled about this.

Maybe also make the case why this is needed as making the case for something usually increases your chances compared to a "I want X"! Maybe also line out how you envision for this to work. E.g., request to introduce an attribute which can be set on port bundles. As for example maxon::DESCRIPTION::UI:NOSORT which is then respected by BuildPopupMenuForDescription.

What we very likely will not do, is that we completely turn this off, as both Scene Nodes and Redshift have a lot of data types with many sub ports where it will be hard to find things without alpha-numerical sorting. I could be wrong about all this as I am neither in the Nodes nor Redshift team, but that is the hunch I have when I look at this system.

Cheers,
Ferdinand