[Gtk-sharp-list] The state of GTK#

[Mike Kestner]

On Sun, 2010-03-07 at 15:25 +0100, Sense Hofstede wrote:

> The past few weeks I've been working on getting the Mono bindings of
> libappindicator[1] to work correctly. I managed to get everything work
> correctly apart from making the virtual members accessible an
> overridable in C#. The thing is that libappindicator provides two
> (virtual) methods that provide a fall back mechanism. You can
> implement your own by overriding those functions. However, I couldn't
> get this to work because virtual methods aren't supported by GAPI2
> which is included in GTK# 2.12.9. If everything goes well it might be
> included in the GTK# 3.0 release in September. That is too late for
> Lucid, obviously and therefore the libappindicator library won't have
> all functionality in C# that is available in C, Python and in the near
> future in Vala as well.

Congrats on your progress with the binding.

The virtual method generation issue is worked around in the gtk-sharp
2.12 tree itself via the use of custom code and a small amount of
boilerplate glue.  There are a few examples of how to do this in the atk
directory, especially on Atk.Object.  To be honest, there aren't a lot
of examples because the capability isn't very widely used in gtk+ and
dependencies.

Also note that we have not made any commitments to release a Gtk# 3.0 in
September.  If the gtk+ 3.0 release happens in September it is probably
more likely a Gtk# binding for it would come next Spring.  

Chasing the gtk+ release during the same cycle basically ensures the
maximum amount of pain for all developers and potential testers.  And
any developer that tracks a Gtk3 library is basically going to ensure
his application is unavailable to all but those who like to chase the
bleeding edge distros.  This is part of the reason behind our
conservative release cycle.

> September 2010 is a quite far away from November 2004, which was when
> VirtualMember.cs was uploaded to SVN for the first time. The long
> waiting period between the introduction seems to be typical for GTK#.

I think you are confused about some things.  One, VirtualMethod was
initially introduced to generate GInterface virtual methods.  This is
the work that started back in 2004.  This capability has been in the
stable 2.12 branch for quite a while.  The lack of GObject virtual
method override is more a function of how much more difficult it was to
override them in generated code, coupled with the minimal use of the
capability within the core libraries.  This generation work didn't
really start until last year, and as you have noticed is one of a few
new capabilities in trunk awaiting release in 3.0.

> You could say that it was GTK# that costed Banshee the position as
> default media player in Ubuntu: GTK# still won't included GIO# in the
> next release -- it was a requirement back then -- but most importantly
> the a11y support wasn't available with the GTK# of that time. Although
> it was mostly written, it wasn't released and if I read the Banshee
> ./configure output correctly it only will be in GTK# 2.12.10. The
> other issues on the list were fixed by the Banshee developers.

I think you are reaching pretty far in these assertions.  GIO bindings
are available.  They are not packaged inside of gtk-sharp, but this also
allows flexibility to improve and fix them before they are forced into
an API stable state.  The fact that applications like banshee and f-spot
are embedding these libraries and working out the kinks in them before
they are integrated is a strength, not a deficiency.  I believe that
even if we had an integrated GIO binding in gtk-sharp, they would
probably still be shipping private copies to ensure that their apps
worked on older versions of Gtk#.

The a11y stuff has also been in gtk-sharp for a long time.  The fact
that banshee and the uia2atk projects have actually started using them
lately has led to a number of improvements and bugfixes in the API.  It
is these fixes which have been coming out in recent 2.12.x releases.
But the core functionality has been there forever, and it wasn't until
somebody started using it that we started getting it into a more
usable/complete state.  The analogy to gio bindings is pretty clear,
from my perspective.  We could have put a gio binding into 2.12 or
released trunk a year ago with it, but with nobody using it extensively,
how good would it have been, and how many people would be complaining
about the bugfixes in svn that haven't been released yet?  Hopefully
with Stephane working out the kinks ahead of time, when we release it in
3.0 it will be something that users can rely on from the start, and
anyone wishing to help or get a head start can integrate his gtk-beans
project into theirs now.

> It would be good for GTK# and the image of Mono applications on the
> GNOME desktop if GTK# wouldn't be maintained as conservatively as it
> is now. 

For every person like you who wants Gtk# to be following the bleeding
edge, I suspect there are at least two or three who are glad that they
don't have to target five or six different versions of the binding which
provide minimal significant differences between versions.

> Maybe it should become a part of the GNOME project and move to
> gnome.org, I don't know. What I do know that it is getting
> increasingly harder for Mono applications to maintain their position
> on the desktop. It could be that everything is fixed with the GTK# 3.0
> release, but in time there will be a GTK# 4.0 release as well. Will
> GTK# development for the 3.x tree die out then as well? I hope not,
> because applications like Banshee, Gbrainy and Tomboy surely add
> something to the desktop and they would be missed.

Gtk# is already a part of the GNOME bindings platform, and is released
on ftp.gnome.org.  I'm not sure how much more a part of the gnome
project we can become than that.  If you are referring to adhering
lockstep to a 6 month development cycle, well, even if we had the
developers and cycles to do so, I'm still not convinced it is what the
majority of our users want.

-- 
Mike Kestner <mkestner at gmail.com>