Direction of KDevelop4
treat at kde.org
Mon Sep 12 14:53:07 UTC 2005
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
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
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
I'm running a Marathon in December!
HELP ME SAVE LIVES and Donate Today!
More information about the KDevelop-devel