Very good point. You guys have to work it out without causing any fork. Forks are OK when they are beneficial, in this case, I don't see any from renaming.
Here is a mid solution which others already presented in the e-mails with slight modification.

Please don't worry. If you look at the thread, you'll find out that nobody wants to fight to the death for just a name. We'll have the name issue sorted out as soon as we finish the rework of the core platform stuff. "Koncrete" wasn't the first proposed name and it won't be the last one.

About the fork... Judging from the replies to the email and IRC conversations I can assure you that nobody from current KDevelop contributors supports the idea of a fork.

It seems that the "New class" tool still do not allow to place .h and .cpp in two different directories.
Maybe I should report to bugs.kde.org..
At least now importing a class with .h and .cpp in two different dirs does not produce two different entries in the class tree.

This looks very good. this is the first kdevelop version that actualy starts for me, lets me create a new project with a sample application and run it. all this withou crashing!! i always wanted to start coding for kde, but until now kdevelop was too buggy for me. now i will take a closer look at it

500 bugs closed is impressive, and you managed to include quite a few useful additions while you were at it :) Good work guys, if only we had such a dedicated team ferretting out the bugs for other major KDE projects, we'd, well, be alot less buggy :D

I don't agree that we should leave PyKDE support to Eric3 (or Eric4). It doesn't have the concept of project types where you can create a standard sort of project such as a python KDE part or a python KDE application, in the way you can with KDevelop. I agree Detlev Offenbach is doing a brilliant job, but it would be very good if we could have some serious python support in KDevelop4 too. I believe there has been some separate work with python KDE project templates, such as python kparts or python kde kicker applets, but that has never been integrated with an IDE - and I believe it is really important that we should do something about that for KDE4.

I personally disagree. It's true that eric3 has a lot more features related to Python, but I still use KDevelop instead because eric has (IMO) a very cluttered interface that makes working with the program hard.

Rails? Python have the similar things like dijango and turbogears. Of course python has PyQt like RubyQt. I don't know musch about ruby, but I think python is qt-friendly at least like ruby. maybe better: i use some native kde apps programed with python but seems no one is programed by ruby.

I also got frustrated with KDevelop and tried eclipse (mainly for the code completion). However it was unbelievably slow! Also KDevelop 3.4 is significantly less buggy than previous releases (although a few new ones seemed to have creeped in).

On the plus side, the code formatter is a lot more useful, and the UI is a whole lot cleaner.

>a few new ones seemed to have creeped in
We'll have 3.4.1 to tackle those :)

As for code completion, as long as you use code completion databases only for libraries you use, it's amazingly fast. I prefer to have kdelibs, qt and libstdc++ completion only and experience no slowdowns.

As about completion quality, David Nolden put a lot of effort to make it complete every time and everywhere. So I highly recommend 3.4 as it is certainly better.

Thanks. I had to manually create/add database from /usr/include/C++ to have completion for STL.

cout.(still nothing)

Anyway, thanks for this vast improvement over previous versions. However, in MSVC I do not need to maualy create any databases - it is being created automaticaly according to what headers are included in the project. Is it so difficult to parse the project and create needed databases automatically?

There's an option to parse the included headers for autocompletion, but that feature is very time and memory consuming in KDevelop3.

For KDevelop4 this is a major point that we want to tackle.

Last but not least: Adding a database for the standard C++ lib is a bit of a problem, because its headers might lie anywhere on the system, for example here it is /usr/include/c++/, on gentoo its somewhere deep under /usr/lib/