These are the notes I (Milian) took during the KDevelop BOF at Akademy 2013. Please extend if I missed anything.

state of the union

What we have works relatively well and many like our product. There are many things which we could improve though.

clang

Major next step, see Projects/KDevelop4/ClangRoadmap for more details.

workflow

We still need to work on usability. Commong workflows need to be "optimized" and simplified. Especially the concept of areas and having different workingsets in the areas needs to be revisited.

Other points raised: - documentation toolview: one cannot add/configure stuff directly from the toolview, needs at least a shortcut to the settings - the separation of editor settings and kdevelop settings needs to be revisited. Unifying the settings is certainly possible, we'll have to see how it should look like. Probably just do what e.g. Kile is doing. - per view editor settings need to be revisited: not useful in many cases, i.e. changing the font size should be global, not per view. Dominik from Kate agreed that this makes sense and is simple to implement there. - blocking message boxes should be removed wherever possible. Maybe add a common API to the UIController to show messages in a common passive widget. Per-view messages like "document changed, do you want to reload?" should be done using the Kate interface for that. Furthermore ensure that textfiles in readonly mode show that visually, maybe "flash" the message whenever the user tries to write something into the editor when it's readonly. - integration with editor when changing branches e.g.

reload files by default if they haven't changed
how to figure out that something was not changed?
git hashobject, git catfile

multiple mainwindows

Low priority, but for those working with a multihead setup this is missing. Maybe it is enough to bring back detachable toolviews and the ability to extract just an editor window.

deployment

Working on embedded stuff or mobile phones becomes more and more important. We need to figure out how/if/when we want to support this. A quick workaround might be sharing custom buildsystem configurations via GHNS or such.

simplify codebases

A long-term goal for us should be to simplify our codebase as much as possible. This makes it simpler for newcomers to contribute and furthermore decreases the maintenance cost.

cmake

We should approach the CMake community to get more from them. The hope is to remove most of our CMake project manager codebase. Instead, get this functionality from CMake directly:

- what targets exist, what files are in there? - adding files to a target - removing files from a target - rename a target - create new target from given set of files, with target types: executable, test, library, ... - query include paths, defines for a given file

When it comes to CMake language integration, we'll probably need to keep what we have right now. It should be possible to cleanup and simplify the codebase a lot though. We'll only need codecompletion, documentation integration and maybe context browsing. So this should be put into a language plugin. The project manager should not depend/use the DUChain at all, only what cmake gives us directly.

QML plugins

Should we look into making it possible to write plugins in qml? The toolview can/could embed QQuick(1/2) without problems. Interacting with the existing API though might not be that straight forward. Furthermore, its questionable how to add actions and other widget UI elements etc. pp. Maybe Declarative Widgets would be cool?

static analysis

We agree that static analysis tools should be built on clang, as that is the future. It would still be good to improve our API for embedding static analysis tools though. We want to polish the cppcheck tool and make it easier to integrate other linters, i.e. based on the jenkins output which is supported by many.

quickopen

Miquel is working on camel case filtering.

C++11

The upcoming refactoring related to Clang will be done using C++11 features. I.e. expect KDevelop to require an up2date C++ compiler.

Qt5

We want to be able to ship a working Qt5 KDevelop version as soon as possible after Frameworks 5 is released. According to most that worked on frameworks, this should not be a big issue, as most things we use come with a KDE4 compat library. Long-term the code base should be cleaned up though and ported over to Qt5 as much as possible. That means:

- KUrl to QUrl: most heavy lifting will be done by porting the code to the new Path from the sharedurls branch. - KMimeType to QMimeType: relatively straight forward, performance tweeks need to be revisited (i.e. whether they are still required). - QStringLiteral: most of our codebase just uses string literals which then get converted at runtime to QStrings. This comes with a performance penalty (slower startup, higher memory consumption, ...). All strings literals should be using QStringLiteral. This is a good task for junior jobs, or google code-in. - probably more, left to be seen.