Direction of KDevelop4

[Matt Rogers]

On Monday 12 September 2005 07:56, Adam Treat wrote:
> 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 ;)
>

LOL, quite funny, but please no. ;)

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

break space brackets: i.e.

void good_function()
{

}

instead of 

void bad_function() {

}

spaces around parens is preferred but either one works (xemacs does the spaces 
automatically)
 i.e. ( arg1, arg2 ) instead of (arg1, arg2 ,arg3)

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

I agree with the no more useless comments part, but usefulness is in the eye 
of the beholder here and truth be told, i'd rather have more comments than no 
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.  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.
>

agreed.

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

I've already started thinking about it, and if I could find some more time, 
I'll open a branch (probably against trunk) so others can view and see my 
work. However, getting involved with the usability folks and the artists is 
definately a good idea.

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

Please provide a way to turn this off since some of us just want a straight 
list of files rather than grouping them by mimetype. :)
-- 
Matt