Direction of KDevelop4

[Andras Mantia]

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 
don't need.
 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 
with it.

Other ideas are welcome. ;-)

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/8bca74ac/attachment.sig>