“The best editor is the one that gets out of your way once you set it up.”
Creation date: 2010-03-11T01:41:47
KDevelop has been on my desk for a while, but this week I pushed it hard with a mixed language workspace. Think C plus plus with Qt, a bunch of Python utilities, some PHP for a tiny admin view, and a few shell helpers. I wanted one place to read code, jump around, run it, and commit. No editor hopping. No window whack a mole.
If you are juggling more than one language, KDevelop is surprisingly calm. With the new releases of KDE SC out and the KDevelop 4 branch maturing, it feels ready for teams that write native code and scripts side by side. Below is how I configure it to behave like a quiet assistant instead of a loud guest.
Story one: the day I stopped juggling windows
Monday morning. I opened a Qt app that talks to a service over JSON. The service had a Python test harness. The admin screen was a tiny PHP page with two buttons that saved a flag. My habits would send me to Kate for quick edits, a terminal for builds, and another editor for the PHP view. I decided to give KDevelop a full day and keep everything inside it.
I created a new session and added the CMake project for the app. Then I pulled in the folder that hosts the Python tools. For the PHP bit I used the generic project option because that piece has no build system. With that, I had one tree where I could search the entire codebase and one shortcut to switch branches. The editor used Kate under the hood, so all my muscle memory for selection, indent, and bookmarks worked. By lunch I had stopped reaching for other apps.
Story two: when the tools started to feel like one tool
By midweek I wanted to run unit tests for C plus plus and Python, then launch the app with a custom env. I set a build folder outside the source tree, pointed CMake at it, and made a launch configuration that sets a couple of env vars and runs the built binary. For Python, I made another run entry that calls the test runner script from the same window. Both showed up under the same green play button list. It felt like one project, not three.
The experience is not flashy. That is the best part. You get code completion for C plus plus that is smart enough to track headers and macros. You can jump to definition, see all uses, and get a clear outline of classes. For Python and PHP, the plugins are lighter but still help with navigation and basic completion. It is not a full stack of tricks for those languages yet, but for a mixed space it is more than enough.
Deep dive one: sessions and projects for a mixed language setup
Start by treating sessions as your workspace containers. One session per product or per team keeps things tidy. Inside a session you can add as many projects as you need. KDevelop will index them all and give you one search box across the lot.
– Add your C plus plus app as a CMake project. Point to the top CMakeLists file, then choose a build folder that lives outside the source tree. This keeps artifacts away from version control and makes clean builds painless. Set the compiler and the CMake generator that matches your platform.
– Bring in Python and PHP code with the generic project import. Pick the folder and let KDevelop index it. You will not get a build button here, but you will get navigation, search, and file management.
– In Project settings, set per project file filters so the indexer ignores large vendor folders, old tarballs, and generated code. This keeps completion snappy and search results clean. A tidy index makes the whole tool feel faster.
– Open Configure KDevelop and set the editor profile. Use one code style for C plus plus and another for your scripts. Kate gives you modelines, indent, and color themes that are easy on the eyes for long sessions. Saving your style is worth the five minutes it takes.
– For C plus plus projects that mix Qt and plain code, verify include paths in the project settings. The C plus plus engine in KDevelop reads compile flags from your build system, but custom defines from exotic modules sometimes need a nudge. Add them in the project include configuration so completion sees the same world the compiler sees.
– If the team uses both Git and Subversion, you can add both projects to the same session. KDevelop detects the tool per project. The version control panes show status, diffs, and history without leaving the editor. Keep your commit templates and user info set per repo to avoid awkward authors.
Deep dive two: build and run like a pro without leaving the IDE
The real gain for me came from setting build configurations and launch configurations that match how we ship and debug.
– Create Debug and Release builds for the CMake project. Assign different build directories so artifacts do not collide. Select the build type in the project settings. Use the build tool button to build the active one. The build view shows errors and lets you jump to the file and line with a click.
– Make a launch configuration for the app. Set the executable path to the binary from your build folder. Add program args as needed. Set working directory to a writable temp folder if the app stores logs or caches. Add env vars like LD_LIBRARY_PATH or QT_PLUGIN_PATH so plugins are discovered without a system install. Save it with a clear name.
– Create another launch entry for Valgrind. KDevelop can run your binary through it and show leaks and hotspots in a friendly view. When you chase a tricky crash, pair it with the built in debugger. The GDB front end knows about threads, watches, and pretty printers for Qt types.
– For the Python test suite, add a run entry that calls your test script with the right interpreter. If the project expects a custom PYTHONPATH, add it to the env of this entry. Now you can hit play and see tests pass or fail in the same problems view that you use for C plus plus errors.
– For the small PHP admin page, you can point a run entry at a local server script or simply register an external tool that opens your browser at the right URL. It is not fancy, but it keeps the routine in one place. The point is to avoid that mental context switch.
– If your C plus plus code needs data files from the repo, keep a copy rule in the build step or make a simple script. KDevelop can run pre launch actions before starting the app. That way every run starts from a known good state.
Deep dive three: navigation, plugins, and little helpers
KDevelop shines when you move around large code bases. A few habits save a ton of time.
– Use Quick Open. Type a few letters and jump to a file, class, or function without taking your hands off the keys. It respects your session and prioritizes the projects you have open.
– The DUChain powered navigation lets you go from a symbol to its declaration or definition and back. The Uses view shows every place a symbol appears. When you do a refactor, you can sanity check impact in seconds.
– The Outline view gives you a map of the current file. For classes with long bodies, it is the fastest way to move. The breadcrumb above the editor also doubles as a navigator across namespaces and scopes.
– The Grep view is underrated. It does fast searches across all your projects and lets you pin results. When a bug crosses C plus plus and Python, you can track the feature name or an id across the stack.
– Version control panes for Git and Subversion are practical. Stage, commit, and inspect diffs without leaving the editor. Blame view helps when you inherit a file and want context. Hook scripts still live in your repo, so KDevelop does not get in the way of your normal workflow.
– The Problem reporter gathers compiler messages, test failures, and tool output. Fixing issues from this panel feels natural. For deeper checks, wire in Valgrind and your favorite static checker as external tools. Even if there is no first class plugin for every linter yet, the external tool support fills the gap.
– Do not forget Snippets. Small templates for test cases, logging blocks, and guard code keep repetition low. Pair them with file templates so new headers and sources come out with the right license and includes.
Reflective close: timeless lessons from a week in KDevelop
Mixed language workspaces are everywhere now. Native core with scripts around it. KDevelop handles that reality with a steady hand. The secrets are simple and they travel well to any team.
– Treat sessions like products. Add projects freely but keep each session focused. Your brain will thank you when search results are clean and the open files list makes sense.
– Keep builds out of the source tree. It keeps version control clean and everything compiles faster when you switch build types. Fix include paths and defines so completion sees what the compiler sees. You will feel the difference as soon as you type a few letters and the right suggestion appears.
– Make launch entries for every routine you run more than once. App, tests, tools, profilers. Give them clear names. The play button list then becomes a menu of your day.
– Accept that some plugins for scripting languages are still growing. Use them for navigation and search, and lean on external tools for linting or coverage. Do not wait for perfect. Use what is here and wire the rest.
– Learn the quick moves. Quick Open, jump to definition, uses, split views. Ten minutes here will save you hours every month.
On a fresh KDE SC with Qt 4.6 and the KDevelop 4 branch, I have a workspace that feels light and complete. The editor fades into the background. The project is front and center. That is the measure that matters. If your day looks anything like mine, give KDevelop a real shot as the center of a mixed language setup. The payoff is quiet focus and fewer moving parts.
As always, if you have tricks that make this smoother, drop them in the comments. I am still refining this setup and I will share more as the plugins grow and the team pushes new parts of the toolchain. For now, this is a calm way to work across C plus plus, Python, and PHP without feeling like you live in a toolbox.