Your first contribution

• How to contribute to an open source project on GitHub
• Build CP Editor from source
• Qt docs
• Discover issues

Before writing codes

If there isn't an open issue for what you are going to work on, please open an issue before writing codes for a pull request, for these reasons:

1. You may get help from others.
2. Others can know you are working on it, this will save possible duplicate works.
3. You will be notified if this feature is not going to be accepted, or the "bug" is actually not a bug, etc., thus saving your time.

Contributing rules

• Remember that the goal is to build an editor for competitive programmers, not for developers.
• Do one thing in a pull request. If you want to add multiple features/fix multiple bugs and they are not relevant, open multiple pull requests. You may need to create multiple branches to open multiple pull requests, you can learn git branching here.
• Add new features on the master branch, and fix bugs on the latest active (master, beta and stable) branch which has the bug. See also the versioning rule.
• Please write clear commit messages. It's also recommended to write Conventional Commits. Since we are squashing and merging pull requests, the commit messages in a pull request is not so important, while the title of the pull request or the message of the only commit in a pull request is more crucial.
• Use Clang Format and .clang-format to format your codes. If anything wrong happens during formatting, try updating your clang-format to the latest version.
• Don't remove features unless it's necessary. Add an option to disable them instead.
• Keep the settings file backward compatible all the time.
• Everyone should obey the Code of Conduct in order to build a harassment-free community.

Documentation

The documentation is hosted at cpeditor.github.io. You can read its contributing guidelines for more information.

Translations

The translations are in the translations directory. It's recommended to use Qt Linguist to edit them. However, if you only want to fix a typo, you can use whatever text editor you like. In Qt Linguist, when a translation is finished, press Ctrl + Enter to mark it as finished and go to the next unfinished translation. If a text doesn't need translation, for example, "C++", you can leave the translation empty and mark it as finished. You should fix all warnings in Qt Linguist.

If you want to add a new language, you can ask the developers for help. For example, you can open an issue for the language you want (it will be better if you can contribute the translations after we finish the preparation for you).

If you want to go a step further: The translated strings are wrapped in tr() in the source codes. When the codes are changed, you can run updateTranslation.sh or updateTranslation.bat to update the translations. You can read Qt Linguist Manual if you are interested in it.

The settings system

The basic structure of the settings system is:

1. The information of the settings are stored in settings.json.
2. settings.json is translated to SettingsHelper.hpp and SettingsInfo.cpp by genSettings.py.
3. Settings are displayed in PreferencesWindow and separated into several PreferencesPages. Most of the settings are displayed in PreferencesPageTemplate which uses SettingsInfo to generate the page.
4. In other parts of CP Editor, you can get the settings via the functions in SettingsHelper.hpp or use SettingsManager to manage the settings. The purpose of SettingsHelper.hpp is to enable auto-complete during development and reduce the chance of misspelling the name of a setting. SettingsManager is usually used in cases where the name of the setting is a variable, for example: SettingsManager::get(QString("%1/Compile Command").arg(language)).toString().

To learn how to add/modify settings, you can refer to other settings or read the documentation. Basically, you need to modify settings.json and the part starts with AddPageHelper(this) in PreferencesWindow.cpp.

Tips

• Reuse codes when possible, even if the implementation is short and easy.
• Use DefaultFileManager when asking the user to choose a path. (With a few exceptions, including choosing a path in the preferences window, where the path is already saved in the settings.)
• Check the stderr when testing. The stderr contains warnings from Qt and qDebug() in the codes, which is a quick way to catch common mistakes.
• Use git submodule update --init --recursive to update submodules.