Breaking news! The KDevelop Team will release version 1.3 of its C/C++ IDE for UNIX within the next couple of weeks. The new release has a lot of new features regarding KDE 2 and Qt 2.2 development, particularly a project file generator which creates a project file out of your existing automake/autoconf project on the fly so you can start working with KDevelop on your former project within seconds. I´ve tried this last night with the kdebase module - and it worked!

Furthermore, the new version supports the new Qt Designer and Linguist (so you can create translations for your Qt 2.2 project just like for a KDE project type) and the KDE 2.0/Qt-2.2 templates are based on KDE´s /admin directory (so you can turn your Qt project into a KDE project with little change). Additionally, the KDE 2/Qt2.2 projects make use of the new API with XML, KAction and QAction stuff. Finally the new KDE 2.0 Development Book will be included (hopefully it´ll be released soon!), so KDevelop will be your first shot for KDE 2.0 Development.

Comments

I use KDE Studio for developing in KDE2 ( see the website of www.thekompany.com ). It has KDE2 support for a long time and run native on KDE2 !! I use the CVS snapshop version, very cool, it also has Designer support etc.

KDevelop won the third place directly after GCC and CodeWarrior. We´re doing it for free, whoever wants to use it, use it. We´re helping everyone in problems and invite everyone helping to improve KDevelop. And most importantly, the code is almost a 100% written by our team - while I won´t make a comment about other IDE´s...

That is THE real show stopper.
There are no more QT 1.xx packages available for debian (woody), kde1 never was.
So where is the reason to give kdevelop a try?
It still depends on anachronistic software.

That is the reason to use kdevelop: it's a damn good IDE! What more reason do you need?
There are other IDE available. Before I know myself, which of them are damn good, I must try them. And I just don't give it a try, if it is not a native KDE2 app.
There are some apps which I'm missing from KDE1, e.g. krabber, but as long as they are not ported, I just live without them.
But, I can live without rabbing CDs for a while, but I need to build some small apps NOW, so I take what is available now _and_ fit my needs.

That is THE real show stopper. There are no more QT 1.xx packages available for debian (woody), kde1 never was. So where is the reason to give kdevelop a try? It still
depends on anachronistic software.

I think KDE packages were made available for Debian in the non-free branch. If qt is no longer available that's Debian's fault, and in any event you can compile qt yourself. Qt 1.4 -- which currently runs on millions of computers -- is hardly "anachronistic".

I'm sure the KDevelop team is working on upgrading to KDE 2, but it takes a bit of time. Try learning the virtue of patience, or roll up your sleeves and help port it to KDE 2 ;-)

I'm sure the KDevelop team is working on upgrading to KDE 2, but it takes a bit of time. Try learning the virtue of patience, or roll up your sleeves and help port it to KDE 2 ;-)
Maybe I would have done that, but a look into the daily snapshot shows, that even the current code depends on qt1.
So in the world of free software, I have the choice just to chose another IDE.
To make my statement clearer:

I see what great work has been kdevelop 1.x. Thanks to the programming team.

I am sureley able to fetch all tarballs, and build everything myself. But I just don't want to. I want to have (now where KDE2 is released) an IDE that runs on KDE2.

And I think, many people have the same opinion. So, what I mean with the "show stopper": If KDevelop 2.x isn't available (even as a Beta) soon enough, many people will just switch to another IDE.

>If KDevelop 2.x isn't available (even as a Beta) soon enough, many people will just switch to another IDE

Yes, but please consider that KDevelop isn't a product by a company or similar. KDevelop is a community project and everyone can help to implement it.
A KDevelop2 release will only depends on how much help the project got, NOT when it's time to release something.

One very good point of you, I even use it myself when arguing about opensource. It is released, when it is ready.

Just to make it clear again, I'm not demanding anything, but I would have loved to have a KDE2 based Kdevelop NOW.

