Direction of KDevelop4

[Vladimir Prus]

Hi Adam,

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

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

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

- Volodya