|
| 1 | +# Contributing code |
| 2 | + |
| 3 | +This document provides information for those who would like to |
| 4 | +contribute new code to the CEF Python project. |
| 5 | + |
| 6 | + |
| 7 | +Table of contents: |
| 8 | +* [Requirements](#requirements) |
| 9 | +* [Tools](#tools) |
| 10 | +* [Python / Cython style guidelines](#python--cython-style-guidelines) |
| 11 | +* [How to debug CEF stack trace](#how-to-debug-cef-stack-trace) |
| 12 | + |
| 13 | + |
| 14 | +## Requirements |
| 15 | + |
| 16 | +- Pull requests should be sent for the master branch |
| 17 | +- Your code should follow the [style guidelines](#python--cython-style-guidelines) |
| 18 | +- Pull request should implement only one feature at a time, so that |
| 19 | + reviewing them is easy. If you have implemented several features |
| 20 | + then send them as sepearate pull requests. If not sure then ask |
| 21 | + on the [Forum](https://groups.google.com/group/cefpython). |
| 22 | +- When adding or exposing new API you should update API docs as well |
| 23 | + (the api/ directory) |
| 24 | +- When adding or exposing new API you should create unit tests |
| 25 | + for the new functionality (the unittests/ directory). If creating |
| 26 | + unit tests is not feasible or extremely difficult then you should |
| 27 | + at least provide an example through [gist.github.com](https://gist.github.com/). |
| 28 | +- Test your code before sending PR. Run unit tests. Run various |
| 29 | + examples to see if your new code didn't break them. Running unit tests, |
| 30 | + hello_world.py, tutorial.py and screenshot.py examples is an absolute |
| 31 | + minimum that you must do. Please try also testing examples for |
| 32 | + various GUI frameworks. |
| 33 | +- Python code should be tested using multiple Python versions. See |
| 34 | + [Issue #249](../../../issue/249) ("How to use pyenv to manage multiple |
| 35 | + Python versions on Ubuntu/Mac") |
| 36 | +- In most cases new code should run fine on all platforms, but in |
| 37 | + some cases it might be required to test on all platforms before |
| 38 | + PR is merged |
| 39 | +- In your pull request modify also the [Authors](../Authors) file |
| 40 | + to add your name and encoded email |
| 41 | +- If you want to update CEF version then take a look at |
| 42 | + [Issue #264](../../../issues/264)("Workflow when updating CEF version"). |
| 43 | +- Edit Python/Cython code using PyCharm IDE to see if there are any |
| 44 | + style warnings for the file you're editing. If you don't see a green |
| 45 | + tick in the upper-right corner of the editor's code area that means |
| 46 | + something is wrong with your code and must be fixed. See the Tools |
| 47 | + section below for how to configure PyCharm for editing cefpython's |
| 48 | + code. |
| 49 | + |
| 50 | + |
| 51 | +## Tools |
| 52 | + |
| 53 | +It is recommended to use PyCharm IDE to edit Cython code. See |
| 54 | +[Issue #232](../../../issues/232)("Using PyCharm IDE to edit |
| 55 | +cefpython's Cython code") for details. |
| 56 | + |
| 57 | + |
| 58 | +## Python / Cython style guidelines |
| 59 | + |
| 60 | +* Try to comply with the [PEP 8 style guide](http://www.python.org/dev/peps/pep-0008/) |
| 61 | +* Limit all lines to a maximum of 79 characters (comments should be shorter, max 60-65 chars) |
| 62 | +* Do your best for the new code to be consistent with existing code base |
| 63 | +* Use 4 spaces for indentation |
| 64 | +* Commit unix-style newlines (\n) |
| 65 | + |
| 66 | + |
| 67 | +## How to debug CEF stack trace |
| 68 | + |
| 69 | +On Linux/Mac you can use gdb/lldb, see instructions on the |
| 70 | +[KB page](Knowledge-Base.md#python-crashes-with-segmentation-fault---how-to-debug). |
0 commit comments