If it is possible for me to help out finishing KDevelop2 (or get it to a usable beta), I'm pleased to do so, but I want a straight environment.

The "SHOW STOPPER" was not meant to offset anybody, just to impress my feelings.
Yeap, I still say "anachronistic" to QT1/KDE1.x (it become, when GNOME 1.2 was released), but I know that everybody producing free software has the right to do with it, what he wants.
I just urge that's bad for KDevelop to release a "clean" 2.x version too late.
kudos, tracer

KDE 1.x was never officially supported in Debian due to the licensing battle. Now that KDE2 solves this, I'm not sure why the KDE 1.x "unofficial" tree disappeared -- you'd have to ask the individual person who maintained it.

In any case, the lazy thing to do is obtain the 1.x RPM for what you need, then "alien" it to a proper .deb file and dpkg -i it.

Alien isn't the preferred method of obtaining debian packages, but it works great for *non-system critical* software (i.e. this should be fine but don't alien XFree86 4.0!)

KDE 1.x was never officially supported in Debian due to the licensing battle. Now that KDE2 solves this, I'm not sure why the KDE 1.x "unofficial" tree disappeared
It hasn't disappeared. It's still available at tdyc.com. Just qt1 has dissappered from debian.

In any case, the lazy thing to do is obtain the 1.x RPM for what you need, then "alien" it to a proper .deb file and dpkg -i it.

Before I would alien an rpm, I would prefer to build it myself.

Alien isn't the preferred method of obtaining debian packages, but it works great for non-system critical software (i.e. this should be fine but don't alien XFree86 4.0!)

Theres no need for such a thing. Have a look at the xfree86 task force (www.debian.org/~branden).
There are binaries for IIRC i386 and sparc.

Well there is a new IDE coming for perl and python. Its based on Mozilla being produced by activestate.
Its called Komodo and they just had a Technology preview release for just win 2000, but they will have versions for Linux as well.http://www.activestate.com/Products/Komodo/index.html

Seriously, for some it may not be important but many of us migrating ex-windows-programmers really have become dependant on a good IDE. KDevelop has been good (and very stable) for quite a while now, and I've done some smaller qt-experimentation programs with it, but this is a real killer feature since almost all programs distributed as source use automake/autoconf and this will help developers trying to get on board on existing projects.

From the comments posted so far, I understand that KDevelop 1.3 will require Qt 1.44 and Kde 1.12, at least the support and libs. It will not be based on Qt 2.21 and Kde 2.0, although it will generate Kde 2 compatible code if so desired. If this understanding is incorrect please inform.

I also understand that a Qt 2.21/Kde 2.0 based KDevelop is also being worked on. When will a usable version be available? I've compiled the snapshots a few times over the last few months, but not within the last few weeks. It compiled but was mostly non-functional.

Back when I was using kde 1.12 Kdevelop was very, very nice, even though I didn't use it much as I was not doing much Kde app development then. Looks like I'll have to reinstall Qt 1.44 and Kde 1.12 just to use it again. The built in debugger and class browser is worth it, in my opinion.

I guess the focus will shift to a native Qt 2.21/Kde 2 version after the release of 1.3. An estimate on when the new version will be available (a usable beta that is mostly functional, not perfect) would be greatly appreciated. Also, if the current snapshots are halfway usable now that would be better than nothing.

> When can we expect a KDevelop 2.0 version which will run under KDE2.0
Currently we have only 3 or 4 active developers which started rewrite KDevelop. Rewriting is necessary because of the huge feature list which forces to a new approach to make all wishes possible. That's why do not expect a finished version 2.0 in the next half year.

> is there already a release schedule ?
Not in the current state of rewriting. But we could need some more developers. Interested?

But there will be KDevelop-1.3 in 1 or 2 months. It is mainly a reaction to TT's Designer, Qt-Linguist, KDE2 release, Qt-2.2

