Direction of KDevelop4
amantia at kde.org
Mon Sep 12 15:27:02 UTC 2005
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
> 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
- kdevelop-extra: whatever else ;-) Can be in trunk or extragear, I
> 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
- 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
These problems might be solvable in the framework.
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
Size: 189 bytes
Desc: not available
More information about the KDevelop-devel