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

Christian Hoff christian_hoff at gmx.net
Sun Mar 7 11:01:16 EST 2010


Sense Hofstede wrote:
> Hello,
>
> 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.
>   
If there are only two virtual methods that you're struggling with you 
could add custom code to make them work with gapi 2. There are basically 
two ways to get this done:
1.) Write some ugly glue/C code that overrides the function and call it 
from managed custom code. Ugly, but at least it works. Gtk# 2.12 does 
this to get cell renderers to work properly (see 
gtk-sharp-212-branch/gtk/CellRenderer.cs).
2.) Do it all in managed code. This does however not work with 
Microsoft's implementation of .net in Version 1.1. Maybe the attached 
GAPI3 generated code for Cellrenderer.cs helps you getting started (have 
a look at OngetSize, OnRender, ..)
> 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#.
>   
VirtualMethod.cs is already part of 2.12, it is GObjectVM.cs that does 
what you need. However, the initial commit for this class also dates 
back to April 2009.

But it's true that we have a problem with all the code that languishes 
unreleased in SVN. There are already numerous forks of the generator, 
one for GLib (Gstreamer bindings) and probably a dozen other workarounds 
that I'm not aware of.

There have been substantial improvements  especially in GLib and the 
generator, and of course gio bindings are now included in trunk, too.
> 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.
>   
Gtk# 2.12.10 plans were buried some 6 months ago. It was planned to 
include GAPI from trunk along with a few extension methods for GLib 2.x 
needed by GAPI3.
> It is a shame that so many features are available, needed, but not
> shipped. F-Spot started to included GIO# in their source because it
> still isn't provided by GTK#. Banshee has taken a few things away from
> the GTK# library as well. This is not how shared libraries should
> work, the whole idea behind a shared library is that the library is
> provided separately from the application, not spread across different
> applications.
>
> 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. 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.
>   
The basic problem in my opinion is that we were targetting Gtk 3.0 way 
too early in trunk and I seriously doubt whether there will actually be 
a release in September. Thus, 2.12 is in a seperate branch and cut off 
from development. That was fine as long as nobody seemed to care about 
the improvements in trunk for some time, but then there were GStreamer, 
F-Spot(GIO#) and numerous others who now all borrowed parts from trunk.

I think that the time has come to do something and release parts of 
trunk. A few possible alternatives that came to my mind:
- Why not simply release Gtk# 3 from trunk as it is now with the 
obsolete API removed? The Gtk+ team makes it pretty clear that version 3 
is a maintenance release with no old, non-deprecated API going to be 
removed. So we would have a Gtk# 3 that uses Gtk+ 2.20 under the hood 
and requires .net 2. No adjustments have to be made, though the version 
name might be misleading and imply that we are binding Gtk+ 3. Once the 
release has been made on the Gtk+ side, all we have to do is recompile 
our binding in order to no depend on the old version 2 binaries no 
longer and include the new features of Gtk+ 3.

-  Release GAPI3 now, but with the glue fallback option set to avoid 
GLib 3 and MS .net 2 dependencies.

-  Include Gio# into Gtk# 2.12.10.

Any comments or suggestions?

- Christian
> [1] https://launchpad.net/indicator-application
> [2] https://blueprints.launchpad.net/ubuntu/+spec/desktop-karmic-default-media-player-choice
> [3] https://wiki.ubuntu.com/DesktopTeam/Specs/Karmic/DefaultMediaPlayerChoice
>
> Regards,
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: CellRenderer.cs
Type: text/x-csharp
Size: 32683 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/gtk-sharp-list/attachments/20100307/11dc5a12/attachment-0001.bin 


More information about the Gtk-sharp-list mailing list