KDE/kdevplatform

David Nolden zwabel at googlemail.com
Thu Nov 26 17:07:34 UTC 2009


Am Donnerstag 26 November 2009 14:24:01 schrieb Andreas Pakulat:
> 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.
I didn't look at it. But I'm quite sure that it's only hard if you want to do 
it properly. A simple hack would be fairly easy: Just don't compile all 
source-formatters except of astyle, disable the UI to disable formatters, 
change the configuration-option that chooses a formatter to another name, and 
let it default to astyle.

Sure, it would be damn ugly, but at least it would not affect the C++ support 
negatively, and just for the 4.0 release it would 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.
> 
> 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.
I don't need bugzilla to see that KDevelop4 is unfinished. I want the C++ 
thing to be stable, and usable. It doesn't have to be perfect, but at least 
all the crash bugs should be fixed. I will not have a lot of time in the very 
close future though as I will still be learning for another exam, but I 
_think_ that I can do that. However I also see the other parts of the IDE not 
finishing up in the pace it would be required to release in 2 months (Session 
support and debugger come into my mind).

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

> > 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.
The problem is that by removing this feature wholly, you introduce new bugs in 
the code-generation. I consider the source-formatter much more important than 
for example the debugger. If there's no debugger then you can use 'gdb' 
instead, but the only replacement for the source formatter is manual work, 
which I hate, especially when it worked before, and the main motivation for 
the regression is code-aesthetic reasons.

We do not need to have a perfect first release, but it's big strength should 
be "writing code", and basic automatic source-formatting is a part of that.

Greetings, David




More information about the KDevelop-devel mailing list