The KDevelop team announces the availablility of KDevelop 3.0 Alpha 4a (yes, 4a). In the more than 3 months since the last release, many new features have been added, bugs have been squashed, and existing features have been refined and polished. Downloads are available via the KDE mirrors. Direct links to packages can be found at the KDevelop download page.
Since the third alpha release, the developers have been extremely busy. Some of the noted improvements are:
- New File Creation Interface, standardized across all of KDevelop
- New Search/Replace Part for multiple files, including regexps
- New Application Templates - kdehello, javahello, qtopia, fortran
- Make Output View verbosity configuration
- Added Fortran, Ruby, and tmake Project Support
- New Class Wizard added features (inc. Make Member support)
- Better documentation browsing, XML support
- Rewritten Classparser code -- faster and more compact
- DCOP interface for FilterParts and CppParts - can trigger events via DCOP
- Most non C++ (Perl, PHP, Java, etc.) project managers improved
- Vastly improved Integrated Doxygen Support
- Debugger integration improved
- Numerous bug fixes (debugger, IDEAl mode layouts, crashes)
And, the development doesn't stop here! Look soon for better persistent class store support, and smarter code completion -- already in CVS!
Your feedback is welcome.
The developers would love your feedback, from positive comments to concerns and wishlist items. Messages in this forum, to our mailing list or on irc.kde.org, channel #kdevelop, are all appreciated!
Comments
> man 3 getcwd
Not so simple, unfortunately. A running image's "current working directory" does not have to be the same directory that it was launched from. I spend most of my time in a subdirectory of my home directory, but *very* few of the apps I run come from there.
I'd be very interested in the answer, too!
Can often be found from argv[0] although I don't think it's particularly cross-platform.
I had this problem until I put the absolute path in for the demoui.rc file. I don't know why this had to be done but it fixed the problem for me.
I'm converting my projects from KDE 2.2 where I used to get away with really simple calls to QT, e.g.
KMenuBar *menubar= menuBar();
QPopupMenu *popup=new QPopupMenu();
popup->insertItem("Item", this, SLOT(slotMySlot()));
menubar->insertItem("My Menu", popup);
It appears this still works in KDE 3.2, but of course you don't get user-customizable menus.
Unpacking gideon-data (from .../gideon-data_1%3a2.999+cvs20030411_all.deb) ...
dpkg: error processing /var/cache/apt/archives/gideon-data_1%3a2.999+cvs20030411_all.deb (--unpack):
trying to overwrite `/usr/share/icons/hicolor/16x16/apps/kdevelop.png', which is also in package kdevelop-data
The problem seems obvious, but not the solution -- to me anyway. Can I somehow force it to install even though the old KDevelop and Gideon share this image file? Any suggestions appreciated!
Uninstall KDevelop?
I was thinking about that solution but I prefer not to, since I don't know whether or not I will be able to use Gideon in place of the older KDevelop for my projects. Particularly since it's just alpha yet.
Ohww... I remember these fights with dpkg very well...
Simply build it from source (works great) or use one of the rpm's.
source:
dl, tar xzvf **.tar.gz,cd **,configure, make && make install
Thanks for the advice. I tried compiling it properly and it seemed to work (no errors or anything), but when I tried to launch it I got the same error as I got when I installed from a Debian package:
---
Unable to find plugins, KDevelop won't work properly!
Please make sure that KDevelop is installed in your KDE directory, otherwise you have to add KDevelop's installation path to the environment variable KDEDIRS and run kbuildsycoca. Restart KDevelop afterwards.
Example for BASH users:
export KDEDIRS=/path/to/gideon:$KDEDIRS && kbuildsycoca
---
So I did the following:
export KDEDIRS=/usr/bin/gideon:$KDEDIRS
Then when I ran kbuildsycoca, I got:
Warning: kbuildsycoca is unable to register with DCOP.
When I launched Gideon after that I got the same problem as always, ie it complains about not loading plugins. Without those plugins, KDevelop seems like a very empty environment where I can't do much of anything.
Any ideas?
Your "KDEDIRS=/usr/bin/gideon:$KDEDIRS" is incorrect
Instead, point it to the base directory where you told the whole gideon installation to go. For me it was /usr/kde/3.1
It looks like for you it may have just been /usr
(If you have the source still, you can go to that directory and type "./configure --help" and see what the --prefix directory is set to. That's your installation directory).
Caleb
I checked configure to find out the dir, and that did the trick for me.
I had tried all sorts of directories and was going nuts. Thanks!!!
Which directory was it? How can i check it out in my configure? Thanks
Just do the following:
dpkg -i --force-overwrite /var/cache/apt/archive/gideon*.deb
this will overwrite any existing file, worked for me.
Mike
..to get the Java application templates to compile?
I still have yet to ever make those work.. :(
When I try to run most of the project types available, I get the following:
aclocal: configure.in: 8: macro `AM_PROG_LIBTOOL' not found in library
And it all stops, and I don't get a makefile. Any ideas? I run Debian, and a Gideon compiled from source.
Upgrade your autoconf and automake. You're probably doing 2.13 and you need 2.5x (2.57, say).
Hope that helps.
Thanks for your reply.
My autoconf is already 2.57. My automake is 1.4-p6. apt-get says it's already the newest version (I'm using Debian unstable).
Debian solution:
Following the solution for Red Hat below, locate the package providing libtool.m4. It is "libtool".
Then: apt-get install libtool
I have the same problem with RedHat9 when I try to compile the default Hello World application in C++.
Info:
I have compiled kde3.2 and kdevelop with konstruct last weekend.
automake (GNU automake) 1.8.2
autoconf (GNU Autoconf) 2.59
Another problem, the CVS init fail with Kdevelop, but the same command line is working inside Konsole.
Ok, this problem was easy to resolve.
the command "aclocal --print-ac-dir" should return the path in with
the file "libtool.m4" is supposed to be.
It wasn't on my system. I've just added a symbolic link (ls -n) to it.
And tadam!
Thanks to this post:
http://sources.redhat.com/ml/automake/2002-02/msg00037.html
It was OK for me to just remove the problematic line from configure.in. My simple application needed no libtool anyway, so there is no use of configuring it.
In my case, the libtool in not even installed on my System. (I am using Kubuntu 5.10 preview) I just have to install the libtool, then the problem was fixed
eg.
apt-get install libtool
just a quick jot...
manually installing any of the programs involved might cause this...
if aclocal --print-ac-dir
returns something like /usr/local/share/aclocal you should probably delete your manually installed aclocal and automake stuff from /usr/local (especially /usr/local/bin).
Obviously if you don't know what you are doing (like me) you can get in trouble. Anyway, deleting the aclocal files from that directory and apt-get install ... fixed it for me.