Direction of KDevelop4
ghost at cs.msu.su
Mon Sep 12 15:09:05 UTC 2005
> 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 ;)
> 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
FWIW, when getting hold of debugger code, I really wished it has much more
comments! There were a lot of code which function was obvious, but it's was
not clear why the code is needed, and how it fits in the overall picture.
Generally, I never seen a piece of software with too much comments, so we
should strive for more comments, not less.
> 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...
Again, FWIW, except for basic indent (2 or 4), I don't see any effect of
coding style on readability.
> 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
> 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.
Definitely. But probably the first step should not be asking artists or
usability experts, but users about the scenarious where KDevelop is not
optimal. As an example, debugging is very inconvenient when you have to
switch between two different targets. As another example, KDevelop is not
very convenient for browsing unfamiliar codebase -- it's not possible to
click on function/class name and go to definition, even though parser
probably has this information already. Users might know much more such use
More information about the KDevelop-devel