KDE/kdevplatform

[Andreas Pakulat]

On 26.11.09 13:54:53, David Nolden wrote:
> 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.

Did you look at the code? I did and its not easy to do the things you
outlined above without some serious changes in the codebase.

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

Re-indenting certain parts is definetly a lot easier than having to write
all the subclasses methods manually. Of course for something like 

class Foo
{
};

There's not much difference (but there even isn't with a formatter). But if
you want to override a couple of functions or subclass from multiple
classes the amount of time needed for reformatting is a lot lower than
writing it manually.

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

Well, if I look at the reports scheduled to be a "must have" in 4.0.0 then
I'm pretty confident its doable in the next 5-6 weeks that we have. If
bugzilla doesn't reflect what your view onto kdevelop then you should start
writing bugreports.

Note: We don't be delivering a perfect product and thats not our aim
anyway. We want to deliver a well-working C++ IDE and we need to deliver it
rather sooner than later. We need to get this out there in a reasonable
shape.
 
> 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.

Feature freeze doesn't just mean no new features. It also means no huge
code-changes (to me at least) because that has the risk of introducing lots
of new bugs.

Andreas

-- 
Don't you wish you had more energy... or less ambition?