KDevelop4 architecture rework

[Roberto Raggi]

Hi!

Quoting Alexander Dymo <dymo at ukrpost.ua>:

> Hi!
> I've started the rework of the architecture in
> branches/work/kdevelop-sublime-integration today.

Thank you

>
> The goals are (as discussed previously):
> - to separate interfaces from shell
> - to clean up both shell and interfaces
> - to review some design decisions in favor of known working solutions
>   from KDevelop3.

Please, try to reduce the number of files(and classes) in kdevelop/lib. 
At the moment we have something like 202 files in kdevelop/lib. The 
library is not exactly accessible to normal developers.

Interesting stuff I noticed while reading the source code

- The Koncrete namespace

I know a lot of poople think that weird names for new KDE projects is 
cool, but if you ask me this is 100% stupid. It is OK to have a cool 
name for our code base(like gideon for KDevelop3), but do we really 
have to use these cool names in our *PUBLIC API*!

We are working on KDevelop! Please use KDev* as prefix. If this is not 
good for you, then you should consider to start a new project, name it 
Koncrete and put it in kdenonbeta.

- useless classes in our public api

For example, kdevelop/lib/kdevast.h. kdevast.h contains the declaration 
of Koncrete::AST. This class has no ctor/dtor, one public member (a 
pointer to the LanguageSupport) and two (non virtual) functions. I want 
to ask you, do we really need this class in our library! Another 
awesome example is  kdevelop/lib/kdevcodedelegate.h. It declares 
Koncrete::CodeDelegate. CodeDelegate doesn't have any functions or 
members at all. It just has a ctor and a dtor. Again, why this stuff is 
in our public api! kdevperstenthash.h should be removed too. Same story 
for kdevparsejob.h.
Another thing that is very interesting is 
Koncrete::LanguageSupport/Koncrete::LanguageController. Do you really 
want LanguageController in our public api?

ciao robe

>
> At this point I've refactored Core (made it look and work like KDevAPI
> in KDevelop3), PluginController (mostly cleanups) and MainWindow
> (it's now Sublime::MainWindow and just waits for more stuff from
> Sublime library to be used).
>
> So far the consequences are: clearer initialization procedure,
> minimal interfaces and (still) working plugin architecture.
> I'll keep you informed as the rework continues. Feel free to contribute
> to this cleanup effort, but just make sure you contacted me at irc before
> you start over.
> I'd like to refactor Document/Part controllers by myself. Also MainWindow
> is my job too. But everything else needs attention as well. For example, the
> independent task would be to experiment with inter-plugin deps and BC ideas
> (see http://lists.kde.org/?l=kdevelop-devel&m=112620787223741&w=2)
> and try to make use of them in KDevelop extension interfaces mechanism.
> If everything works ok, project manager needs to be modified so it provides
> extension interfaces.
>
> Another task would be to sort out utility stuff that still lies everywhere
> in lib/. Take a look at Matt's reply to "useful stuff in lib" thread for
> hints.
>
> Also there're smaller tasks. Removing unused code, checking dependencies
> between files and removing extra #include's, reformatting
> the code when nesessary.
>
>
> _______________________________________________
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.