ITU - MDD - Eclipse Plug-ins


Published on

This presentation shows how Eclipse plug-ins are developed. It has two purposes:
Introduce you to the architecture and techniques of a major component based application
Introduce you to basic Eclipse plug-in development – this will hopefully ease the needed programming in the rest of the course

This presentation is developed for MDD 2010 course at ITU, Denmark.

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • The basic goals for the Eclipse architecture means – among other things – that the complete platform must be equally accessible for all parties. So all parts of the basic platform must be
    Free of charge
    Fully documented
    No licensing attached to any of the software apart from the basic EPL – Eclipse Public License
    The basic unit of functionality in Eclipse is the plug-in. A single plug-in can encompass a complete application, but it can also be a functional independent part of an application.
    The interfaces between plug-ins is defined via extension points  Extension points are well-defined places in the system where other plug-ins can contribute functionality.
    Each major subsystem in Eclipse IDE and Eclipse RCP is itself structured as a set of plug-ins that implement some key function and define extension points.  The Eclipse system itself is built by contributing to the same extension points that third party plug-in providers can use.  Plug-ins can define their own extension points or simply add extensions to the extension points of other plug-ins.
    Note that the concepts of plug-ins and extension points runs very deep in the Eclipse platform: even the very basic parts of the platform are organized as plug-ins with extension points. The only Eclipse RCP plug-in that does not provide or use extensions is SWT.
  • Eclipse products are built in layers.
    At the bottom there are Eclipse RCP with the bare necessities. The RCP subsystems typically add visible features to the platform and provide APIs for extending their functionality. Some of these components supply additional class libraries that do not directly relate to an extension point, but can be used to implement extensions. For example, the workbench UI supplies the JFace UI framework and the SWT widget toolkit.
    The platform layer adds the generic features needed for an Integrated Development Environment (IDE).
    The different language support sits on top of the platform. The basic IDE features (known under the misleading name Eclipse SDK) includes two major tools that are useful for plug-in development. The Java development tooling (JDT) implements a full featured Java development environment. The Plug-in Developer Environment (PDE) adds specialized tools that streamline the development of plug-ins and extensions.
    Likewise for the many features of Calisto, Europa and now Ganymede. They are also layered to provide a set of basic features that are used by other features to provide better and more specialized tools.
    The Resources, Workspace and Update components shown above is not really part of the very basic RCP component set. They are used very often in RCP applications.
  • The platform run-time core implements the run-time engine that starts the platform base and dynamically discovers plug-ins. A plug-in is a structured component that describes itself to the system using a manifest (plugin.xml) file. The platform maintains a registry of installed plug-ins and the functions they provide.
    Functionality is added to the system using a common extension model. Extension points are well-defined function points in the system that can be extended by plug-ins. When a plug-in contributes an implementation for an extension point, we say that it adds an extension to the platform. Plug-ins can define their own extension points, so that other plug-ins can integrate tightly with them.
    The extension mechanisms are the only means of adding function to the platform and other plug-ins. All plug-ins use the same mechanisms.  Plug-ins provided with the Eclipse SDK do not use any private mechanisms in their implementation.
    Extensions are typically written in Java using the platform APIs. However, some extension points accommodate extensions provided as platform executables, ActiveX components, or developed in scripting languages. In general, only a subset of the full platform function is available to non-Java extensions.
    A general goal of the run-time is that the end user should not pay a memory or performance penalty for plug-ins that are installed, but not used. A plug-in can be installed and added to the registry, but the plug-in will not be activated unless a function provided by the plug-in has been requested according to the user's activity.
  • Using Eclipse RCP in an application is typically done the very same way as when used in Eclipse IDE.
    At the bottom there are Eclipse RCP with the bare necessities.
    The platform layer adds the generic features needed for any application in the specific environment.
    The application itself is then placed at the top.
  • The terms listed above are central to an Eclipse system and it is rather important to understand them in order to implement a big Eclipse application.
  • There are two parallel JSR projects which both looks at OSGi, but with totally different results!
    JSR 291, “Dynamic Component Support for Java SE”, aims to use OSGi directly in standard Java SE
    JSR 277, “Java Module System”, aims to implement a completely new module system. In this case “OSGi is not good enough”.
  • The term Workbench refers to the desktop development environment. The Workbench aims to achieve seamless tool integration and controlled openness by providing a common paradigm for the creation, management, and navigation of Workbench resources.
    Each Workbench window contains one or more perspectives.  Perspectives contain views and editors and control what appears in certain menus and tool bars.  More than one Workbench window can exist on the desktop at any given time.
  • Something about the development model used in the Eclipse IDE development…
    …and why this match the requirements of a multi-national bank. (Nordea has development groups in multiple locations and also like to keep the option for outsourcing open)
  • The information model of the Eclipse workbench consists of a number of entities. These all have a UI representation expect for Workbench and Perspective.
    The information model is relative simple:
    A workbench consists of one or more workbench windows.
    Each workbench window has a top-level menu, a tool bar, a status line and a perspective switcher.
    Each workbench window has exactly workbench page.
    Each workbench page has one or more perspectives.
    Each workbench page handles any number of editors and views.
    Each perspective provides a specific view of the editors and views of the page.
    Each view also has a view-local menu and tool bar.
    Most applications only have one window.
    Most UI resources in the application is handled on a per-window basis, which can be very important if the windows are shown on different monitors, in which case the low-level resources such as fonts and images must be handled specially.
    Please note that the Resource API provides a view of the workspace of the user and this view is common to all workbench windows.
    All editors and views are shared between all perspectives of a workbench window.
  • Now it’s time for the lab.
  • A fragment is recognized in the MANIFEST.MF file by the presence of the Fragment-Host specification.
  • Most of these files can exist both in a jar based plug-in (a plug-in packaged as a single .jar file) and in a directory based plug-in. As long as the files from a plug-in are accessed using FileLocator.find(Bundle, IPath, Map) this is completely transparent.
    More information:
    See the module “L0054 - Localization of an Eclipse RCP Application” for information on exactly what can be localized
  • The declaration files for extension points are based on a restricted form of XSD (as also implied by the extension).
  • The complete syntax for the manifest fest is found in “OSGi Specifications”. The Eclipse specific headers are described in “OSGi Bundle Manifest Headers”.
  • The  PDE has a number of multi-page editors, including the plug-in manifest editor, that share the same basic behavior. The editor has one or more source pages that show the raw file content and one or more form pages that present the same information in a more structured format. 
    The plug-in manifest editor partitions the form information into several pages for less clutter. The best way to learn about the plug-in manifest editor is to visit each page.
  • The Dependencies page shows the dependencies that your plug-in has on other plug-ins.  The plug-ins your plug-in currently depends on are shown in the list. You can modify the list by adding more plug-ins (button Add...) or removing them from the list. Changes in this list will prompt PDE to update the plug-in manifest and also configure the build path of the project so that the classes of the imported plug-in are visible to the plug-in under development.
    Once you add the plug-in reference to the list, you can browse it by selecting Open from the pop-up menu or double-clicking on the entry.
    Use the “Automated Management of Dependencies” sub-page to add all the possible plug-in dependencies to your project:
    Content assist will include all Java classes from these classes as well as all classes from required plug-ins
    The required plug-ins will automatically be updated
  • The Runtime page describes which Java packages of the plug-in that is exported to other dependent plug-ins. Only the listed packages can be used by other plug-ins.
    There are a special case: it is possible to make certain packages visible only to a limited set of other plug-ins (“Package Visibility”). This feature can be used between very closely coupled plug-ins to allow a greater visibility than normally. One such case is for test suites, there the test code is kept in a separate plug-in – to avoid getting it into the production system – but it often needs an more enhanced interface in order to test many features. Note though that fragments are a better solution in this case.
  • The Extensions page is used to browse and edit plug-in extensions. Extensions are the central mechanism for contributing behavior to the platform. Unless your plug-in is a simple Java API library made available to other plug-ins, new behavior is contributed as an extension.
  • The Extension points page is used to browse and edit extension points defined by the plug-in. Our plug-in's extension points can be used by the plug-in itself or another plug-in.
    Please note that the name of the extension point is localized – the text is found in with the key ExtPoint.acceleratorConfigurations.
    The XML file that describes the complete extension point is found as the file schema/acceleratorConfigurations.exsd. More about this in the module “L0015 - Making Extension Points”.
    To see more about the different plug-ins that make up the Eclipse IDE, browse the “Plug-ins” view of the PDE perspective.
  • The Build page shows information about the generated runtime libraries. When packaged, platform plug-ins deliver all of their Java classes in JAR libraries. This page defines how the classes that are in source folders during the design time are packaged into the libraries. One source folder and one library have already been set during the project creation by the wizard. You can define more on this page.
    Although a plug-in can be divided into multiple .jar files, this should normally be avoided as it means the plug-in must be distributed as a directory instead of a .jar file.
    The source build side of the tab is only relevant if you wish to distribute source plug-ins either to the public (not so likely) or to other parts of you company that might build on top of your work.
  • The look-n-feel of the native widgets and SWT is governed by the native look-n-feel guide. Eclipse adds some further rules on top of these in the form of “Eclipse User Interface Guidelines”.
    The look-n-feel of an RCP application can be changed; this is described in the module “L0019 - Changing the Look-n-Feel”.
  • The Standard Widget Toolkit (SWT) is a Java class library that allows you to create native user interfaces. It's designed to provide efficient, portable access to the underlying facilities of the operating system on which it's implemented. SWT uses native widgets wherever possible, giving an SWT program a native look and feel and a high level of integration with the desktop. In addition, SWT includes a rich set of controls such as tree, table, and tab folder
    The SWT library actually exists in a number of editions – one for each target platform. In Eclipse there are a single generic SWT plug-in with very little functionality and a SWT fragment for each of the target platforms. The version of the SWT fragment that is part of the Eclipse IDE or RCP download, is one of the major differences between the different platforms.
    The Eclipse platform fully supports development of SWT stand-alone applications.
  • SWT is just a thin layer on top of the native widgets. This is illustrated on this slide, where the same tiny SWT based application has been run on a number of platforms. As can be seen, the look-n-feel of the application follows the native look-n-feel exactly.
  • Sleak is a simple tool that monitors the creation and disposing of SWT graphics resources. See here for more information:
    Please the article “Swing/SWT Integration” for a description of how to integrate SWT and Swing.
  • There are quite a few alternative SWT widgets on the net – especially on Sourceforge.
  • Images taken from the SWT homepage.
  • The style arguments that are allowed for different widgets, varies greatly. Also the meaning differs somewhat between widgets. For a complete description of the exact meaning of the different style arguments, the javadoc is not enough – instead refer to SWT Bible “The Definitive Guide to SWT and JFace” by Robert Harris and Rob Warner.
  • The Swing layout manager GridBagLayout is very similar to SWTs GridLayout, as is Swings SpringLayout with SWTs FormLayout.
    Eclipse IDE includes more than 50 special case layouts – e.g. for tab folders and the perspective switcher of the workbench window.
    If you forget to add a layout manager to a Composite (or children) then the children will very likely not be shown at all as they will all have zero size!
  • The generic light-weight Listener interface is primary used for low-level events such as MouseMove, whereas the type-safe version is used for just about everything else.
  • Now it’s time for the lab.
    The extra lab exercise with the form with multiple labels is taken from a puzzle by Eugene Kuleshov – see
  • ITU - MDD - Eclipse Plug-ins

    1. 1. L0079 - 2009-08-27 Redistribution and other use of this material requires written permission from The RCP Company. ITU - MDD - Eclipse Plug-ins This presentation shows how Eclipse plug-ins are developed. It has two purposes: Introduce you to the architecture and techniques of a major component based application Introduce you to basic Eclipse plug-in development – this will hopefully ease the needed programming in the rest of the course This presentation is developed for MDD 2010 course at ITU, Denmark.
    2. 2. L0079 - 2009-08-27 2 Equipment and Groups  Today's lecture will include a bit of Java development!  So…  You need your laptop  You need the following installed and tested – please – on your laptop  Eclipse 3.6 Modelling Edition  Java SDK 6  You need to be in a group of people (3-4) with some knowledge of  Eclipse IDE as a development platform  Java development  User interface development – if possible
    3. 3. L0079 - 2009-08-27 3 Agenda  Eclipse Architecture  The basic plug-in  What is a plug-in?  Standard Widget Toolkit – SWT
    4. 4. L0079 - 2009-08-27 4 Agenda  Eclipse Architecture  What are the drivers for the Eclipse architecture  What are the requirements for the architecture
    5. 5. L0079 - 2009-08-27 5 Some Numbers on Eclipse  The Eclipse Modeling Tools  1099 plug-ins  229 features  All Eclipse Projects  >45 projects in the Galileo release train  29 MLoC  >500 active committers  >25 countries  >140 locations
    6. 6. L0079 - 2009-08-27 6 Project Activity
    7. 7. L0079 - 2009-08-27 7 So…  We need an architecture that supports distributed development over a large number of autonomous development groups  We need a component concept where components are loosely coupled and can be started (and stopped) independently  We need a way to describe external interfaces of components and dependencies between components  We need a way to only start the components as they are needed – also known as late activation  We need all this to work over multiple generations of components
    8. 8. L0001 - 2008-11-27 8 Eclipse Architecture  Goals for the Eclipse architecture  Be able to host any number of 3rd party applications  Scalability in terms of size and complexity of hosted applications  Alignment with native UI look-n-feel  Flexible architecture, structured around  Plug-ins – the basic unit of functionality  Extension points – the defined interfaces between plug-ins  This architecture allows for  Implementation of 3rd party applications on top of the basic platform (Eclipse RCP)  Additional tools to be integrated in the platform  Integrated tools to be further extended
    9. 9. L0001 - 2008-11-27 9 Eclipse Platform Resources Workspace Help Update Team WebServer Filesystems Apache Search Navigator Intro TextEditors Eclipse Architectural Components JDT CVS WTP Datatools VE BIRT Mylyn PDE Eclipse RCP Run-time/OSGi SWT JFace Workbench Preferences Jobs ICU Commands Registry CDT
    10. 10. L0001 - 2008-11-27 10 The Basic RCP Components  In the Eclipse, everything is a plug-in including the run-time platform itself  It is a small kernel that represents the base of the platform  Built on top of OSGi  All subsystems built on the run-time platform follows the rules of plug-ins:  They are plug-ins themselves  RCP includes:  Component Management  Resources Management  Preferences  Workbench (include SWT and JFace)  RCP does not include functionality that are not commonly needed:  Update  Help  This can be included from the Eclipse platform Eclipse RCP Run-time/OSGi SWT JFace Workbench Preferences Jobs ICU Commands Registry
    11. 11. L0001 - 2008-11-27 11 Application Platform Comm. Logging Help Update Auth. Auditing Apache Intro Your Typical RCP Application Base Add-on Add-on Add-on Add-on DebugTools DataModel Eclipse RCP Run-time/OSGi SWT JFace Workbench Preferences Jobs ICU Commands Registry Add-on
    12. 12. L0001 - 2008-11-27 12 Organizing the Platform  The software of an Eclipse system is based on the following terms:  Plug-ins – a plug-in is the basic unit of software  Fragments – a fragment is an add-on to an existing plug-in with additional functionality  Features – a feature is a number of plug-ins that is distributed and updated as a whole  Applications – an application is a Java class that implements a specific interface and is declared as such in the plug-in  Products – a product is a set of features or plug-ins along with the appropriate branding
    13. 13. L0001 - 2008-11-27 13 Extension Points  Describe additional functionality that could be integrated with the platform  External tools extend the platform to bring specific functionality  Java Development Tooling (JDT) and Plug-in Development Environment (PDE) are external tools integrated with the platform  Extension points are used to  Add an implementation for a generic feature  Extend the workbench  Extend common object factory  Advantages:  Allows for late load and startup of plug-ins  Provides a common “registry” for most extensions like views, perspectives, commands, etc  Disadvantages:  Makes it harder to understand flow of control  ID Hell!  Extension points may have corresponding API interface  Describes what should be provided in the extension
    14. 14. L0001 - 2008-11-27 14 Eclipse RCP Run-time/OSGi SWT JFace Workbench Preferences Jobs ICU Commands Registry The Role of Run-Time/OSGi  Dynamic module system for Java  Solves many of the problems of big applications  Late activation of code  Multiple versions of the same library  Eclipse is the reference implementation!
    15. 15. L0001 - 2008-11-27 15 Eclipse RCP Run-time/OSGi SWT JFace Workbench Preferences Jobs ICU Commands Registry Workbench  Represents the desktop development environment  It contains set of tools for resource management  It provides common way of navigating through the resources  Multiple workbenches can be opened at the same time in individual windows
    16. 16. PR0005 - 2008-04-10 16 Eclipse Development Model  Yearly releases  Always released around 27. June – just before the start of the Canadian holidays  Many diverse and highly independent development teams  More than 25 countries involved in Eclipse 3.5 Galileo  Many milestones and release candidates  5 monthly milestones (August to February)  4 release candidates (May and early June)  Still room for integration of other mayor projects  Many projects are released with other release schedules
    17. 17. L0079 - 2009-08-27 17 Agenda  The Basic Plug-In  How to build a basic Eclipse plug-in and get it included in Eclipse IDE
    18. 18. L0079 - 2009-08-27 18 Show and Tell  You will be shown how to create a new plug-in with  A new perspective  A new view  A new command for the view  The new plug-in will be included in Eclipse  If you need to do this again, have a look at the two tutorials listed in the last slides
    19. 19. L0036 - 2008-11-23 19 Basic Eclipse UI Information Model Workbench Window Workbench Page Editors Views PerspectiveTop-level menu Top-level toolbar Status line Perspective switcher Drop-down menuLocal toolbar Workbench 0..n 1..n 0..n0..n
    20. 20. L0039 - 2009-08-27 20 Lab Exercise  Create 4 views altogether  Add the views to the perspective The way to position views in a perspective have not be discussed in details, but…  Add the Help About command to one of the views→
    21. 21. L0079 - 2009-08-27 21 Agenda  What is a plug-in?  What makes up a plug-in? How are they managed and developed?
    22. 22. L0016 - 2008-11-10 22 What is an Eclipse Plug-in  A plug-in is the smallest functionality that is managed in the Eclipse platform  Plug-ins are described via a number of configuration files  Plug-ins have different forms under development and runtime  Plug-ins are sometimes deployed individually  If you need update support, plug-ins must always be deployed as parts of a feature  A fragment has the same structure as a plug-in with very few changes
    23. 23. L0016 - 2008-11-10 23 Runtime Files of a Plug-in  OSGi files  META-INF/MANIFEST.MF – description of OSGi bundle  .options – options for this specific plug-in  General plug-in files  plugin.xml and fragment.xml – description of extension points and extensions of a plug-in  and – localized strings for the previous files
    24. 24. L0016 - 2008-11-10 24 Development Time Files of a Plug-in  .project – basic description of Eclipse project  .classpath – the Java class path for a Java Eclipse project (and thus also a PDE project)  .settings – preference store for project level preferences – includes all property settings for the project  *.product – product declaration files  – build information for Ant with content of the resulting jar files for the project  *.exsd – extension point declaration files
    25. 25. L0016 - 2008-11-10 25 MANIFEST.MF File  The OSGi manifest file describes the identify of the plug-in and the dependencies on other plug-ins  Manifest files are very seldom edited directly! Manifest-Version: 1.0 Bundle-ManifestVersion: 2 Bundle-Name: %pluginName Bundle-SymbolicName:; singleton:=true Bundle-Version: 2.1.0 Bundle-ClassPath: . Bundle-Vendor: %providerName Bundle-Localization: plugin Bundle-RequiredExecutionEnvironment: J2SE-1.5 Export-Package:, Require-Bundle: org.eclipse.core.runtime, org.eclipse.emf.ecore;visibility:=reexport Bundle-ActivationPolicy: lazy
    26. 26. L0016 - 2008-11-10 26 plugin.xml File  plugin.xml describes extension points and extensions <extension point="org.eclipse.ui.commands"> <command id="com.rcpcompany.demo.menu33.commands.HelloWorld" name=”&amp;Sample Action” /> </extension> <extension point="org.eclipse.ui.commandImages"> <image commandId="com.rcpcompany.demo.menu33.commands.HelloWorld" icon="icons/sample.gif” /> </extension> <extension point="org.eclipse.ui.handlers"> <handler class="demo.actions.SampleHandler" commandId="com.rcpcompany.demo.menu33.commands.HelloWorld” /> </extension> <extension point="org.eclipse.ui.menus"> <menuContribution locationURI=""> <menu id="sampleMenu" label="Sample Menu" mnemonic="M"> <command commandId="com.rcpcompany.demo.menu33.commands.HelloWorld" id="” /> </menu> </menuContribution> </extension>
    27. 27. L0016 - 2008-11-10 27 Plug-in Editor  Double-click on the plugin.xml or MANIFEST.MF opens the editor  Almost all plug-in details can be changed in the editor  Overview page displays basic plug-in information
    28. 28. L0016 - 2008-11-10 28 Dependencies Page  Displays dependant plug-ins  Created by tools when the plug-in type is chosen  New dependences can be added
    29. 29. L0016 - 2008-11-10 29 Runtime Page  Displays runtime information such as plug-in classpath  Populated by the tools based on inputs from wizards  Additional libraries can be added to the classpath
    30. 30. L0016 - 2008-11-10 30 Extensions Page  Displays plug-in extensions  Created by the tool based on the plug-in type  Extensions can be added
    31. 31. L0016 - 2008-11-10 31 Extension Points Page  Displays plug-in extension points  This example is taken from the org.eclipse.ui plug-in
    32. 32. L0016 - 2008-11-10 32 Build and Pages  Interface to the file  specifies which .jar files to generate  Also describes which non-Java files that are part of the generated .jar file
    33. 33. L0079 - 2009-08-27 33 Agenda  The Standard Widget Toolkit - SWT  How to develop the UI parts of an Eclipse
    34. 34. L0079 - 2009-08-27 34 Eclipse User Interface Layers  4 Layers:  The Eclipse Workbench  Overall look-n-feel  JFace  Architecture-independent models  SWT  Platform independent API yet rather close to the metal  Native widgets  Platform dependent: Windows, Linux, Mac, Unix  The “Eclipse User Interface Guidelines” governs the look-n-feel of the workbench and JFace  Consequently (nearly) all Eclipse RCP based applications look the same!  Use the SWT Bible “The Definitive Guide to SWT and JFace” by Robert Harris and Rob Warner Eclipse RCP Run-time/OSGi SWT JFace Workbench Preferences Jobs ICU Commands Registry
    35. 35. L0079 - 2009-08-27 35 SWT and the Native Widgets  SWT is short for ”The Standard Widget Toolkit”  SWT is a sub-project of the Eclipse project  SWT has a common API on all target platforms – the implementation is different  Base plug-in org.eclipse.swt contains only MANIFEST.MF plus some configuration files  A set of platform specific fragments implements all of SWT – org.eclipse.swt.win32.win32.x86 for 32-bit Windows on x86 (not Vista look-n-feel)  SWT is a thin layer on top of the native widgets  Windows  Mac  Motif  GTK  SWT can easily be used stand-alone
    36. 36. L0079 - 2009-08-27 36 SWT on Different Platforms
    37. 37. PR0000 - Using Eclipse RCP in your Organization - 2007-09-0 37 Extended Branding Here IBM Lotus Notes version 8
    38. 38. L0079 - 2009-08-27 38 Working with SWT  SWT API is not as regular as Swing  The SWT site contains a large repository of “SWT Snippets” that demonstrates most of the abilities of SWT  To find leaks with graphical resources use sleak  It is possible to integrate SWT and Swing to a very large degree  Though expect problems with shortcuts and focus management
    39. 39. L0079 - 2009-08-27 39 SWT Widgets  Basic  Button, Combo, Composite, Group, Label, Link, List, Menu, ProgressBar, Shell, Slider, Scale, Spinner, TabFolder, Table, Text, ToolBar, and Tree  Advanced  Browser, Canvas, CBanner, CCombo, CLabel, CoolBar, CTabFolder, DateTime, ExpandBar, GLCanvas, Sash, SashForm, ScrolledComposite, StyledText, SWT_AWT, TableCursor, and Tray  Other Sources – e.g. Nebula,  FormattedText, Gallery, Grid, and many more  The C... versions of Label, Combo and TabFolder are emulated and should normally be avoided if possible
    40. 40. L0079 - 2009-08-27 40 SWT Widgets
    41. 41. L0079 - 2009-08-27 41 The Basic Widget Hierarchy Widget Control Menu Item Button Label Composite List MenuItem TableItem TabItem Canvas Combo Form OleSiteClient Table, …
    42. 42. L0079 - 2009-08-27 42 Using SWT Widgets  Common constructor form – e.g. new Text(parent, SWT.PASSWORD)  The parent  The style argument specifies the basic sub-function of the widget  Use Text controls for data values event when read-only, as this makes it possible to select and copy the value
    43. 43. L0079 - 2009-08-27 43 Using SWT Styles  Second argument of all widget constructions – e.g. new Text(parent, SWT.PASSWORD)  The most use styles are  SWT.NONE – no style needed  SWT.LEAD, SWT.CENTER, and SWT.TRAIL - the alignment of text in labels, menus and buttons  SWT.ARROW, SWT.CHECK, SWT.PUSH, SWT.RADIO, and SWT.TOGGLE - the sub-type of a button  SWT.PASSWORD - Text is used for password entry  SWT.V_SCROLL, SWT.H_SCROLL, and SWT.NO_SCROLL – Table or Tree has vertical, horizontal or no scroll bar (3.4)  Some special considerations regarding styles  Some style arguments cannot be changed once specified in the constructor (e.g. SWT.CHECK for a Button), whereas others can (e.g. SWT.LEAD for Label)  Some style arguments have different meaning for different widgets –e.g. SWT.MULTI for Table and Text
    44. 44. L0079 - 2009-08-27 44 SWT Layout Managers  The positioning and sizing of controls in a Composite (and subclasses) is performed using layout managers  SWT includes a rather complete set of standard layout managers  FillLayout and RowLayout: layout is a single row or column  GridLayout: layout in a grid with size constrains  FormLayout: layout in canvas with size and edge-to-edge constrains  Most GUI designer can handle these  A new layout manager can be created fairly easily created  computeSize: computes the “natural” size of the Composite  layout: lays out the controls of the Composite public abstract class Layout { protected abstract Point computeSize(Composite composite, int wHint, int hHint, boolean flushCache); protected abstract void layout(Composite composite, boolean flushCache); }
    45. 45. L0079 - 2009-08-27 45 Using the Grid Layout (GridLayout)  Grid Layout is the most used layout manager in Eclipse  It works by adding the child widgets to the cells in a grid  Widgets are added in sequence  When using a Grid Layout, the parent uses the GridLayout and all children use GridData final Composite composite = new Composite(parent, SWT.NONE); final GridLayout gridLayout = new GridLayout(3, false); composite.setLayout(gridLayout); label = new Label(composite, SWT.NONE); label.setText("Label"); text = new Text(composite, SWT.BORDER); text.setLayoutData(new GridData(SWT.FILL, SWT.CENTER, true, false, 2, 1)); // …
    46. 46. L0079 - 2009-08-27 46 Using the Grid Data (GridData)  GridData specifies how a child widget is laid out in the parent grid  A GridData holds the following primary information  Grab Excess Space (horizontal and vertical) – describes whether the grid column or row should expand to grad any excess space (defaults to no grab)  Span (horizontal and vertical) – describes the number of cells the widget should span (defaults to 1,1)  Alignment (horizontal and vertical) – placement of widget within the cells – one of SWT.BEGINNING, SWT.CENTER, SWT.END or SWT.FILL (defaults to BEGINNING, BEGINNING)  A GridData also contains information about indentation, minimum size and size hints  Don’t use the two-argument constructor! 1,1 2,1 2,2 C,C F,C E,E Horizontal grabNo grab
    47. 47. L0079 - 2009-08-27 47 SWT Events  SWT events and listeners exist in two versions:  A simple very light-weight version  One event format and listener interface  A type-safe version  Multiple event formats and listener interfaces tailored to the specific use  The difference is illustrated in the following example filter.addListener(SWT.KeyDown, new Listener() { public void handleEvent(Event event) { if (event.type == SWT.KeyDown) { //... } } }); filter.addKeyListener(new KeyAdapter() { @Override public void keyPressed(KeyEvent e) { //... } });
    48. 48. L0079 - 2009-08-27 48 SWT Events  Key  KeyDown, KeyUp, HardKeyDown, HardKeyUp  Mouse  MouseDown, MouseUp, MouseMove, MouseEnter, MouseExit, MouseDoubleClick, MouseHover, MouseWheel  Control  Paint, Move, Resize, Dispose  Selection  Selection, DefaultSelection  Focus  FocusIn, FocusOut  Tree and Table  Expand, Collapse, EraseItem, MeasureItem, PaintItem  Shell  Iconify, Deiconify, Close, Activate, Deactivate  Menu  Show, Hide, Arm, MenuDetect  Basic Controls  Modify, Verify, SetData, Settings  Drag-n-Drop  DragDetect  Misc  Help
    49. 49. L0079 - 2009-08-27 49 Lab Exercise  Create a view with the following look using simple SWT controls  GridLayout, GridData  Label, Text, Button  …addSelectionListener(…)  Another extra lab for the fast ones:  add “stuff” to the lab to only allow “a” and “b” in the text field  and to only allow more “a” than “b”!  Use a Verify listener public class View extends ViewPart { public void createPartControl(Composite parent) { Composite top = new Composite(parent, SWT.NONE); // Add something here… } public void setFocus() { } } GridLayout with 2 columns Label Text FILL aligned + grab Button spans two columns, RIGHT aligned SelectionListener that prints current text of Text control
    50. 50. L0079 - 2009-08-27 50 More Information (Basic Plug-in)  “Eclipse Plugin Development Tutorial”   “Eclipse Plugin Development Tutorial”   Eclipse Resources 
    51. 51. L0079 - 2009-08-27 51 More Information (SWT)  “Eclipse User Interface Guidelines: Version 2.1”   The Look-n-Feel guidelines for Eclipse – heavily influenced by the corresponding Microsoft Windows Look-n-Feel guidelines  SWT home   SWT versus Swing   “Using SwingRCP (instead of SWT) in RCP”   A discussion of different ways to integrate Eclipse RCP and Swing  “The Definitive Guide to SWT and JFace” by Robert Harris and Rob Warner (ISBN: 978-1590593257)  As it says – “The Definitive Guide…” – and needed due to the pure javadoc of SWT  “SWT Snippet” Repository   A large repository of sample code for most uses of SWT!