[Gtk-sharp-list] Gtk+ 3.0 and Gtk#

[Mike Kestner]

On Mon, 2010-11-15 at 09:32 -0800, Daniel Morgan wrote:
> I have read the way Gtk+ 3.0 works, it will break user interface
> designers like Glade.  I understand that MonoDevelop uses its own
> users interface designer called Stetic.  
> 
> Will Gtk+ 3.0 break Stetic?  

Gtk3 is a parallel-installable library to gtk2, so gtk3 won't break
anything.  Stetic uses gtk-sharp 2.x.0.0 assembly version currently.  It
would need to be extended to be able to support a Gtk# 3 assembly set in
the future.

> Are there any breaking changes in Gtk+ 3.0 that will break Gtk#?  Is
> someone working on the Gtk# bindings for Gtk+ 3.0?

There are numerous API breaks in Gtk+ 3.  Tons of deprecated API is
going away.  Most of this API is marked Obsolete in Gtk# 2.12.10, but
they have deprecated API since, and to my knowledge are still
deprecating and removing API in the 2.x releases leading up to the final
release.

While nobody is actively working on 3.0 bindings, I have experimented
with private patches that bring trunk up to 2.90.0.  With Gtk+ getting
closer to a 3.0 release, I will probably spend some time to clean it up
to recent source levels and commit it, though due to work priorities,
this will likely be a spare time and margins effort in the near term.

These would be parallel-installable bindings to Gtk# 2.x though, so I
repeat, 3.0 doesn't break anything.  Gtk3 and Gtk2 are likely going to
be coexisting on machines for a while now, and Gtk3 won't even be
available on most user machines for a while.

> Does Gtk# follow the Gtk+ / Gnome releases?

Gtk# is not in lockstep with the Gnome release cycle.  Gtk# is a member
of the platform bindings release set, however.

> Just curious, since Mono 2.8 has dropped support for the .NET 1.1
> profile, can we finally get some generic collections, LINQ to Gtk#
> controls, data binding?

We already return and accept typed arrays for most g(s)lists.  I don't
see how changing those to List<Foo> would enhance things, and it would
be a very large API break throughout the binding.  If you have
suggestions for uses of LINQ on Gtk# controls, feel free to propose
them.  However, since most of LINQ is implemented in external assemblies
there's no need for this feature to be directly integrated at first or
for that matter, ever.  Databindings have already been pursued
successfully in external assemblies.

> Is it possible for Gtk# to start using Gtk+ Introspection instead of
> Gapi?

Short answer is that it would be a huge amount of work to do so, for
little benefit, since Gtk# is already a mature binding. 

I have done some work on a GIR to GAPI XML converter to support
consumption of GIRs in the GAPI generator, eliminating the GAPI parser
from the toolchain for new binding efforts.  I will check that in to
github in case anyone wants to play with it.

Any GIR file is still likely to require some markup to make it C#
friendly, though.  And rewriting the GAPI code generator to consume GIR
directly would be a rather large effort.

-- 
Mike Kestner <mkestner at gmail.com>