useful stuff in lib/ (was Let's discuss KDevelop4 interfaces and shell)

[Jens Dagerbo]

On 1/19/07, Alexander Dymo <dymo at ukrpost.ua> wrote:
> > 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.?
>
> Yes, you have a point here. We shall just put background parser to its own
> directory and make a library (from your responce I guess that you agree
> with that). We can do this with all other useful things like
> editor integration, code models, whatever we have now in lib.
>
> Please don't get me wrong, I don't want platform to be something "abstract".
> I'm fine with keeping all that in lib/ but we just have to reorganize it and
> in my opinion we can do that in this way:
>
> (koncrete/ is what we call lib/ now)
>
> koncrete/interfaces
>         abstract interfaces for plugins to have access to platform stuff
> koncrete/sublime
>         my ui stuff
> koncrete/shell
>         core stuff like mainwindow implementation, plugin controler and
>         other controllers, profile engine
> koncrete/codeutils
>         catalog, code model and code proxy, background parser
> ... (other subdirectories)
>

I would like to see something like this. It looks good to me and
doesn't break too far from what we know worked in KDevelop.

About BC, we basically have 3 options as I see it:
1. Be really fucking careful
2. Use a d-pointer scheme common in libraries
3. Use interfaces - the way we did it in kdev3
(4. Use the sci-fi Qt based invocation scheme sketched by Alexander
and Roberto in that thread from 2005)

The first option is of course not realistic. Both 2 and 3 are proven
solutions, but 3 is imho much preferable. It gives us better
separation and *avoids linking* which the d-pointer scheme typically
does not. This is a very real benefit when working on a large codebase
with limited (cpu)time. KDevelop3 had this, and I would not want to
lose this benefit in KDevelop4.


// jens