Things to be figured out:
Probably at the moment KDevelop is quite optimal when it comes to the day to day development of a C++ developer/KDE Hacker. Making an SDK on top of KDevelop, I think it would mean to fulfill the following use cases:
Someone should add a "deplyoment" concept to our launch/build tools, such that we can use e.g. CMake/QMake for cross compiling and afterwards deploy some binary blob onto a device.
It should be simpler to debug e.g. an KIO slave or a KDED plugin or a Plasmoid or ... Maybe by adding different/special launch configurations for these things or so... What about a Gammaray plugin?
One way or the other, QML will stay and we should support it. Thus lets work on a language plugin and integrate the qmlviewer and stuff like that.
Thanks to the .qch integration it should all work already. We should ensure it does. We could also think about adding a 'getting started' section to the welcome screen that has shortcuts to download the most common .qch documentations e.g.
The new file templates stuff should help a lot here. But we could/should add a new provider for KDE and Qt examples. Also, we must ensure that these official examples have a high quality. Also we should write/extend the KDevelop examples, i.e.: toolview, language plugin, app wrapper (like quanta), ...
The unit testing branch should be merged and we should ensure it works nicely. E.g. we want to hide unit tests from the launch configuration.
Once the unit testing is in, we could automatically add launch configs for targets in a project. Also (or alternatively?) we could store launch configs associated with a project target (opposed to scripts or running an absolute path) in the project.kdev4 file such that it can be shared between developers.
The Project Page idea should be revived and implemented. Sharing meta data and social aspects around community projects should be cool.
KDE Community Wiki 