Ruby and QT/KDE

[Greg Brondo]

Is there any mature bindings (like Python has) for KDE/QT and Ruby?

Thanks!
Greg B.

 

[Bauduin Raphael]

Is there any mature bindings (like Python has) for KDE/QT and Ruby?

The best candidate is the package Richard DAle is working on.
Maybe it'll be part of KDE 3.2 that will be release soon, I don't know.
I'm looking forward to it

RAph

 

[Alexander Kellett]

The best candidate is the package Richard DAle is working on.
Maybe it'll be part of KDE 3.2 that will be release soon, I don't know.
I'm looking forward to it

prerelease available at http://ww.lypanov.net/bindings.html if
you want a working qt only binding already...

(its just a working known snapshot i made - 400kb tarball)

Alex

 

[Alexander Kellett]

prerelease available at http://ww.lypanov.net/bindings.html if
you want a working qt only binding already...

(its just a working known snapshot i made - 400kb tarball)

unforunately after a bit of investigation
it seems that in order for programs using
these bindings to even start without an
immediate segfault --enable-pthread
is needed. qt 3.1 doesn't do this otoh
with the same bindings. i still need to
verify that the old tarballs also don't
work with latest ruby, but somewhere
along the line i think qt 3.2.3 (iirc) or
maybe even ruby's behaviour changed
somehow and since that moment i get
the following backtrace on program
startup:
#0 0x410d1785 in __pthread_unlock () from /lib/libpthread.so.0
#1 0x410ced75 in pthread_mutex_unlock () from /lib/libpthread.so.0
#2 0x40259bc9 in _dl_open () from /lib/libc.so.6
#3 0x40100e88 in dlopen_doit () from /lib/libdl.so.2
#4 0x4000adc6 in _dl_catch_error_internal () from /lib/ld-linux.so.2
#5 0x40101286 in _dlerror_run () from /lib/libdl.so.2
#6 0x40100ed4 in dlopen@@GLIBC_2.1 () from /lib/libdl.so.2
#7 0x400448ee in dln_load () from /usr/lib/libruby18.so.1.8
...

using "export LD_DEBUG=libs" shows the
following:
...
888: calling init: /usr/lib/libGL.so.1
888: /usr/lib/libGL.so.1: error: relocation error: undefined symbol: pthread_key_create (fatal)
888: calling init: /usr/lib/ruby/site_ruby/1.8/i686-linux-gnu/qtruby.so

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 888)]
0x410d6785 in __pthread_unlock () from /lib/libpthread.so.0
...

but further up i notice a large pause when

888: calling init: /lib/libpthread.so.0
888: (no debugging symbols found)...(no debugging symbols found)...[New Thread 16384 (LWP 888)]

takes place.
it seems strange that pthread is seemingly starting a new thread...

okay. enough rambling and onto some possible solutions.
1) --enable-pthread becomes default
2) i *somehow* figure out what --enable-pthread is changing
in the environment and try to manually perform those
operations before ld'ing pthread/qt/qtruby (i.e, add a dummy
wrapper which sets up pthread locking or something...)

option 1 is fine for me but for one thing. it breaks the
the gnome2 bindings which would also like to mess with
for gstreamer + kde integration ;-)

[ if anyone wants the program that shows these
problems with the gnome2 bindings i'll gladly
forward / upload ]

thanks for listening
Alex

 

[Richard Dale]

The best candidate is the package Richard DAle is working on.
Maybe it'll be part of KDE 3.2 that will be release soon, I don't know.
I'm looking forward to it

Sadly too late for KDE 3.2 as it wasn't included in the release plan 3
months ago, and I couldn't seem to manage to justify it going into 3.2 on
the kde-core-devl list as a 'technology preview' or similar.

Please see Alex's comments about the pthreads startup crash problem - that
seems a bit of a show stopper at the moment. I don't have it, and I use gcc
3.2.2 on PowerPC with Qt 3.2.3. It seems to be a combination of a later gcc
than I have with a current Qt lib.

