JAN
27
2007

KDevelop 3.4 Brings Many New Features

KDevelop 3.4 has been released, bringing many new features to KDE's Integrated Development Environment. The first major release in over a year closes more than 500 bugs. There is an impressive list of additional features including improved Qt 4 support, new debugging abilities, more attractive default user interface layout and improvements for C++, Ruby and PHP support. Packages are available for Kubuntu and openSUSE with unofficial builds for several others on the download page. Update: The developers have put together a slideshow to showcase the new features.

Comments

Hi,

the new Kdevelop is great.... thanks so much! I am excited about what is planed for Kdevelop 4...please rock on! The only thing I am worried about is a potential fork of the project

http://lists.kde.org/?l=kdevelop-devel&m=116940111208187&w=2
http://lists.kde.org/?l=kdevelop-devel&m=116939723404129&w=2

please don't do this because of a name!


By MK at Sat, 2007/01/27 - 6:00am

I +++++++++++++++++++++++++++++++++++++++++++++++++


By David at Sat, 2007/01/27 - 6:00am

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.

KDev for Kdevlop. indicative, meaningful, & short,
KDevForm, KdevPlat, KDevBase, KDevPlatform for KDevelop Platform.

Get a resolution without any forking PLEASE!!! Otherwise you are wasting your novel efforts for nothing.


By Abe at Sat, 2007/01/27 - 6:00am

Wow, what a lame name. Koncrete. The IDE for 10-year-old-boys-who-enjoy-stupid-names. WTF?


By AC at Sat, 2007/01/27 - 6:00am

Yikes, it reminds me of this old joke:

http://www.geocities.com/rcwoolley/

:)


By Colin at Sun, 2007/01/28 - 6:00am

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.


By Alexander Dymo at Sat, 2007/01/27 - 6:00am

I don't like the name Koncrete... it just doesn't sound any better than KDevelop. Why not try to come up with something like the other main KDE 4 projects: Plasma, Phonon, Solid, Decibel.


By ac at Sun, 2007/01/28 - 6:00am

How about "Kodex"?


By Daniel at Mon, 2007/01/29 - 6:00am

You know, that's actually pretty damn good. Drop the K, make it 'Codex', and I'm very much sold. :)


By A.C. at Mon, 2007/01/29 - 6:00am

Thank you to all the people who continue to put work into this great software. Really great release.


By ac at Sat, 2007/01/27 - 6:00am

Definitely true!

The configuration of this release just got soo clean.. :)

I notice it in many places, the class browser with bold method names, the RMB settings of the output display, and global settings. It's great to see so many improvements there.


By Diederik van de... at Sun, 2007/01/28 - 6:00am

Don't forget to digg the story and help spread the good news:
http://digg.com/software/KDevelop_3_4_Released


By Tsiolkovsky at Sat, 2007/01/27 - 6:00am

dugg


By Mark Kretschmann at Sat, 2007/01/27 - 6:00am

The Qt4 support is great. I've just started working on a new Qt4 project and KDevelop is making it really easy.


By james at Sat, 2007/01/27 - 6:00am

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.


By and. at Sat, 2007/01/27 - 6:00am

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


By Beat Wolf at Sat, 2007/01/27 - 6:00am

Oops, honestly it should have worked before too ;) Don't forget to post a bug report if you see crashes in the future please. Our bug squad (Andreas and Jens) are eager to see new bugs :)


By Alexander Dymo at Sat, 2007/01/27 - 6:00am

for the best IDE on unix systems.
Keep up the great work please!


By David at Sat, 2007/01/27 - 6:00am

wow, you want to give them tanks? that may be dangerous if they start playing around :-)

Nevertheless, hooray for the kdevelop team!


By infopipe at Sun, 2007/01/28 - 6:00am

Thanks too for such a great release!


By Sebastian Sauer at Sun, 2007/01/28 - 6:00am

We also prepared a little presentation for some of the new features and improvements:
http://www.kdevelop.org/3.4/showcase.pdf
http://www.kdevelop.org/3.4/showcase.odp


By Alexander Dymo at Sat, 2007/01/27 - 6:00am

Thanks for the informative presentation, and keep up the great work! KDevelop is my favourite IDE thanks to you guys and girl(s).


By Claire at Sun, 2007/01/28 - 6:00am

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


By Ben Axnick at Sun, 2007/01/28 - 6:00am

What about the Python support in KDevelop? How good is it? Usable?

Thanks,

Florian


By Florian at Sun, 2007/01/28 - 6:00am

For a good python IDE use eric3. KDevelop can't compete with it.


By Andreas Pakulat at Sun, 2007/01/28 - 6:00am

"For a good python IDE use eric3. KDevelop can't compete with it."

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.


By Richard Dale at Sun, 2007/01/28 - 6:00am

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.


By Luca Beltrame at Tue, 2007/01/30 - 6:00am

Since the ruby will be support seriously, why the python not?

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.


By JackPhil at Wed, 2007/02/21 - 6:00am

Boy, I have mixed feelings about the KDevelop team and KDevelop.

I tried KDevelop for a project a couple years ago and it was very buggy. Support and interest and dealing with these issues was non existant. I wasted a ton of time with KDevelop !

Shortly thereafter I moved to Eclipse and I haven't looked back. The only thing that Eclipse doesn't do for me that KDevelop does is visual Qt development, but that is a pretty major thing !

I don't know what to think about this release. I don't doubt they fixed 500 bugs because there was a ton of them !

I'll have a look at the new release of KDevelop, but its going to have to really wow me to earn back my trust.


By me at Sun, 2007/01/28 - 6:00am

Well.. since you no doubt made bug reports for the issues you found (right?), it should be trivial for you to find out if the problems are fixed or not...


By teatime at Sun, 2007/01/28 - 6:00am

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.


By Tim at Sun, 2007/01/28 - 6:00am

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


By Alexander Dymo at Sun, 2007/01/28 - 6:00am

I just installed new KDevelop 3.4 from Debian unstable. It autocompletes nothing.

E.g.:

MyClass o;
o.(nothing happens, Ctrl-Space works)

cout.(nothing happens)

std::(nothing happens)

std::vector v;
v.(nothing happens)

What's wrong? (I have CTags installed)


By zack at Tue, 2007/01/30 - 6:00am

Make sure you created code completion databases as described in http://www.kdevelop.org/mediawiki/index.php/FAQ


By Alexander Dymo at Tue, 2007/01/30 - 6:00am

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?

And, IMO standard C/C++ library should be autocompleted by default.


By zack at Tue, 2007/01/30 - 6:00am

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/


By Andreas Pakulat at Tue, 2007/01/30 - 6:00am

>its headers might lie anywhere on the system
If the compiler can get the information about where to get the headers, then it should be no problem for the IDE as well.


By Dom at Sat, 2007/03/24 - 5:00am

It's necessary to close and reopen the file after auto-completion was enabled to make it trigger automatically. This is a bug that is fixed in svn.


By David Nolden at Sat, 2007/03/31 - 5:00am

Today, I can use MonoDevelop for Mono developing, but it is not good as KDevelop.


By Aceler at Mon, 2007/01/29 - 6:00am