faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
thread
|
KDevelop language integration not up to speed
by Richard Dale on Tuesday 26/Jul/2005, @23:10
|
"In fields unrelated to Web, C++ and Ada, the language integration is not up to speed yet."
Not so. Ruby support in KDevelop 3.2 was improved quite a lot with a ruby debugger, Qt Designer integration, KDE project templates and an improved class parser. It is certainly 'up to speed', and at least as good as in other ruby IDEs. |
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: KDevelop language integration not up to speed
by Kevin Krammer on Wednesday 27/Jul/2005, @01:44
|
Speaking of the Ruby application template: wouldn't it be better to remove the C++ starter application?
Having it in the template requires the developer to install the Ruby devel package for its headers.
|
[
Reply To This | View ]
|
Re: KDevelop language integration not up to speed
by Richard Dale on Wednesday 27/Jul/2005, @01:58
|
Yes, that is a problem. The reason it starts the ruby code via a C++ stub is that it would be exactly the same whether it was a KPart project or a kicker applet. For those other project types there is no choice but to start via C++, as they have to be libraries dynamically loaded from a running KDE app.
The current automake based build system for KDE a way too complicated for ruby anyway. I think the best solution would be to have another application template with exactly the same ruby code, but using a simpler build/install system and no C++ top level stub.
|
[
Reply To This | View ]
|
Re: KDevelop language integration not up to speed
by Kevin Krammer on Wednesday 27/Jul/2005, @03:13
|
Ah, I see. I suspected that there was a reason for it, but I was neverthelesse quite surprised when I tried the template and got a compiler error about a missing header :)
I agree that having another ruby-only template would be a good idea.
Btw, if one has two Ruby KParts/Kicker applets, will the two calls to ruby_init be problematic or does the Ruby interpreter lib handle this grazefully?
|
[
Reply To This | View ]
|
Re: KDevelop language integration not up to speed
by Richard Dale on Wednesday 27/Jul/2005, @04:20
|
"neverthelesse quite surprised when I tried the template and got a compiler error about a missing header"
Yes, in fact you have to run the usual 'make -f Makefile.cvs' and 'configure' commands via the GUI to install. So you get incomprehensible configure stuff for about 5 minutes.
Note that you've got the KDE problem where you can't actually debug you program until it's installed because it won't be able to find xmlgui menu items and so on. Or if you have a KPart project, it won't run until the KPart is installed. I really hope that's fixed in some way for KDE 4 for C++ and other languages like Ruby. Maybe there should be 'share/apps' directories under the KDevelop src dir with symbolic links from the subdirectories into the src dir, and the src dir added to $KDEDIRS. But I don't want to have a ruby specific work round, it needs to be sorted properly.
"Btw, if one has two Ruby KParts/Kicker applets, will the two calls to ruby_init be problematic"
It works fine if you call it twice - it just doesn't do anything the second time.
|
[
Reply To This | View ]
|
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|