Open pcdavid opened 2 years ago
This is caused by different parts of the code which are note fully compatible with multi-selection.
NodeStylePropertiesConfigurer
which only tests for the type of the first element in the selection in its canCreatePagePredicate
. If the first element is a NodeStyle, the page will be instanciated, and then its semanticElementsProvider
will be invoked for every element oin the selection, but that provider assumes every element in the selection is a NodeStyle (there used to be only one, so that was always the case if canCreatePagePredicate
had returned true
earlier. This explains the second crash above.
The first stack is unrelated to multi-selection, but caused by https://github.com/eclipse-sirius/sirius-components/issues/1033 not having created the _UI_BorderStyle_borderColor_feature
key (and probably others) when regenerating the metamodel. It is not visible in "normal" usage as NodeStylePropertiesConfigurer
does not use this to create the label for the "Border Color" attribute's widget.
However since the first element in the selection is an element from Flow, NodeStylePropertiesConfigurer
's canCreatePagePredicate
return false, which triggers the use of the default generic/reflective rules, which use EMF's item providers.
Another related issue seen while analysing this: even after fixing the invalid semanticElementsProvider
, there is an incorrect behavior when selecting first a NodeStyle and then a Flow element. Because the first selection element returns a non-empty form, the use of the default provider for the other elements in the selection where it may apply is completelyn bypassed in PropertiesEventProcessorFactory.createRepresentationEventProcessor()
:
Optional<FormDescription> optionalFormDescription = Optional.empty();
if (!formDescriptions.isEmpty()) {
optionalFormDescription = new FormDescriptionAggregator().aggregate(formDescriptions, objects, this.objectService);
}
FormDescription formDescription = optionalFormDescription.orElse(this.propertiesDefaultDescriptionProvider.getFormDescription());
Here FormDescriptionAggregator
finds at least one match (the custom page for the NodeStyle), so it does not try to apply the default rules for the other parts of the selection.
Screenshots
Steps to reproduce
Expected behavior
When selecting multiple elements I should get one page per element, each rendered using the appropriate Form implementation registered to handle that type.
Actual behavior