IDE Support

[tresf]

A major part of contributing to a large codebase is support for a particular IDE. This lowers the barrier to entry for a particular project because it gets developer hands on the code quicker.

Choosing an IDE

• Based on my conversations with two professional C++/Qt developers, QtCreator is a professional grade IDE that works well for most of the above purposes so that will be the initial focus of this task. There are also commercial IDEs as well as platform-specific IDEs that can also do the trick. Often, developers don't even use an IDE and use nano, vi, gedit, kate, notepad++, atom, sublime, etc. This is OK too!... but they are out of the scope of this task.

Objectives

• Setup: The initial setup of the IDE. This will vary depending on platform, but short steps on how to install and configure the build environment can speed things along.
• Building: This is arguably the most important part if an IDE is used properly. The play button should properly build the source code and run the application.
• Debugging: Hand-in-hand with building, but often the IDE has special steps for inspecting/watching a particular part of code. A video may be better than a wiki in this case, but debugging steps are important if an IDE is to be used properly for hunting bugs (which we have plenty of)
• Dependencies: 3rd party dependencies must be recognizable by the IDE so that the project will build and to encourage code completion. Adding new dependencies should be documented/relatively easy as well to encourage new feature development.
• Code Styling Steps: This is important because PRs become a wasteful back-and-forth when spaces/tabs are the only thing preventing good code from being merged. Pre-configuring an IDE with code styling is extremely important to prevent frustration with otherwise perfectly good code.
• Version Control: Most IDEs have git integration, but this shouldn't be taken for granted. Sometimes, committing and pushing can be hard to find in the IDE. Also, there are often built-in diff features which are a good part of the pre-commit-review process. We should provide basic steps for the review-commit-push process.
• Branching: The topic of branching is an interesting one because we don't really spell out the fork-branch-PR-commit process. This is is more of a "GitHub" best practices, but we should either link to an official document on this or write our own so that developers don't get burnt-out accidentally editing the unpushable upstream.

Here are two videos that I was given permission to share by @curlymorphic that tackle a lot of the above using an IDE called "Qt Creator".

• Initial Loading http://youtu.be/XTWnQPGL9xs
• Tips and Tricks: http://youtu.be/3OzGXfm6fqE

[midi-pascal]

LMMS being a Qt based application, Qt Creator is the IDE of choice for it.
It is multi-platform, easy to set up and to use.
The debugging and source control are well integrated and easy to use.
I must say, it is my preferred IDE now, even for non-Qt apps, on any platforms.
so 👍

[Vzor-]

This looks like a good place to start. I'm on this one.

[tresf]

@Vzor- I'm not sure if you'll need it but we're in the process of rewriting our Compiling tutorial. Here's our draft, if it's of any assistance.

New compiling tutorial permanent link: https://github.com/lmms/lmms/wiki/Compiling