Hi Lars,
PerspectiveDescriptors seems to be a good idea.. If a fragment has to declare a new perspective today it must add it in the PerspectiveStack, and this object may not exist in the host application model since perspectives are optional. With a specific Perspective descriptors it would be easier. Sure.
Now if we tend to have one E3 extension point described in a ‘xxxDescriptor’ in the application model we could take advantage of this evolution to include, at the same time, all the missing concepts like preference pages, property pages, wizards … Having a Wizard [descriptors] node reflecting wizard extension point would be really cool.
More generally, I think it is really the moment to have a big discussion on what is missing in the model and when/who could add it !
Olivier
PS : sorry for the previous answer that was not in the scope of this thread (actually I didn’t imagine that it could produce so many answers :))…
Hello,
In the current runtime application model of the IDE, we create perspectives based on the perspectives which were opened by the user or as default perspective.
I think the current model makes it difficult to migrate the existing extension point based definition of perspectives to the application model.
We could use model snippets (for perspectives) to model this, but I think we should go for the same route as for ViewDescriptors or Toolbar and Menu contributions.
ViewDescriptors can be defined as model fragments. In the case of the IDE they are calculated based on the extension points and added to the runtime model. This allows to use this model information at runtime, as I plan for example in Bug 430988.
Should we add a similar model element for perspectives, i.e., PerspectiveDescriptors?
Best regards, Lars
_______________________________________________ e4-dev mailing list e4-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/e4-dev
|