Direction of KDevelop4

[Adam Treat]

Hi Roberto, All,

I've been working on trunk/kdevelop over the weekend and have several 
questions/ideas I want to run past you.

The first concerns future directions of KDevelop.  As the new maintainer I 
would love if you could write an email or post a page on the wiki detailing 
what you want to see and what goals you have for kdevelop4.  To get you 
started, and for you to consider, here are some of the things I would like to 
see:

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.

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

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

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.

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.  These include C++ obviously, and 
perhaps Ruby or one of the other bindings.  All plugins/language parts 
removed from KDevelop svn could,  of course, be maintained elsewhere.  
Perhaps a kdevelop-extras module or perhaps in extragear/playground as the 
case may be.

6.  I think we should get involved with a usabilty study and/or some artists 
participation over at kde-artists.org.  Our UI as is very convoluted.  I want 
to see something simpler and more elegant for kdevelop4.  I don't know what 
that is, but I think we should start thinking about it.

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

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