Ten years ago, I had written a blog entry about KDevelop. There was some sort of short coming, and moved on from there. I think my next environment was NetBeans.
Netbeans worked for me for quite a while. But when it was taken over as an Apache project, the C++ side of things have dwindled away. Only through an obscure programmer's build was I able to get it to build C++17 code.
That forced me to cycle back into Eclipse to edit and build my C++ apps. It has good integration with the CMake build process. That worked well. For a while. Then I started building some Linux kernel attached apps. Those apps require including various kernel libraries.
The pain point here is that there are a number of special include paths, and I could find no way to get those paths into the environment so I could open include paths and name references. By using a CMake build process, the C++ configuration items for those paths are all hidden/removed (as the Eclipse make system isn't used).
Coming full circle, KDevelop has evolved. I have evolved. And we seem to be meeting at the same point. KDevelop 'knows' how to pull the needed information from the CMake build process. My first half hour of use has provided being able to review #includes and the associated symbol references. So far so good.
The disadvantage of KDevelop is in window management. I can split windows, but to move a tab from split to split, doesn't seem to be possible. And on program restart, window/tab arrangement is not restored. And there are some symbols definitions to which it should be able to jump, but doesn't. KDevelop is not as good as it could be.
I think I could have worked with KDevelop, however, it couldn't seem to build a complete symbol table reference. That or I didn't twist the correct knobs. Going from file to file, following symbol referencesis how I typically come up to speed with code.
So... onward to something else.