Direction of KDevelop4
amantia at kde.org
Mon Sep 12 16:07:02 UTC 2005
On Monday 12 September 2005 16:46, Adam Treat wrote:
> On Monday September 12 2005 9:27 am, Andras Mantia wrote:
> > 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.
> Well, what happens when I need to make a change to a plugin and can't
> determine which coding style it uses because styles differ even in
> the same file. I can find many examples where the coding style isn't
> even consistent in the SAME FILE, let alone plugin or module. Look
> at the examples I gave in my reply to Vladimir. Note those are some
> of the most important files in all of kdevelop svn...
This is not why I was saying. I was saying that coding style should not
be global, but per plugin. So if the maintainer of a plugin uses 4
spaces to indent, the other is using 2, we should follow their style if
we change the code. But of course the maintainers should be consistent
to use their own style all throughout the plugin and use
Kate/Vi/Emacs/whatever variables in it, so others know the style.
> Then one should make their code more obvious. We need a higher
> standard because currently the code is a mess and hard to work on.
You cannot get rid of hacks unless you (or a quality team) review all
the code that gets committed. So believe it or not, there will be hack,
ugly code and things that needs to be commented.
> > 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. :-(
> The time to start brainstorming is on the horizon ;)
Yes. A way to deal is that we remove unneeded entries/actions. But this
can be done only for parts we know. So we know that if the Kate part is
loaded, we don't need the (random pickup) View -> Switch to command
line. But if a random part is loaded, we don't know what we need or we
Conflicting shortcuts might be easier to solve: on part loading iterate
through the shortcuts and if they conflict with some main KDevelop
shortcut, than disable them. The problem: there are only a few (if
there are any) KDevelop shortcuts, almost all of them are in plugins.
What if the debugger plugin wants to use F7, the search plugin wants to
use it as well, and Katepart already uses it? Either we know which
plugin is the most important and gets F7, or the first one is served
Other ideas are welcome. ;-)
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