Direction of KDevelop4

[Jens Herden]

Hi,

> 1.  A clear goal or mission statement ie, "To offer the best KDE/Qt
> development environment bar none."  I  think focusing on such a mission
> statement will provide a better direction for thinking about what we want
> to see in the new kdevelop.

I can imagine that a mission statement will have some kind of value for 
marketing. But it would not affect me much and I doubt that many other 
developers would be affected by such a statement. 
But thinking about the direction is indeed a very good idea.


> 2.  Rebranding in the future and a new development name now.  As a
> suggestion, how about 'Orange Julius' for a development name ;)

I do not care about this. Call it as you like.


> 3.  A source code policy.  Currently, KDevelop's source code is atrocious.
> Even in the new trunk branch, we have a dozen different coding styles with
> some individual files having more than one coding style.  This makes things
> very hard to read...  I think your coding style is brilliant and beautiful.
> It is very easy to read and clear.  I think we should adopt one coding
> style throughout KDevelop svn and stick to it.  Pick one and stick to it. 
> Add Kate modelines for everything and give us an astyle setting to use. 
> BTW, the astyle settings should be made a per project plugin, because
> different projects people work on have different astyles...

If a coding style is beautiful or not is definitely a matter of taste. Since 
people have different taste they have different coding style. That is life.
But I agree that there should be guidelines, but I do not see that the whole 
code must follow the same guidelines. Mixed style in one file should be 
avoided and cleaned if found. 
But personally I have no problems reading code from people with different 
styles. I see coding as a kind of art where people express themself in 
different styles, each with its own advantages and disadvantages. 

> 4.  Standards for kdevelop source.  No more useless comments.  Comments
> should only be necessary if:
> 	a) Something _really_difficult_ or unobvious is going on.
> 	b) It is a public library/interface and comments are needed for
> documentation.

"useless" for whom? I know many comments that could be removed without any 
doubt. But I also saw many comments that were helpfull for me to understand 
the code quicker and this was not only in really difficult situations. What 
might be useless for you can of course be usefull for others. Have mercy with 
people not as skilled as you.
Why should a non public libray/interface not get commented? Because it is 
internal and what is internal is only for people who do not need comments? 


> 5.  We should limit the amount of plugins/language parts in kdevelop's svn
> to only those that are best of breed and meet our new mission statement. 
> This means broken/buggy or unmaintained plugins should be removed from svn.
>  I think the only language parts that should go in kdevelop's svn are ones
> that enjoy wide usage among KDE developers.  

Why only KDE developers? I guess there are also people out there who do not 
develop for KDE with KDevelop. So the basic question is what is widely used 
from KDevelop. I have no idea how this question could be answered. But 
thinking only about KDE seems a bit shortsighted to me. 


> 7.  I am working on a replacement for the filelist plugin for kdevelop4
> called documentview.  The idea would basically copy the new qt4 designer
> widget list.  ie, it would list the currently opened documents by breaking
> them up by mimetype.  Ie, all .cpp files would be listed under a
> collapsable header called 'C++ Files' and all .h files would be listed
> under a collapsable header called 'Header Files' and all .ui files would be
> listed under a collapsable header called 'Qt Designer Files', etc, etc

Are you going to put the code for the project views in this plugin as well? 

Jens
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20050912/310ac3dd/attachment.sig>