Devel GTK Patch guidelines

⚠️ THIS TOPIC CONTAINS PARTIALLY OUTDATED INFORMATION ⚠️
GTK 2 is no longer supported by SWT.

Patch submission guidelines

When submitting patches, you should consider the following guidelines.

Avoid re-factoring code in the same patch as a bug-fix. Instead split it up into two commits. This makes it easier to rollback broken commits and avoids merge conflicts.
Please avoid removing white spaces in the same commit as a bug fix. Reviewing patches that consist of a lot of white space removal and a few actual code changes is tedious and causes merge conflicts. Instead submit white space removal in a separate patch.
Do not introduce any trailing white space into the code base.
Your code should follow SWT code style. See the code in other widgets for guidance. E.g use '!=' instead of '>' for bit checks.
Avoid introducing methods that are only called once. But if you see the same code many times, it makes sense to add a method for it.
When removing code that calls internal functions, check that those functions are actually still called else where. Avoid leaving dead methods in the code.
Not contain non-ASCII characters
Refer to the style guidelines for information regarding commit message etiquette

Compile/build on both GTK2 and GTK3
Be sure to commit all files necessary for native building, i.e. os_stats.h, etc...

Any testing should happen across the last two stable versions of GTK3, GTK3.22 and GTK3.24. GTK2 testing isn't required as it will be removed in Eclipse 4.10. Please see the JUnit testing page for more info.
If the initial bug report contains a snippet that reproduces the issue, please test using this snippet as well
Please run the JUnit test suites on your patch, and try a child Eclipse instance to make sure nothing else is broken