-
Notifications
You must be signed in to change notification settings - Fork 123
Contributing to NME
Take a look at the issue page:
- Atlassian project tracking
-
Issues on Github(closed!) -
Issues on Google Code(closed!)
We're experimenting to use only Atlassian for all the trackings. Hopefully it is our destination.
For missing feature we mean the Flash API that is not yet implemented in NME. When implementing it, please make sure the behavior and the API signature is identical to the corresponding one of the latest version of Flash. Try to document it clearly if the implemented feature is complete for all the NME targets or only works for some targets.
For anything not included in the Flash API or not already existed in NME, don't make an pull request to NME. Instead, write an NME extension or look at the later section Discuss new features or changes to the API.
NME extension allows one to extend or overwrite default NME behaviors. It is also possible to interface with native library, for example written in Java (for Android project)/ Objective-C (for iOS project).
Here is a tutorial:
Since NME is truly cross-platform that it contains code written in several languages: C++, Objective-C, Java, JavaScript and of course Haxe. It means the contributors of NME are also come from different backgrounds. It is hard to unify the coding conventions. But, try to make sure the following things are consistent at least in a single file:
- Use of tabs or spaces.
- Use of Egyptian brackets or not:
if (true) {
//codes
}vs
if (true)
{
//codes
}- Use of spaces before and/or after
:of type declarations. Eg.var for:Barvsvar for : Bar.
Open a discussion on new features, or extending the API to be more compatible with another target, either in the mailing list or forums. There may be reasons why features are missing, or someone else may have already attempted this change and can give some advice.
Have larger changesets reviewed early, NME has many interrelated parts, which often require lots of manual testing. Iterating through smaller chunks that get peer reviewed at different stages is the best way to create a great patch.
Commit logs from outside the core team should usually reference an external source for the change, either a bug ticket or a URL.
The team often looks over commit logs, it's sometimes unclear why a commit was made. A link in the commit log is helpful for a historical reference should that patch ever become an issue for another bug.
If you are using code from another source, make sure the external code is not intellectual property and is permissively licensed enough to be compatible with NME's MIT license.
Generally, this means you can use MIT / BSD / Apache / ZLIB, and other public domain licenses. LGPL is highly undesirable - we can get away with it maybe on desktop with an open NME.ndll, but can't go anywhere near it on iphone. If in doubt, ask the author politely if you can use the code for an open source project.