Really, KDevelop should be ported to KDE2.0/Qt2.2.1 as soon as possible. KDE2.0/Qt2.2.1 is so much better than KDE1.1.2/Qt1.4* that I think it is just not worth trying to stick with this framework. So,
please, port it to KDE2.0/Qt2.2.1, it will be
better for everyone. And people who mantain their
KDE1.* applications should also port them to KDE2.0 - it not so much work. I have ported a quite complex application from Qt1.44 to Qt2.0 in less than one hour, so...

It seems that the KDevelop team decided to make the kde2 port and a rewrite for new features at the same time. Unfortunately the latter seems to have taken longer time than planned. I don't know how much effort would it take to port the 1.3-tree to KDE2.0 separately, but it would be nice not to depend on those soo old kde1/qt1-libraries while waiting for the KDevelop2.0 :)

I don't know how much effort would it take to port the 1.3-tree to KDE2.0 separately, but it would be nice not to depend on those soo old kde1/qt1-libraries while waiting for the KDevelop2.0 :)
Maybe one could make a cvs split, at least till the "original" version will compile against current libs?

I can't get even kdevelop 1.2 installed. I'm using KDE2, which removed KDE1.1.2 when I installed it. Kdevelop requires KDE1 libs, but I can't find KDE1 libs RPMs any longer from anywhere! Especially for RedHat 6.2. I don't want to compile them.

Why on earth was necessary to remove all KDE1.1.2 directories from all mirrors????

Yeh, thanks. They seem to be in RH6.2 install directories too. But it would have been nice to find those from the kde/stable directories in FTP sites. Requires too much thinking to find them elsewhere... 8-/

Sheep. Using the RH6.2 libs was really a mess. Had to fight a day before I got it working.

The problem is that KDE2 wants to be installed in /usr. It doesn't like to be relocated, for some reason. But KDE1 wants to be installed there too. So, I relocated KDE1 to /opt/kde1. Fine.

First problem is that the kdevelop-autoconf-whatever default path for KDE includes is /usr/include/kde. Ok, edit the acinclude.m4.in manually to change that to /opt/kde1/lib. Of course the automation doesn't now work on other machines, but what the hell.

Second problem is that the rpm relocate did not appropriately alter libkdecore.la, now in /opt/kde1/lib. It internally points to /usr/lib, where the wrong version of libkdecore is, so you have to change that too.

Hey, it works now (at least on this machine)! A mess, eh?

I really wonder how a beginner could ever get the program working under KDE2.

It also seems that kdevelop doesn't know how to generate Qt-2.2.1 dialog sources. Thus, can't do my project with KDE2/Qt2.

I would rather not clutter up my hard drive with obsolete libraries... Sorry, but that is just how I am.

But since it is _my_ harddrive and not yours, I will wait for KDevelop 2.0 before I install it.

It is a shame that they didn't port to 2.0 first, then start adding features to the new system... That way they would have only had one unknown at a time... This way when they run into a problem developing a new feature they won't be sure if it is a QT 2.0 bug, or an implementation problem.

Solving for one variable is always easier than solving for two variables. It would have gone much faster.

I ported KDevelop to KDE2.0 about 14 months ago,
without adding any features. It turned out that the
codebase was in such a state that it would get
completely unmaintainable when adding new
features. So I introduced a new component system
which made it much easier to modularize KDevelop
and separate its subsystems into separate units.
Later we used KParts to put the whole component
system on a more advanced foundation. So your
way of describing the KDevelop history is completely
wrong.

What's also wrong is that Qt 2.0 are a problem. Of the
whole code KDevelop is based on, Qt is definitely
the most stable.

You don't need all of KDE 1.0
Just QT 1.45 and the KDE 1.1.2 libraries.
I'm running KDE 2.0, and have KDevelop running this way. It's only really another 10Meg or so ( over and above KDK 1.2 that is ), and you can delete em from your hard drive when KDevelop 2 comes out ;-).
If you're that straped for space, then I dont know what else to tell ya *grin*