Let's discuss KDevelop4 interfaces and shell

[Matt Rogers]

On Thursday 18 January 2007 5:35 pm, dymo at ukrpost.ua wrote:
> 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 ;)
>

Thank you for starting the discussion. 

Personally, I would like to see more discussion take place on the mailing 
list. It may not be as high bandwidth as IRC, but at least then we can all 
follow and participate and don't get all worked up over reading something in 
an IRC log that can be misinterpreted.

> 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

That's not what I ever considered the platform to be. I thought the platform 
was about providing an API that can be used to create IDEs, similar to the 
Eclipse SDK. Other than needing a bit of love and some cleaning up, I think 
we're doing a decent job of providing that API. 

KDE already has something that provides a useful plugin architecture and if 
that's all you expect the platform to be, then we might as well not have a 
platform.

> 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

A lot of things there are KDevelop specific and should be moved to other 
places. However, there are a lot of other things that should continue to be 
there and I would argue that the background parser is one of those.  Let's 
take a step back and look at what we want the platform to be. We want it to 
be an API that can be used to ease the creation of an IDE. In my mind, this 
is very similar to the Eclipse SDK. Every IDE that I've worked with operates 
on a language. That language will probably be parsed. Where is the problem in 
providing a common base that can be used to build off of for things like a 
background parser, code model, etc.?

> - the interfaces (if I can call them interfaces now) are huge and have high
>   coupling and lots of dependencies

Sure you can call them interfaces. They're all interfaces. API means 
Application Programming Interface. :)  The tight coupling and the lots of 
dependencies needs to go though, I agree. In my mind that was the plan all 
along, but I haven't had the time so far to do anything with that, and Adam 
kinda disappeared and so it's be overcome by events.

> - 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.

Does DocumentController need to be cleaned up? Yes. I will agree with that. To 
what extent it needs to be cleaned is up for some debate and perhaps we 
should have a separate discussion about that.

> - 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.
>

That's because the goal for the src -> lib merge hasn't been accomplished yet, 
IMHO. The goal was to move things that would be common to the platform into 
the platform library, and then whatever was not general enough for a library 
gets moved back out into src. The work that was supposed to go towards 
accomplishing that goal just hasn't been done yet.

> 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.

Except with integrating the code model and the background parser and the 
language support bits with kate, which, IMHO, is quite important. Why does 
EditorIntegration need to correlate with anything more than that? Perhaps 
Hamish can tell you more about it.

> - PluginController is also freestanding, Core knows about other controllers
>   and not about this controller

And it should stay that way. IMHO, Core should go away and we should just use 
real singletons. Once we really get down to it, we shouldn't have that many 
of them anyways.

> - Core class is just a collection of static methods, there're a lot of
> static objects everywhere and it has a cumbersome initialization procedure
>

Agreed.

> 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

why do we need that? What's wrong with lib? The stuff in lib is targeted for a 
move outside of the kdevelop module anyways.  The platform just hasn't come 
far enough along where it seemed like a good idea to do that.

> - extract interfaces from PluginController, ProjectController,
> LanguageController and put them into koncrete/interfaces directory

Except that you don't say why we should do this. To me, it's not obvious, so 
you will need to elaborate. Please answer the following questions:

There is only one way to load plugins in KDE and that's via the KService 
mechanism, which is how PluginController works. Why do we need to make 
PluginController an abstract interface? What does it accomplish by changing 
it to an abstract interface? Why should we not centralize plugin loading and 
unloading for the whole platform in one place and make it available 
everywhere? PluginController is based off code in Kopete and we've not 
changed that class there for years, so there's obviously no problem with 
keeping it BC. What's the point of providing a platform if the plugin 
controller (which if we use your definition of the platform) is an abstract 
interface with no implementation?

Why do we need to make ProjectController an abstract interface? What does it 
accomplish by changing it to an abstract interface? What about project 
opening and closing can't be customized by leaving it the way it is and 
having users intercept the projectOpened(), projectClosing(), and 
projectClosed() signals?

Why do we need to make LanguageController an abstract interface? What does it 
accomplish by changing it to an abstract interface? Depending on what we do 
with Core, it won't hardly do anything except provide the currently active 
language (based on the file that currently has focus) and load language 
support plugins (which we can do just as easily in the PluginController). We 
could almost remove it.

> - 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

I disagree. I don't think we need Core anymore. I think we should just have 
normal singletons that can be referenced using self() or instance() or some 
other similarly named function. Less messy, and IMHO, better design. 

> - move anything else not related to the shell (and potentially useful to
>   quanta) into koncrete/shell

What purpose does that serve? The current layout may not be totally complete 
(BackgroundParser should be in the backgroundparser subdir for example) but 
it's very similar to what's been done in Qt and what's being done in kdelibs 
right now.

> - 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)
>

We already have this using the same extension interfaces mechanism we had in 
KDevelop 3.x. They work well so there's no point in getting rid of them. I 
don't see a reason to do anything you propose in the above paragraph. The 
language support plugins should know about their own background parsers. 

KDevBackgroundParser is meant to be an base background parser class that does 
some nice things for it's users like job and threading control. It is meant 
to be inherited from and extended by plugins.

> 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 ;)

I think we should wait with any branching until we decide what we're going to 
do. :) In my mind, what we have in terms of API is not so flawed but it's 
implementation definately could be better. I see a lot of cleaning that needs 
to be done, but I don't really feel like it's that bad (based on my vision of 
what the platform should be)

Like I've said before, I can be convinced to go along with pretty much 
anything. I don't do many things w/o a reason to do them, so you can't just 
say we need to do something without at least explaining why we need to do it 
and why it's better. I'm kinda dense like that. ;)

-- 
Matt