RG2 as GNOME official bindings?

Hi,

I’m seeing on this blog
http://blogs.gnome.org/aklapper/2009/08/11/gnome-3-update-module-proposals-welcome-now/
that new modules can be proposed for inclusion into GNOME 3 and it
made me think of Ruby GNOME. Do you think that the project would
benefit becoming an official binding for the GNOME platform?

A possible problem is maintenance. Official bindings must match the
GNOME release schedule and Kouhei often complains that the human
resources for the project fall short so it may be too much of a burden
for Kouhei.

Anyway, I’m just throwing the idea.

Mathieu

Mathieu B. wrote:

Hi,

I’m seeing on this blog
GNOME 3 update + Module proposals welcome now! | andré klapper's blog.
that new modules can be proposed for inclusion into GNOME 3 and it
made me think of Ruby GNOME. Do you think that the project would
benefit becoming an official binding for the GNOME platform?

A possible problem is maintenance. Official bindings must match the
GNOME release schedule and Kouhei often complains that the human
resources for the project fall short so it may be too much of a burden
for Kouhei.

Anyway, I’m just throwing the idea.

Mathieu

I think it would be best to ask the Gnome devs. Personally I prefer Qt
over Gt, but I decided to use gtk because of ruby-gtk (i love the wiki).
I am glad that the Gnome folks decided to clean up on gnome.

Ruby is really my main reason to consider Gnome/Gtk, but perhaps ruby-qt
would be a better platform for many people (because Qt4 as such is
better suited than Gnome). I mean - the Gnome guys must be aware of it
because it is not only ruby, but also python, which should be a bit
bigger than ruby, and qt/kde have python bindings also. So it is a more
general question altogether.

The maintenance issue is something that would always exist, and with a
lack of manpower such a project will fall behind quickly too. I dont
know what would help make maintenance for scripting languages to keep up
with the C libraries could help…

Le mercredi 09 septembre 2009 à 18:09 +0200, Marc H. a écrit :

Ruby is really my main reason to consider Gnome/Gtk, but perhaps ruby-qt
would be a better platform for many people (because Qt4 as such is
better suited than Gnome). I mean - the Gnome guys must be aware of it
because it is not only ruby, but also python, which should be a bit
bigger than ruby, and qt/kde have python bindings also. So it is a more
general question altogether.

Sorry, but I really can’t understand what you mean

Le jeudi 10 septembre 2009 à 14:29 +0200, Marc H. a écrit :

Now, if one looks at this website for gtk:

http://www.gtk.org/language-bindings.html

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.

Yes that was the point of this discussion as the subject says, should we
try to become officiel part of gnome :slight_smile:

This problem as such - if it is one - will continue to exist.

This is the argument against becoming official (I’m quite sure GNOME
will not accept a binding which does not release up to date bindings
every six months)
The argument for becoming official is that more people would use it, and
maybe more people would help

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
like
python/ ruby/ java/ php/ falcon/ etc…

Inside that ruby/ directory one would find phonon/ qtruby/ qtwebkit/
etc…

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:

http://www.gtk.org/language-bindings.html

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
maintainers.

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
development process.

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 … :wink:

Pascal T. wrote:

This is the argument against becoming official (I’m quite sure GNOME
will not accept a binding which does not release up to date bindings
every six months)

OTOH, the transition to GNOME 3.0 will remove a bunch of obsolete
libraries, which will in turn allow for the removal of at least eleven
bindings:

bonobo
bonoboui
gnome
gnomecanvas
gnomeprint
gnomeprintui
gnomevfs
gtkhtml2
gtksourceview (1.8)
libart
libglade

Ruby/Libgda has been unmaintained for years, and who knows what will be
with gtkglext (unmaintained?) and gtkmozembed (hopefully replaced by
webkit) by then. That means approx. half of the existing bindings will
disappear, leaving much less work to spread around.

The argument for becoming official is that more people would use it, and
maybe more people would help

Of course, that is all relative to the overall usage of Ruby, which is
AFAICS much less than Python. But it is a strong argument nonetheless.

Yaakov
Ruby/GtkSourceView2 maintainer