Sorry, but I really can’t understand what you mean
The KDE folks provided a more unified approach to the KDE “subsystems”
in collecting what is required into kdebindings (and providing bindings
to plasma as well). This is an integrated approach the kde folks chose
here, which I believe is a better approach than the Gnome one right now
(for ruby at least).
For example, if one goes and extracts kdebindings he finds directories
python/ ruby/ java/ php/ falcon/ etc…
Inside that ruby/ directory one would find phonon/ qtruby/ qtwebkit/
As far as I can see Qt/Kde has a tighter approach to include ruby at the
moment, and it seems to be quite complete from the top-down.
Now, if one looks at this website for gtk:
he gets to see that python is officially a part of GNOME (and the
version is officially higher than ruby), and ruby is not an official
part of GNOME.
(The officially supported languages for GTK seem to be C++, C#, Javam,
Python and Perl). The version usually lags behind the official GNOME
versioning, and the reason for this is mostly because we lack
This problem as such - if it is one - will continue to exist.
My above phrase was a general remark about “scripting languages”,
meaning that the GNOME folks must aware that other scripting languages
will have a problem to provide up-to-date bindings. Obviously python is
more important for the GNOME project, and it seems even perl is
preferred over ruby, but at least the situation could be somewhat
similar for lua bindings to Gnome. At least I could imagine that the Lua
folks do have problem to keep up easily with a fast moving upstream
But perhaps I am wrong, because from that page it seems that even Lua is
more up-to-date than ruby-gnome, since they are on 2.12 whereas
ruby-gnome seems not yet, at least only partially-supported hmmm …