Other than that, here is a summary of the current development status:

The bindings use the same runtime as the PerlQt project, which has been
released on SourceForge for over a year. It seems to be picking up steam
(go PerlQt guys!), with the Debian GUI installation front end being written
in PerlQt for instance. I would say that the QtRuby bindings are about as
complete/stable as the perl ones - ie they don't crash randomly/leak memory
etc. The Qt bindings are about 95% done feature wise, but still quite
usable as they stand.

The Smoke runtime for Qt/KDE has 950 classes/29000+ methods wrapped last
time I measured, so it is really very complete

This is Germain Garand's comment on the kdeperl list about the status of
PerlKDE (the ruby bindings or 'Korundum' have the same runtime and are at
the same stage):

"Well, PerlKDE is in CVS. It's missing some more marshallers and some DCOP
eyecandy, but it's pretty complete and stable otherwise. Let's say it's beta
or pre-beta."

Ruby has one or two more KDE marshallers than perl, so more of them for all
the bazillions of C++ list types, and finished DCOP support is mainly
what's missing.

-- Richard

 

[Alexander Kellett]

Sadly too late for KDE 3.2 as it wasn't included in the release plan 3
months ago, and I couldn't seem to manage to justify it going into 3.2 on
the kde-core-devl list as a 'technology preview' or similar.

as bindings are not entirely simple distribution-wise in any case
i think that a fair number of distributions will probably ship with
korundum bindings - i merged the branch, but its still in do_not_compile
by default, but that shouldn't matter, it is in the source tree at the
very least, and we could probably get it enabled for 3.2.1 if the
enable-pthread stuff is sorted. or in any case i'll make sure that
gentoo at the very least has it for 3.2.x ;-)

Please see Alex's comments about the pthreads startup crash problem - that
seems a bit of a show stopper at the moment. I don't have it, and I use gcc
3.2.2 on PowerPC with Qt 3.2.3. It seems to be a combination of a later gcc
than I have with a current Qt lib.

i'm hoping that someone else can enlighten me further on this as
i'm still unable to go any further. i've now given up on the possibilty
that it will work out of the box for the moment and i've thus built
ruby with --enable-pthread on my machine and will work on some korundum
using example programs in the coming weeks.

"Well, PerlKDE is in CVS. It's missing some more marshallers and some DCOP
eyecandy, but it's pretty complete and stable otherwise. Let's say it's beta
or pre-beta."

i should check out PerlKDE at some point in the near future. i hope that
germain imports this into kde cvs after the freeze is lifting in the
coming months.

Ruby has one or two more KDE marshallers than perl, so more of them for all
the bazillions of C++ list types, and finished DCOP support is mainly
what's missing.

the generic marshalling depends on 3.2, but other than that the
package on lypanov.net/bindings.html will work with either qt 3.2
or qt 3.1.

cheers,
Alex

 

[Richard Dale]

as bindings are not entirely simple distribution-wise in any case
i think that a fair number of distributions will probably ship with
korundum bindings - i merged the branch, but its still in do_not_compile
by default, but that shouldn't matter, it is in the source tree at the
very least, and we could probably get it enabled for 3.2.1 if the
enable-pthread stuff is sorted. or in any case i'll make sure that
gentoo at the very least has it for 3.2.x ;-)

That's really good news Alex! If we can only sort out the pthreads/crash and
write a few marshallers we're golden..

-- Richard

 

[Alexander Kellett]

That's really good news Alex! If we can only sort out the pthreads/crash
and write a few marshallers we're golden..

i've got a few evil ideas for this that i'll work on tonight...

Alex

 

[Alexander Kellett]

i've got a few evil ideas for this that i'll work on tonight...

yay. it works:
http://lists.kde.org/?l=kde-cvs&m=107351612904433&w=2
and for sources:
http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdebindings/korundum/bin/
(whenever it actually syncs with main cvs...)

Alex