Direction of KDevelop4

[Andras Mantia]

On Monday 12 September 2005 15:56, Adam Treat wrote:
> 3.  A source code policy.  Currently, KDevelop's source code is
[...]
>  I think we should adopt one coding style throughout KDevelop svn and
> stick to it.  Pick one and stick to it.
As KDevelop is modular, I think this won't work. And this was already 
discussed and the outcome was that we should have one coding style for 
the main libraries and interfaces and per-plugin coding style for the 
rest. 

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

Altough I agree to comment these items, I think in other case comments 
are welcome as well. In some cases it's obvious for you when you code, 
but not for anyone else. So some extra (useful) comments do not hurt.
And please use doxygen comments for the interfaces and libraries!

> 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.
Yes, we also discussed to rearrange the source code in the repository. 
The idea was:
- kdevelop-framework: interfaces, common shell, common libraries. I 
would like to see here common plugins as well, like the "search in 
files" or VCS support (and maybe others that do not depend on the 
language support plugin). 
- kdevelop-languages: language support plugins (and other language 
specific plugins)
- kdevelop-extra: whatever else ;-) Can be in trunk or extragear, I 
don't care.

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

One of the reasons of the mess in the UI is the KPart and XMLGUI 
framework and the fact that there are independent plugins. This can 
cause:
- long menus with unneeded items
- conflicting shortcuts

Solution? I don't know if there is a good solution. :-(

Another problem is the inability to fine tune the context menus is 
KDevelop. There are too little contexts one can use, and this makes 
items appear e.g. in the tab menu, altough they don't really make sense 
there. Same for other menus. It is also a problem that you cannot 
control where the entries appear, and this way the context menus look 
disorganized.
 These problems might be solvable in the framework.

Andras
-- 
Quanta Plus developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20050912/f0c7a01d/attachment.sig>