Direction of KDevelop4
Alexander Neundorf
neundorf at kde.org
Mon Sep 12 22:07:02 UTC 2005
Hi,
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
mostly"
> 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
commenting).
(...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 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.
Yes.
> 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).
Bye
Alex
--
Work: alexander.neundorf at jenoptik.com - http://www.jenoptik-los.de
Home: neundorf at kde.org - http://www.kde.org
alex at neundorf.net - http://www.neundorf.net
More information about the KDevelop-devel
mailing list