Is there any mature bindings (like Python has) for KDE/QT and Ruby?
Thanks!
Greg B.
Greg Brondo wrote:
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
···
Thanks!
Greg B.
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
···
On Tuesday 06 January 2004 21:36, Bauduin Raphael wrote:
Greg Brondo wrote:
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
–
Women sometimes forgive a man who forces the opportunity, but never a man
who misses one.
– Charles De Talleyrand-Perigord
Bauduin Raphael wrote:
Greg Brondo wrote:
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
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
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.
- –enable-pthread becomes default
- 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
···
On Tuesday 06 January 2004 23:26, Alexander Kellett wrote:
On Tuesday 06 January 2004 21:36, Bauduin Raphael wrote:
Greg Brondo wrote:
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 itprerelease 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)
–
Beauty, n.:
The power by which a woman charms a lover and terrifies a husband.
– Ambrose Bierce
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
···
On Thu, Jan 08, 2004 at 01:11:41AM +0900, Richard Dale wrote:
--
When women love us, they forgive us everything, even our crimes; when they do
not love us, they give us credit for nothing, not even our virtues.
-- Honor'e de Balzac
Alexander Kellett wrote:
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
i’ve got a few evil ideas for this that i’ll work on tonight…
Alex
···
On Wednesday 07 January 2004 18:26, Richard Dale wrote:
Alexander Kellett wrote:
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.xThat’s really good news Alex! If we can only sort out the pthreads/crash
and write a few marshallers we’re golden…
–
Loan-department manager: “There isn’t any fine print. At these
interest rates, we don’t need it.”
yay. it works:
'kdebindings/korundum/bin' - MARC
and for sources:
http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdebindings/korundum/bin/
(whenever it actually syncs with main cvs…)
Alex
···
On Wednesday 07 January 2004 21:03, Alexander Kellett wrote:
On Wednesday 07 January 2004 18:26, Richard Dale wrote:
Alexander Kellett wrote:
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.xThat’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…
–
Fakir, n:
A psychologist whose charismatic data have inspired almost
religious devotion in his followers, even though the sources
seem to have shinnied up a rope and vanished.