The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: no (ruby) bindings update?
by David on Monday 10/May/2004, @14:42
|
From what I've seen all of the bindings have come on leaps and bounds. I'd be surprised if Ruby wasn't in the 3.3 bindings release.
|
[
Reply To This | View ]
|
Re: no (ruby) bindings update?
by Richard Dale on Monday 10/May/2004, @22:03
|
QtRuby and Korundum weren't built by default for KDE 3.2, but they will be for KDE 3.3.
The basic bindings for Qt/KDE are complete, and the rbuic tool works with KDE widgets. KDevelop has some ruby support; with ruby class browsing/syntax highlighting, and Marek Janukowicz has recently added a QtRuby template.
Here's a list of a few further things to do (anyone like to help out?):
- More code samples, particularly KDE ones
- Qt Designer plugin
- Kate ruby plugin
- KDevelop Korundum project template
- More documentation
- Set up Korundum site on rubyforge with a release
- Online tutorials
- KDevelop Korundum project template, debugger front end etc
- Extract KDE C++ doc comments from kde headers and convert to RDOC format
- RubberDoc documentation browser (Alex Kellett)
- Release Announcement (eg 'KDE Ruby bindings now official!')
I'm sure a killer RAD environment isn't that far off..
-- Richard
|
[
Reply To This | View ]
|
Re: no (ruby) bindings update?
by Christian Loose on Tuesday 11/May/2004, @00:48
|
Will the ruby bindings (Korundum) contain only stuff from kdelibs or will it also contain non-core libraries like libkcal? Or asked differently, how hard would it be to generate those bindings and ship them with an app?
Christian
|
[
Reply To This | View ]
|
Re: no (ruby) bindings update?
by Richard Dale on Tuesday 11/May/2004, @01:55
|
Korundum only contains stuff from kdelibs (and Qt). It is driven by the file kdebindings/smoke/kde/kde_header_list, and so you might just need to add the libkcal headers to that in order to add them to Korundum (and link libsmokekde against libkcal). That would allow you to try kcal ruby programming. But does it have any of its own namespaces? If so, they would need to be added the QtRuby runtime which would be extra work, although not much.
The current version of the SMOKE library is a bit monolithic, and so you either have to add classes to the Korundum extension or not at all. It isn't possible to have a kcal specific extension that could be used in conjuction with Korundum. This is because in SMOKE v1 each method is identified with a short integer. In SMOKE v2 the methods will be indentified with a URI which should make it more flexible.
|
[
Reply To This | View ]
|
Java bindings
by Boudewijn Rempt on Tuesday 11/May/2004, @03:35
|
I did a little experiment with the Java bindings yesterday, and I was quite impressed. It's actually possible to create a Qt app in Java, and compile that to native code with gcj. See my writeup at: http:/www.valdyas.org/fading/index.cgi/hacking/gcj.html?seemore=y.
|
[
Reply To This | View ]
|
Re: Java bindings
by Richard Dale on Tuesday 11/May/2004, @04:06
|
Just had a look - good work! Thanks for spreading the news that there are viable Free Software alternatives to Sun's jdk. I agree that gcj and the java bindings are a really good combination too - I think gcj is a really underrated project.
Note that you can use the interpreter 'gij' that comes with gcj too. I've found that works really well with Qt or KDE java programs; they run fast because they spend most of their time in the kde or qt libs which are native code.
You can compile qtjava.jar to a library called 'lib-org-kde-qt.so' and gcj or gij will use that in preference to qtjava.jar. But I've found the libraries are a bit large relative to the speed up and perhaps it's more trouble than their worth.
|
[
Reply To This | View ]
|
Re: Java bindings
by Boudewijn Rempt on Tuesday 11/May/2004, @04:08
|
Yes, I first used gij to verify it all worked, and then slowly worked up towards an optimized binary... Is there a special reason for the naming of the shared library? I just named it qtjava.so...
|
[
Reply To This | View ]
|
Re: Java bindings
by Richard Dale on Tuesday 11/May/2004, @04:53
|
You need to name the compiled qtjava.jar 'lib-org-kde-qt.so' so that gcj/gij can search for it when resolving 'import org.kde.qt.*' in your program. It just extends the idea of .jar files to include compiled .so libs. If the directory containing 'lib-org-kde-qt.so' is on your LD_LIBRARY_PATH, it is exactly equivalent to qtjava.jar being on your CLASSPATH.
If you name it qtjava.so you can only use the lib by naming it in a gcj compile command, and not as a qtjava.jar replacement as above.
|
[
Reply To This | View ]
|
Re: Java bindings
by Zoltan Bartko on Tuesday 11/May/2004, @10:04
|
Do I understand that well? Does it mean that I could actually develop my app faster in java with gij and when I would be satisifed with the result, just let it through gcj? Or is there something else to know about this?
Zoltan
|
[
Reply To This | View ]
|
Re: Java bindings
by Richard Dale on Tuesday 11/May/2004, @10:31
|
Yes, you can use both gij and gcj, but I've found nearly all QtJava and kde koala java apps run quite fast enough using gij. I think you'd only need to compile to native code with gcj if your app is graphics intensive. On the other hand, with Swing nearly all the code is java, and so it makes much more difference whether or not you have a jit compared with just ordinary slow interpreted code.
|
[
Reply To This | View ]
|
Re: Java bindings
by Boudewijn Rempt on Tuesday 11/May/2004, @11:27
|
Yes, that's what I set out to discover. I have a vague intuition that applications somehow find easier acceptance if they're native code, instead of any kind of bytecode. Richard is right, though, for the actual performance there's not much difference, perhaps because qtjava uses JNI, and Mark Wielaard tells me that for every JNI call, gij is called to generate some bytecode, which is then executed. Things could be faster, he tells me, but I think it's plenty fast enough. Although I noticed that putting a simple QMainWindow on screen is a lot faster with qtjava compiled to native code using -O2, than it is without optimization or in bytecode.
Also, I've checked Richard's other remark -- about the name of the shared library compiled from a jar -- and I was told that the difference is not that when the shared library has a name that doesn't reflect the package is contains, the java jar is used, but that when it's named qtjava.so (for instance), the ordinary dynamic linker is used, but when it's named org-kde-etc.so, the bootstrap classload is used; but in both cases it's native code.
Anyway, my next target is to find out how to create a library using java, compile it natively, and call that from C++. I think java is especially suited to appliation cores that handle data structures.
|
[
Reply To This | View ]
|
Re: Java bindings
by Roberto Alsina on Tuesday 11/May/2004, @10:25
|
I´m impressed :-)
More people should write like this, what they do, and what they find cool about KDE.
I try to do it but I´m not doing much ;-)
|
[
Reply To This | View ]
|
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
