Let's discuss KDevelop4 interfaces and shell

[dymo at ukrpost.ua]

Hi! I've started my work of Sublime UI integration and first looked at kdev4
architecture and code in lib/ and src/. So I'd like to share some thoughts about
what I saw. This will be lengthy email, so prepare ;)

First there's no more clean separation between lib/ and src/.
As I understand that, the reasons behind the merge were:
- there's no point in maintaining one interface in lib/ and one implementation in src/
  because there's little chance someone is reimplementing the KDevelop platform
- platform can be considered as a library that just provides useful plugin architecture
  and some control over what is happening there
So far I observed followng problems with that:
- the stuff in lib/ now contains everything - tons of classes with huge implementations
  and rich interfaces. It contains even background parsers and lots of kdevelop
  specific stuff
- the interfaces (if I can call them interfaces now) are huge and have high
  coupling and lots of dependencies
- BC will be impossible to keep because when you want to modify the KDevelop
  shell, you will need to modify interfaces as well. For a "good" example see
  Koncrete::DocumentController class which does everything connected to the
  documents, has tons of slots, signals (public and private) and generally 
  has every single implementation detail exposed. At the same time any plugin
  can get this object via Koncrete::Core::documentController() and call 
  and abuse all that stuff.
- in general it's hard to modify anything in the code because after changing
  it in one place it gets broken in many others. The kdev4's stuff in lib/ feels
  more complex than it was in kdev3 and it's a pity.

The problems above are not the only ones. The design of core classes has 
troubles also. The major problems are:
- there is EditorIntegration which correlates with nothing else by design.
- PluginController is also freestanding, Core knows about other controllers
  and not about this controller
- Core class is just a collection of static methods, there're a lot of static objects
  everywhere and it has a cumbersome initialization procedure

So those are the problems as I see them. And here are the solutions I propose:
- create koncrete/ directory in source tree to hold kdevelop ide independent
  platform stuff
- extract interfaces from PluginController, ProjectController, LanguageController
  and put them into koncrete/interfaces directory
- make Core class non-static and abstract, create plugins with Core as a parent
  and provide core() method in Koncrete::Plugin in a similar way we did with
  KDevApi in 3.x., move Core and Plugin to koncrete/interfaces too
- move controller implementations into koncrete/shell directory
- move anything else not related to the shell (and potentially useful to
  quanta) into koncrete/shell
- provide extension interfaces mechanism (like in 3.x or invent another one)
  for kdevelop-specific classes and move their implementation to the plugins
  (for example background parser could be moved to the generic language support
  plugin which could implement the interface to get and operate with the parser)

These proposals are not complete of course, but we'd need to solve the problems
described here first and then look further.

All of the stuff I'm proposing is debatable, so let's share our vision and 
decide how to approach to the outstanding architecture problems.

PS: of course I volunteer to start over my plan in a branch ;)