This is a brief step by step description about a typical work flow of fixing a first Mixxx bug. Follow the links for more details.
You can edit Mixxx's code in anything from a basic text editor to a professional IDE (Integrated Development Environment.) We've had good experiences with Eclipse, but some of our developers just use text editors that handle multiple files and support syntax highlighting such as Kate or Notepad++. If you're working from a text terminal, GNU Nano also supports syntax highlighting, though it's not quite as thorough as many of the graphical ones. See Developer Tools for more information.
Read the code to figure out what it is doing. Insert qDebug statements to help understand what is happening at specific points in the code. Note that you must run mixxx with the
--debugLevel 2 argument to have all debugging messages printed to the console.
Ask your questions or discuss your ideas on Zulip chat.
Some notes about the Mixxx Control interface: developer_guide_control
And don't forget to ask if you get stuck!
You can open a pull request before your code is ready to be merged with Mixxx to show others your code and ask for help, just make sure to say that your code is not ready for merging when you open the pull request.
If your pull request changes the GUI, please include screenshots of your changes.
This is the most annoying part. Because we are sometimes nit pickers Don't take it personally if there are a lot of changes requested. Code review is important to make sure that Mixxx continues to run reliably and quickly. It is also important so that Mixxx remains maintainable so we can keep making it better without having to make huge changes.
Be sure that you code follows the Mixxx coding guidelines to avoid extra work.
You have to sign a contributor agreement. We will contact you about it in time.
The Bug is fixed now and will be released with the next release cycle.
Your name will appear in the “About” box of Mixxx.