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 <[email protected]> _______________________________________________ Gtk-sharp-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
