Crtl N and INamedConcept


just struggling with some MPS internals. Basically, i really like the CRTL-N (find root node by name) feature. Obviously, it lets you search all Root-Concepts in MPS implementing INamedConcept. 

Now in my case, i have a IOptionallyNamedConept, which consists of (string) name and (boolean) isNamed. I'm using that interface in my language to let the developer choose if he wants to name a specific concept or not. Of course, CRTL-N does no longer work. The IOptionallyNamed Root-Concepts are not listed in the search menu.


Now there are two options to fix this... 

(1) Is there any way to make the IOptionallyNamedConcept appear in the CRTL-N menu? ..

(2) Should IOptionallyNamedConcept extend INamedConcept, which might result in having many nodes loaded in MPS which are INamedConcepts but with an empty name. Does that do any harm in other sub menues or search functionalities? Of course, root concepts need a name due to there appearance in the logical view ... 


Is there a preferable solution to this problem?


Any help appreciated,



It looks like you can register you own NavigationParticipant using PersistenceRegistry.addNavigationParticipant to add additional nodes to that menu.


Hi Sascha,

thanks for your response. I already had a look at the NavigationParticipant and the PersistenceRegistry. 

By coincident i found out, that the Root Nodes are already present in the CRTL-N Menu, labeled as "null". Thus, i created a lang from scratch with just one concept, extending BaseConcept but not implementing INamedConcept. However, i overwrote getPresentation() and getDetailPresentation() in the behaviour Aspekt.


And then again, via CRTL-N  there is a Root-Node labeled "null" present. Obviously, the default MPS NavigationParticipant takes Root-Nodes into account. The SNode implementation then returns null ...

public String getName() {

if (getConcept().isSubConceptOf(SNodeUtil.concept_INamedConcept)) {
return SNodeAccessUtil.getProperty(this, SNodeUtil.property_INamedConcept_name);
} else {
myOwner.fireNodeRead(this, false);
return null;



So guess, there is no way to come around this behaviour easily. Seams that one has to implement the INameConcept ... 



Please sign in to leave a comment.