Direction of KDevelop4

Alexander Neundorf neundorf at
Mon Sep 12 22:07:02 UTC 2005


On Monday 12 September 2005 14: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.

I use it for embedded development, the "best KDE IDE" is not automatically the 
tool of choice for me. 

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

While it would be nice, you can't force all kdevelop committers to one coding 
style. KDE rule: "stick to the coding style in which the file is writing 

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

While useless comments are really useless, useless comments for you might not 
be useless for me, so if you would remove them I might miss them. I'd better 
encourage comments (I know I write too few comments myself and good code 
shouldn't need much comments at all etc., but we really shouldn't discourage 
(...what a useless comment ;-)

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

Just mark the plugins as experimental or something, but build and install them 
by default. Without this they will get less users, and maybe especially for 
an IDE less users means less developers (because IDE users *are* developers).

> 6.  I think we should get involved with a usabilty study and/or some
> artists participation over at  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

Just make sure that it stays easy to use with the keyboard (typing the letters 
jumps to the file name).

Work: alexander.neundorf at -
Home: neundorf at                -
      alex at               -

More information about the KDevelop-devel mailing list