Revision as of 15:35, 17 August 2018

This page is useful for beginners who would like to develop SWT. All of the information here is cross-platform, general knowledge. Please note the page is under construction.

Getting started

Please note this article is still being written and is not final.

Eclipse Plugins

Download and install SWT tools. Other than that, you may find the following plugins useful (not mandatory for SWT development):

• EGit
• Code coverage (Eclipse Marketplace)
• Quick search (Eclipse Marketplace)

Download/import sources and binaries

SWT works using two code repositories:

1. The source code, which contains Java and JNI source code for all widgets. This where 99% of all changes belong.
2. The binaries, which contain the platform specific library objects. These allow the Java source code to call the operating system's toolkit.

Start by cloning both of git repos above. From the sources repo, import the following projects:

• org.eclipse.swt
• org.eclipse.swt.snippets
• org.eclipse.swt.examples
• org.eclipse.swt.tests

This will add the SWT source code, snippets, example applications, and test cases to your workspace. Now import the binaries project. This will depend on your platform and architecture of your machine -- choose accordingly.

Modify the .classpath

After importing the SWT sources and binaries, you will see lots of errors. This is normal, as the SWT sources have not yet been linked to the binary matching your platform and can be resolved by modifying the .classpath file.

1. Open the "Navigator" view (not Package Explorer).
2. In the org.eclipse.swt folder you will see a collection of .classpath files corresponding to various platforms (GTK, Win32, Cocoa, etc.).
3. Copy the desired .classpath_* file.
4. Paste it in the same folder, except rename it to .classpath
5. Go to Project -> Clean, and clean the org.eclipse.swt project and the project matching your platform's binaries.

Gerrit configuration

Eclipse/SWT uses a code review tool called Gerrit. It's quite easy to configure if you have the EGit plugin installed.

1. Open the "Git Repositories" view
2. Expand the "org.eclipse.swt" item (assuming you have the org.eclipse.platform.swt project in your EGit repositories view)
3. Expand the "Remotes" item
4. Right click the "origin" item, and select "Gerrit configuration"
5. Fill in your information from gerrit (username).

Writing a patch

How SWT interacts with native code: native and non-native changes

Before writing an SWT patch, it's important to have a crash course on how SWT interacts with native code. Earlier we mentioned the SWT sources (org.eclipse.swt) and the binaries (such as org.eclipse.swt.gtk.linux.x86_64, as an example). The binaries project in your workspace contains library objects, such as .SO files on Linux, .dll on Windows, etc. Modifying the .classpath allows the SWT sources project to load these library objects and run the SWT from your workspace.

How does this work? Well the SWT sources use Java code to interact with native libraries through JNI. This is done by adding boilerplate JNI function signatures in files like OS.java, for example. SWT Tools then generates the JNI C code which links the Java JNI functions to the actual native calls. The generated code and the JNI function signatures (as well any other Java code) are then merged as one change under the org.eclipse.swt project. This type of patch is considered a native change.

After such a change is merged, the JNI C code does not need to be generated again. Changes that do not modify the JNI code are considered non-native changes, as no additional changes beyond "pure" Java code needs to be made. However SWT does not load every function possible from native libraries, only those that are actually called/needed by SWT. It is not uncommon that a bug fix will require a new native function available for use in SWT, in which case its method signature needs to be added to SWT. And thus the process repeats itself.

Writing a non-native change

Non-native changes require no special action -- just upload to Gerrit as usual.

Writing a native change

Native changes are trickier because they require the author to rebuild the native bindings. Those library objects mentioned earlier now have to be generated as well in order for SWT to run with the changes in the workspace. While these don't need to be submitted in your Gerrit change, they do have to be built for testing purposes (otherwise SWT won't run and will complain about library link errors). For instructions on building the library objects, check for a README file in that platform's project folder.

After testing your patch, follow the steps below to submit a native change:

1. Prepare all Java code, including function signatures in OS.java
2. Go to Project -> Clean. Clean the SWT sources and binaries projects. Make sure "Build Automatically" is checked in the Project menu.
3. After cleaning, some *.c and *.h files will show up in the Git staging area. Usually these are files like os.c, os_stats.c, os_stats.h, etc.
4. Commit these, as well as the Java files. Submit the patch by right clicking the org.eclipse.swt project in the "Git repositories" view and select "Push to Gerrit".

Adding API to SWT

SWT API has to be backwards compatible, meaning changing existing API is basically not an option (except in a few cases). However it's very common to add new API -- to do so, follow the steps below.

1. Add the API. If you are doing this in a common class, you only have to add it once. Otherwise, be sure to add the constant/method to all platforms' classes.
2. If this is the first time you are adding API in this release cycle, bump the minor "version" fields in the pom.xml and MANIFEST.mf files. For example, 3.107.100 -> 3.108.0
3. Write the Javadocs, and be sure to include @since tags, indicating the API is available since the API version you just bumped in step 2.

Setting an API baseline

In general, it's important to configure API tools properly to warn you about API changes and versions that need to be bumped. To set an API baseline:

1. Go to Windows -> Preferences. Search for "API baseline"
2. Click "Add Baseline"
3. Select "An existing Eclipse installation directory"
4. Click "Browse" and point the wizard to the binary "eclipse" file for your current Eclipse installation
5. Click "Finish"

Writing new and noteworthy (N&N) posts

If you've added a new feature or fixed a significant bug, it's often useful to write an N&N post. N&N posts are short HTML entries in a milestone's/release's N&N page. The N&N page showcases improvements and features for all aspects of the Eclipse IDE during that milestone/release. To write an N&N post:

1. Clone the eclipse/news repo
2. Look for the folder and file corresponding to the milestone/release and component you want to write about (for example: 4.9/platform.html)
3. Follow the instructions in the HTML page and/or look at other posts as example
4. Add a new section with a meaningful title and a short description about the feature/bug that was fixed. Images can be added to further demonstrate the fix (follow the instructions in the HTML file re: images)
5. Submit the change by right clicking the news project in the "Git repositories" view and select "Push to Gerrit".
6. Once uploaded in Gerrit, add a committer from your component to review it.