-
Notifications
You must be signed in to change notification settings - Fork 123
Home
Here is the wiki for the contributors of NME. Mainly for sharing development ideas and coding guidelines etc.
To learn using NME, check the documentation.
This is the official GIT mirror of NME's SVN repo on Google Code. You can fork and make pull request to here, and the changes will be synchronized to the SVN repo from time to time.
However, the main contributors of NME are still using SVN, and the synchronization is not automatic at the moment. So please take a look at the SVN repo before starting to work on a feature/issue to avoid conflict or waste of time. It would also be more efficient and cause less trouble to commit to the SVN. Feel free to ask for commit right after you've shown your skill and enthusiasm (eg. by giving some good quality patches/pull requests).
Take a look at the issue page:
- Atlassian project tracking
-
Issues on Github(close!) -
Issues on Google Code(close!)
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.