Direction of KDevelop4

[Adam Treat]

On Monday September 12 2005 9:57 am, Andras Mantia wrote:
> > 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.

That's fine.  But for current plugins/modules where we can't determine the 
coding style intended (I dare say quite a few plugins/modules) that they 
should be cleaned up and given a uniform 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.

Well, hopefully, kdevelop4 will give us a chance to improve the quality and 
set a new standard for commits.  Yes, there will be hacks, but, once again, 
this should be the _exception_ not the rule.

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

Well, cleaning up the ones we do know is surely better than just saying 'we 
can't know all so do nothing'.  I would like the possibility if we know what 
might be loaded.

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

We choose.  Hopefully via a configuration file that can be changed and won't 
create any BC compatibility problems or undue dependencies.

> Andras

-- 
I'm running a Marathon in December!
HELP ME SAVE LIVES and Donate Today!
http://helpmesavelives.blogspot.com/