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.
Dot Categories:
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!
I +++++++++++++++++++++++++++++++++++++++++++++++++
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.
Wow, what a lame name. Koncrete. The IDE for 10-year-old-boys-who-enjoy-stupid-names. WTF?
Yikes, it reminds me of this old joke:
http://www.geocities.com/rcwoolley/
:)
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.
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.
How about "Kodex"?
You know, that's actually pretty damn good. Drop the K, make it 'Codex', and I'm very much sold. :)
Thank you to all the people who continue to put work into this great software. Really great release.
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.
Don't forget to digg the story and help spread the good news:
http://digg.com/software/KDevelop_3_4_Released
dugg
The Qt4 support is great. I've just started working on a new Qt4 project and KDevelop is making it really easy.
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
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 :)
for the best IDE on unix systems.
Keep up the great work please!
wow, you want to give them tanks? that may be dangerous if they start playing around :-)
Nevertheless, hooray for the kdevelop team!
Thanks too for such a great release!
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
Thanks for the informative presentation, and keep up the great work! KDevelop is my favourite IDE thanks to you guys and girl(s).
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
What about the Python support in KDevelop? How good is it? Usable?
Thanks,
Florian
For a good python IDE use eric3. KDevelop can't compete with it.
"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.
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.
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.
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.
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...
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.
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)
Make sure you created code completion databases as described in http://www.kdevelop.org/mediawiki/index.php/FAQ
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.
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/
>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.
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.
Today, I can use MonoDevelop for Mono developing, but it is not good as KDevelop.