|
Q1
|
The application model is stored in the e4xmi file, and provides a way of representing the entire state of the application's UI. It is also persisted on save and then reloaded at startup, so positions of parts and their visibility is persisted. The model is also accessible at runtime via the various M classes such as MApplication and MPart, and can be queried and mutated at runtime.
|
|
Q2
|
Parts are a more generic form of views and editors. Unlike Eclipse 3.x, not everything needs to fit into a View or Editor category; they are all just Parts which contain UI components underneath, and can be organized appropriately.
|
|
Q3
|
Although extension points aren't used for things like commands, keybindings, or views, they are still used to define other extensions to Eclipse such as builders, marker types, and language parsers. The only thing that the Eclipse 4 model moves out of the extension points are the UI-related concepts. Even then, in the Eclipse 4 IDE the backward compatibility mode ensures that all the UI-related extension points are still rendered. For developing IDE plugins, the Eclipse 3.x APIs are likely to be around for the next couple of Eclipse releases.
|
|
Q4
|
The Eclipse 4 parts can be styled with CSS, and the underlying renderer applies the styles on the fly, including if the CSS styles change. This allows theme managers to apply different color combinations in Eclipse 4 in ways which are not possible in Eclipse 3.
|
|
Q5
|
The Eclipse 4 contexts are essentially a series of HashMaps that contain values (objects) associated with keys. Parts can dynamically obtain content from their context, which include all of the injectable services as well as dynamically changing content such as the current selection. A context is implicit in every Part, and inherits up the containment chain, terminating with the OSGi runtime.
|
|
Q6
|
There are several annotations used by Eclipse 4, including:
@Inject (used to provide a general "insert-value-here" instruction to Eclipse)@Optional (meaning it can be null)@Named (to pull out a specific named value from the context)@PostConstruct (called just after the object is created)@PreDestroy (called just before the object is destroyed)@Preference (to pull out a specific preference value or the preference store)@EventTopic and @UIEventTopic (for receiving events via the event admin service and on the UI thread respectively)@Persist and @PersistState (for saving data and viewing data)@Execute and @CanExecute (for showing what method to execute, and a boolean conditional which has a boolean return to indicate if it can run)@Creatable (to indicate that the object can be instantiated)@GroupUpdate (to indicate that updates can be deferred).
|
|
Q7
|
Preferences are accessed with the @Preference annotation which can inject a value into a field. If updates are needed it should be set as a method parameter, which will be called when the preference value is changed.
|
|
Q8
|
Messages are sent via the EventBroker, which is accessible from the injection context. This can have sendEvent() or postEvent() to send data. On the receiving side, using the @UIEventTopic or @EventTopic annotations is the easiest way to receive values. As with preferences, if it's set up as a method parameter then the changes will be notified.
|
|
Q9
|
Selection can be accessed using the value from the context with a method injection or value injection using @Named(IServiceConstants.ACTIVE_SELECTION).
|
