SWT/Devel/Gtk/Patch guidelines

Patch submission guidelines

When submitting patches, you should consider the following guidelines.

Formatting

Your patches must:

• Avoid re-factoring code in the same patch as a bug-fix. Instead split it up into two commits.
• Please avoid removing white spaces in the same commit as a bug fix.
• 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.
• 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. See SWT/Devel/Gtk/NonAsciiCharacters

Building/Compiling

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

Testing

• Any testing should happen across multiple versions of GTK3, and the current release of GTK2. For example, at the time of this writing, any snippets/test cases/child Eclipse instances should be tested for versions. Please see the JUnit testing page for more info.
  • GTK3.20
  • GTK3.18
  • GTK3.16
  • GTK3.14
  • GTK2.24
• 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 for the GTK versions listed above

General etiquette

• Description : It's recommended to mention how you tested your patch at the end of the description.
• When you submit new patch sets, in the comment please describe what you improved on (unless it's a trivial thing). Often when reviewing multiple patch sets it's easy to loose track what was done in each patch set.