During Akademy I once more was a bit disappointed how bad the project plugin of Kate can cope with out-of-source builds.
At work, we use in-source-builds, as we normally only build in one configuration and have no issues with left-overs in the source directories locally. For this use-case, the project plugin works really well. You have your project local terminal view and that allows you all normal things you need during work, e.g. building + using the git command line client for the version control work.
On the other side, with out-of-source builds, that no longer is that nice to use. Either you use the .kateproject generated by the “Kate – Ninja” or “Kate – Unix Makefiles” CMake generators, then your terminal defaults to the build directory, which allows building just fine, but no version control stuff, or you use the .kateproject (or auto-project creation) in the source directory, which doesn’t allow you to build nicely inside the terminal prompt of Kate. There are workaround for that, like having shell magic to switch between source and build directory with ease, but that all feels a bit unnatural.
Therefore, I added today a very simple “fix” for the issue: If you have a .kateproject that has a different base directory (the toplevel “directory” entry) than the directory the .kateproject file is located in, you will get two terminal tabs in the project view. One is the “old one” that has the directory of the .kateproject as base, the other has the base directory of the project as base.
I hope this improves the usability of the project plugin for the normal setup of out-of-source builds with CMake. If this sparked your interest: any further improvement ideas are welcome, best as patches submitted on phabricator.kde.org.
I think this small change is something that shows how many open source contributions work: You have some itch to scratch and you share your solution to help others that have a similar issue.
If you look at the open bugs & wishes for Kate/KWrite/KTexteditor/… you will see that there are still a lot things that need some scratching. It might look like the developers don’t care for the issues of their users, but that is not correct. We just don’t have the time to scratch all these itches (nor are all that easy solvable). Sometimes we unfortunately did even lack time or motivation to do proper reviews for some proposed solutions, I hope we improve on that in the future. Any volunteers that help us taking care are always welcome. The addition of the inline notes interface is a nice example. Michal Srb provided an initial solution for his own needs to us and sparked some new development with that.