(For the unenlightened out there, IDE stands for Integrated Development Environment, a program that usually includes a text editor specifically geared toward program source code, an integrated project manager to keep track of what files are part of your program, some kind of parser for error messages from your compiler, easy ways to call up your compiler and debugger, and possibly similar tools. It’s a programmer thing, you wouldn’t understand. 
)
About ten years ago, I was forced to drop Borland C++ and switch to Microsoft Visual C++, because Borland’s compiler simply didn’t support a feature that my project at the time required. It was a very traumatic experience… I’d been using Borland’s compiler products ever since college (Turbo Pascal, Turbo C, Turbo C++, and Borland C++), and I was comfortable with them. Even more, I liked them, as a company, as much as I disliked Microsoft… their no-nonsense license agreement (you could use its products “just like a book”; you were allowed to make multiple copies of a program, as long as only one copy was in use at any point in time) was very innovative and fair, and that I found it impressive might give you some idea of the state of software licenses at the time.
But Borland’s products, preeminent for fifteen years or so, had been going downhill for a while. Each version was buggier than the last, and the aforementioned missing feature was the proverbial straw that broke the camel’s back. I switched to Microsoft’s compiler instead, and was obliged to switch IDEs too.
I hated every second of it. Eventually I got productive with the new editor, but I never learned to like it. Minor features in Borland’s IDE, like the ability to display a faint line at eighty columns so that I knew when I should move to a new line, and the ability to automatically eliminate whitespace characters at the ends of lines… MSVC just didn’t support them. Some of these were politically motivated (you weren’t supposed to care about the number of characters in a line, that was text-mode thinking, nevermind the fact that different computers had different maximum resolutions), others were arrogant assumptions (if you put a space there, even accidentally, we’re going to keep it forever because you must have meant it), still others I never figured out the reasons for. And there were enough of these “minor features” missing from MSVC that I keenly felt the difference. I probably could have learned to write customizations for it that would have made up most of the lack, but I had too much real work to spend time on that. And you pretty much had to use an IDE to write Windows programs, at least the Microsoft way — if you didn’t, you were reduced to a slow and arcane method of creating text files that described the visual “resources” of your program (dialog boxes and the like), which was even more painful. (The excellent and cross-platform wxWidgets library solves that now, in the way that I’ve always wanted things to work.)
Fast-forward to last year, when I switched to using Linux full-time. Since MSVC doesn’t run under Linux (of course), I was obliged to switch IDEs again. As mentioned at the time, I ended up using Eclipse. It’s fully cross-platform, and works with any compiler, so in theory I would never again be forced to switch environments, even if I switched operating systems.
I don’t really require all that much from an IDE. I just want a decent editor, a very basic project manager, an easy way to go to the lines that the compiler is complaining about, and (the number one requirement) that it not get in my way. Eclipse, with the CDT plug-in, did most of that… the editor had a few quirks that I didn’t care for, but it seemed at least as good as MSVC. Until I started using the Boost libraries very heavily in Project X. Eclipse, written in Java, was just too slow… it spent more time “scanning” my files, when I tried to compile them, than it took to actually compile them. And it wouldn’t use the second CPU core to do it, allowing the compiler to use the other one to simultaneously compile the code.
Last week, all of this came to a head when I started working on a new portion of the project, and realized that I was going to have to recompile (for testing) a lot in the near future. I decided that the time spent looking for, and learning to use, a new IDE would be more than made up for by the potential savings in compile-time.
I also wanted whatever I was using to be open-source. I have no problem paying for software (I’ve got several shelves dedicated to the for-pay software that I’ve bought, and I’ve written for-pay software for nearly a decade), but the company that makes it has complete control over it — if it dies or decides to kill off the package, you’re stuffed (there can never be any more updates to it, period), and if they get some nut in charge that has a different sense of what is esthetically pleasing, you get the dubious benefit of his changes, like it or not. Thanks but no thanks, I’d had enough of both with Borland. At least with open-source software, I can continue to update it if I don’t like how slowly it’s moving, or the direction that a later version is taken.
Anyway, the three top contenders, after a bit of research:
KDevelop. Pros: highly recommended, multiple language support, extensible via plug-ins. Cons: Linux-specific, no simple way to support the Boost::Build system that I use, and I have a personal and irrational bias against KDE. I didn’t even want to try it until I’d exhausted the other alternatives.
Anjuta. Pros: also highly recommended and extensible, with multiple language support, and GNOME-based. Cons: also Linux-specific, Boost::Build only supported via a make-based hack. I actually installed this one and gave it a whirl, but when I tried to make a project with it so that I could test it out, it immediately demanded that I install something else first, so I put it off.
Code::Blocks. Pros: highly recommended, extensible, fully cross-platform using the wxWidgets library, can support Boost::Build with minimal settings changes. Cons: C/C++ only, not available via Ubuntu’s repositories. It’s labeled version 8.02, but that’s misleading because it’s using the Ubuntu version number system. It’s actually only on its second major release; the project is about three years old, and its youth shows in a few areas that aren’t as polished as in other projects — such as, when you try to compile a program and come up with errors, and edit the file to fix the first one, going to the next error takes you to the line number that it was originally on, rather than the one that your previous editing moved it to.
Nevertheless, it fits my aforementioned criteria — especially about staying out of my way so I can do my work. It has several of the minor features that I haven’t had since Borland’s compilers, and a few unique ones that I’m rapidly coming to like as well.
So the search is over. I’ve decided to stick with Code::Blocks, at least until I find a darn good reason to change. Maybe I’ll even find some time to contribute code to fix some of the unpolished edges, we’ll see.
But oddly enough, almost all of them were under the /proc branch. After eliminating that, I had only a handful.