Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "E4/UI/Toolkit Model"

< E4‎ | UI
(New page: =The Toolkit Model= The Toolkit Model is an EMF model of the user interface (UI) components (aka. widgets) found in toolkits like Swing and SWT. The model includes concepts like Composite,...)
 
(The plugins)
 
(3 intermediate revisions by one other user not shown)
Line 18: Line 18:
 
== The plugins==
 
== The plugins==
  
There are currently three main plugins in the TM feature
+
There are currently three main plugins in the TM feature:
* '''org.eclipse.e4.tm''' provides the model itself with support for most simple widgets, but not complex ones like trees and tables
+
* [[E4/UI/Toolkit_Model/org.eclipse.e4.tm]] provides the model itself with support for most simple widgets, but not complex ones like trees and tables
* '''org.eclipse.e4.tm.builder''' provides a builder for SWT, so the model may be bound to a concrete SWT UI
+
* [[E4/UI/Toolkit_Model/org.eclipse.e4.tm.builder]] provides a builder for SWT, so the model may be bound to a concrete SWT UI
* '''org.eclipse.e4.tm.ui''' provides a view for previewing TM instances and an editor (very in-progress) for building applications based on EMF, TM and Javascript
+
* [[E4/UI/Toolkit_Model/org.eclipse.e4.tm.ui]] provides an editor (very in-progress) for building applications based on EMF, TM and Javascript and supporting views, including views for previewing TM instances and editing Javascript source.
  
The Javascript support is provided by the '''org.eclipse.e4.emf.javascript''' plugin (available separately). In short, it makes EMF objects look like native Javascript objects, so both EMF-based data and UIs (since TM is EMF-based) can be scripted.
+
The Javascript support is provided by the [[E4/UI/Toolkit_Model/org.eclipse.e4.emf.javascript]] plugin. In short, it makes EMF objects look like native Javascript objects, so both EMF-based data and UIs (since TM is EMF-based) can be scripted.
 +
 
 +
The [[E4/UI/Toolkit_Model/org.eclipse.e4.tm.examples | examples plugin]] provides sample models that may be a good starting point for your own models.

Latest revision as of 12:52, 2 June 2009

The Toolkit Model

The Toolkit Model is an EMF model of the user interface (UI) components (aka. widgets) found in toolkits like Swing and SWT. The model includes concepts like Composite, TabFolder, Text, Layout etc. that define the structure and content of a user interface. An instance of the Toolkit Model (henceforth shortened to TM) represents all or part of a specific UI, like an application window or form, but is not itself a runnable/running UI. Instead, a concrete UI in a specific toolkit is built and bound to the TM instance, to create a running user interface. By bound, we mean that the two representations, the TM instance and the concrete UI (widgets), are kept in sync, so changes to one are propagated into the other. There may be limitations to this synchronization, so the typical setup is:

  • The application manipulates the TM instance to change the concrete UI, e.g. set the "text" EAttribute of a Text EObject instead of calling the setText method of the underlying Text widget. This should work for arbitrary changes, like moving widgets around in the hierarchy and changing widget behavior, look & feel and layout.
  • The application reacts to user interaction by listening to changes to TM instances, e.g. when the user edits the text in a Text widget, the "text" EAttribute of the corresponding Text EObject is updated and a normal EMF Notification is delivered. Usually you will listen to changes to value-oriented attributes, like text value or selection. In addition, events are represented as transient attributes holding toolkit-specific values.
  • Each TM widget instance may have references to application data, and by using EMF's Javascript support, changes to these references may trigger UI changes.

There are several advantages to this setup:

  • The Toolkit Model is a (slight abstraction) of the underlying toolkit, and may hence be conceptually simpler and easier to work with.
  • EMF provides a simple set of concepts and a uniform object structure for the UI, that hides the technical details of the underlying toolkit.
  • The reduced coupling that binding gives, makes it easier to support different architectures where the concrete UI runs in a different process on a different machine on the network, e.g. a thin client or web browser.
  • An application designed with EMF will be easy to bind to an EMF-based UI. EMF instances representing the application data and UI state can be saved and loaded together and used as session data.
  • Although the TM instance may be build by hand using EMF tools, it may also be the result of a model-driven engineering process. E.g. the UI may be generated from a prototyping tool or a domain model with styling templates.

There are also disadvantages, particularly:

  • The model introduces a set of intermediary objects, and hence is more bloated than having only the underlying toolkit's widgets.
  • You may be unfamiliar with EMF or it may be considered inappropriate for UI programming.

The plugins

There are currently three main plugins in the TM feature:

The Javascript support is provided by the E4/UI/Toolkit_Model/org.eclipse.e4.emf.javascript plugin. In short, it makes EMF objects look like native Javascript objects, so both EMF-based data and UIs (since TM is EMF-based) can be scripted.

The examples plugin provides sample models that may be a good starting point for your own models.

Back to the top