KDE/kdevplatform

[Andreas Pakulat]

On 26.11.09 18:07:34, David Nolden wrote:
> 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:

I can't stand hacks. They tend to stick, especially in code that nobody
actively maintains or wathces (which is the case for the whole
sourcecode formatter stuff). I've seen far too many people drop by, drop
some code and vanish in the last 2 years of KDevelop4 to leave anything
in that has nobody who can be easily reached.

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

There's a huge difference between "unfinished" and "unsuable". And quite
frankly, bugzilla is the _only_ way to get an overview in which
stability-state we are. Unless you know all code parts of kdevelop
in-depth.

> I want the C++ thing to be stable, and usable.

My experience shows this is both fulfilled as far as a first release is
concerned. IMHO you need to think again about your expectations from the
4.0 release unless you want to work another 2 years on the codebase.

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

Well, except the bug that projects are not properly reloaded, IMHO
session-support is done. At this point we just need to find a good way
of figuring out what should be stored in the session and what should
not. Implementing that is simple.

As far as debugger goes, well its always been a problem. Vladimir
apparently has rather unstable timeframes for working on it. He promised
fixing and as far as I know there are exactly 2 major problems right now
(Locals and breakpoints set during debugging are not forwarded to gdb).
 
> > > 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.

Huh? Are you kidding? There's exactly 2 lines of source code that I
touched in code-generation and they were already "optional" if no
formatter was available.

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

I consider using gdb manual work too, so there's no difference to me in
both. Having to use gdb on the cli is just as cumbersome as having to
select a few lines and let kate add/remove indentation on them.

> which I hate, especially when it worked before, and the main motivation for 
> the regression is code-aesthetic reasons.

Its not code-aestethic reasons. Its maintainence nightmare. Nobody cared
about this code for the last months (except a minor bugfix) and I tried
to fix it up, but its not fixable in an easy way and has design flaws.
Unmaintainable code has to be removed at some point, so lets start early
(we removed tons of code already to playground).

Andreas

-- 
Beware of a dark-haired man with a loud tie.