KDE/kdevplatform

David Nolden zwabel at googlemail.com
Thu Nov 26 12:54:53 UTC 2009


Am Donnerstag 26 November 2009 13:03:38 schrieb Andreas Pakulat:
> On 26.11.09 09:45:00, David Nolden wrote:
> > Am Donnerstag 26 November 2009 00:27:44 schrieb Andreas Pakulat:
> > > > What is the exact troubles this code is causing,
> > > > except that it's not pretty? It hasn't ever crashed here..
> > >
> > > Disable both formatters and try to configure it. And thats just the
> > > beginning. As I said it keeps around pointers of things it shouldn't,
> > > which can make it crash easily when plugins are loaded/unloaded (think
> > > about the sessions).
> > >
> > > Additionally part of this was public API that exposed far too much
> > > internals. Even if we don't guarantee BC we don't have to clutter our
> > > API from the start either. And its not like this was used in a lot of
> > > places (I wouldn't have disabled the code in that case) already, so it
> > > was mostly a manual thing to do. And running astyle from a commandline
> > > isn't that hard ;)
> >
> > Yes but this did allow partial code-snippets to be reformatted in
> > context, which is a lot different from running astyle in the
> > command-line.
> >
> > If there is those problems, then we could also just cut out the thing
> > down a bit by disallowing to change the source-formatter:
> > - Remove all source-formatters expect of astyle, forbid disabling source-
> > formatters
> >
> > Or we could create and enable one source-formatter that calls a
> > command-line tool that it reads from somewhere in the source-tree, using
> > a
> > ".kdev_formatting" file, and then simply disable the complete GUI.
> 
> All of that involves quite some code-changes and hence are not accetable at
> this point in the release cycle.
The first part (aka.: disable some functionality, instead of disabling 
everything) would be totally acceptable, as the required changes would 
inherently be much less significant than removing the plugin altogether.

> > The problem is, that we really _need_ source formatting, as without a
> > source- formatter, the C++ support will create completely messy code in
> > some places.
> 
> I disagree on that, having the code formatted according to some style is a
> nice and useful feature. But not something you absolutely need for being
> able to work with an IDE.
> 
> If you disagree with that, I suggest you re-open the discussion about
> releasing with KDE4.4, because there's no way to change this at this point.

What is the sense of a class-wizard when you need to manually go through the 
whole file, and re-format it manually? It's probably even less effort writing 
the whole class by hand. The same goes for the automatic creating of 
definitions, slots, etc.

Completely removing source formatting cripples many of the c++ features to a 
level that they are not really useful any more (in the sense of speeding up 
your work). 

So if that is the only way then yes, we should release separately from KDE 
4.4. As I said before, I'm anyway confident that we won't be _ready_ in 2 
months.

We should stay in feature freeze, but with another interpretation than the one 
you're applying. Fixing the source-formatter is not a new feature, no matter 
how much code-changes would be involved.

Greetings, David




More information about the KDevelop-devel mailing list