Direction of KDevelop4

[Adam Treat]

On Monday September 12 2005 9:27 am, Andras Mantia wrote:
> On Monday 12 September 2005 15:56, Adam Treat wrote:
> > 3.  A source code policy.  Currently, KDevelop's source code is
> >  I think we should adopt one coding style throughout KDevelop svn and
> > stick to it.  Pick one and stick to it.
>
> As KDevelop is modular, I think this won't work. And this was already
> discussed and the outcome was that we should have one coding style for
> the main libraries and interfaces and per-plugin coding style for the
> rest.

Well, what happens when I need to make a change to a plugin and can't 
determine which coding style it uses because styles differ even in the same 
file.  I can find many examples where the coding style isn't even consistent 
in the SAME FILE, let alone plugin or module.   Look at the examples I gave 
in my reply to Vladimir.  Note those are some of the most important files in 
all of kdevelop svn...

This can't continue!

It is ugly and makes things ten times as hard to work and see around.  I think 
all those clamoring for more comments are doing so because the source code is 
so bad/inconsistent.  If it were cleaned up and made proper, people wouldn't 
have to rely so much upon the comments.

> Altough I agree to comment these items, I think in other case comments
> are welcome as well. In some cases it's obvious for you when you code,
> but not for anyone else. So some extra (useful) comments do not hurt.
> And please use doxygen comments for the interfaces and libraries!

Then one should make their code more obvious.  We need a higher standard 
because currently the code is a mess and hard to work on.  I don't want more 
comments, I want _cleaner_code_ to begin with.  I've already stated that some 
code is inherently subtle and desiring comments, but this should be the 
_exception_ not the rule.

> Yes, we also discussed to rearrange the source code in the repository.
> The idea was:
> - kdevelop-framework: interfaces, common shell, common libraries. I
> would like to see here common plugins as well, like the "search in
> files" or VCS support (and maybe others that do not depend on the
> language support plugin).
> - kdevelop-languages: language support plugins (and other language
> specific plugins)
> - kdevelop-extra: whatever else ;-) Can be in trunk or extragear, I
> don't care.

Sounds much better than what we have now.

> One of the reasons of the mess in the UI is the KPart and XMLGUI
> framework and the fact that there are independent plugins. This can
> cause:
> - long menus with unneeded items
> - conflicting shortcuts
>
> Solution? I don't know if there is a good solution. :-(

The time to start brainstorming is on the horizon ;)

Adam

-- 
I'm running a Marathon in December!
HELP ME SAVE LIVES and Donate Today!
http://helpmesavelives.blogspot.com/