Direction of KDevelop4
treat at kde.org
Mon Sep 12 16:20:10 UTC 2005
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.
I'm running a Marathon in December!
HELP ME SAVE LIVES and Donate Today!
More information about the KDevelop-devel