GtkSharpPlan
From Mono
| Table of contents |
Stable Releases
Gtk# 2.4.3, 2.6.3, 2.8.5, and 2.10.4 and 2.12.0 have been released.
Plans for Gtk# 2.x
2.4/2.6/2.8 Bindings
We are now in stable bugfixing mode for the 2.4, 2.6, and 2.8 bindings. There are no current plans to add new features for these releases.
Novell is packaging the 2.4 releases for our currently supported platforms. We recommend developers stick to the 2.4 API for more widespread availability of your applications, unless there is a really compelling reason to use 2.6 or 2.8 APIs. Our 2.6.x releases are source only.
We are also packaging 2.8 releases for distributions supporting gtk+ 2.8, such as SUSE 10, SLED10, and FC5.
2.10 Bindings
Gtk# 2.10 and the new Gnome# 2.16 package are released in source form on GNOME FTP (http://ftp.gnome.org/pub/gnome/sources/gtk-sharp/2.10) and packaged for platforms which support Gtk+ 2.10. Gtk# 2.10 is included in the GNOME platform bindings as a blessed binding for desktop development. The Gnome# 2.16 releases are included in the GNOME desktop release.
2.12 bindings
Gtk# 2.12 bindings are in stable release. Gnome# 2.20 and the new GnomeDesktop# unstable library bindings package have been released as well. Source tarballs are available from GNOME FTP (http://ftp.gnome.org/pub/gnome/sources/gtk-sharp/2.12). The following enhancements and new features were delivered in 2.12, along with newly bound API members from Gtk+ 2.12 and GNOME 2.20:
Memory and Reference Management Improvements
We now use the toggle_ref API introduced in glib-2.8 to provide more accurate reference management for managed subclasses of GLib.Object. Toggle refs are a special class of reference that lets us determine if we are the sole owner of a native object. This is especially important when dealing with managed subclasses of GLib.Object. As long as unmanaged code holds references to a managed subclass, we have to artificially keep a managed ref around to ensure garbage collection doesn't occur, since the objects likely contain instance data that would be lost if the managed object is finalized.
Gtk.Object destruction enhancements
We have simplified and improved the notification and release mechanism for Gtk object destruction, eliminating a substantial number of leakage scenarios.
Revamped the GLib.Object finalization mechanism
In the previous implementation, the finalizers invoked GLib.Object.Dispose. GLib.Object.Dispose would queue up the object for a timeout handler to process it. This approach caused problems for subclasses that override Dispose. Basically, any Dispose override would have had to do a similar timeout mechanism to ensure that any GObject operations they performed would not occur on the GC thread.
We now do the timeout in the finalizer itself. It queues up the object for a timeout handler which invokes Dispose on the queued objects. This ensures that all Dispose invocations occur on the "GUI thread" and takes the burden off the subclass author to do the switch in their Dispose overrides.
Better exception handling
Exceptions thrown during native to managed callbacks like signal handlers and callback parameters previously caused stack corruption and were nearly impossible to debug. Trunk contains a new GLib.ExceptionManager.UnhandledException event that applications can connect to be notified of any exceptions thrown in these scenarios. The exceptions can not be thrown across the native to managed boundary so this is a mechanism to "catch" those exceptions and deal with them gracefully.
The following code snippet would display an error dialog and terminate the application:
... UnhandledExceptionHandler h = new UnhandledExceptionHandler (OnException); ExceptionManager.UnhandledException += h; Gtk.Application.Run (); ... void OnException (object o, UnhandledExceptionArgs args) { ShowErrorDialog (args.ExceptionObject, args.IsTerminating); args.ExitApplication = true; }
Structure marshaling
Structures passed to callback marshaling delegates in many cases can be NULL pointers. We previously marshaled these parameters as "ref Foo" types, which caused crashes in the runtime marshaling code. The generator has been enhanced to treat these parameters as IntPtr to allow for NULL checking prior to marshaling.
GInterface Registration
Registration of GInterface implementations is now supported. Details on how to implement an interface with a tutorial can be found at ImplementingGInterfaces
Future Plans
The following list is a prioritized view of the planned feature additions:
Documentation
We have already invested substantial effort into completing the API documentation and will continue to improve the state of the API documentation. Our goal is to introduce no new undocumented APIs going forward, and to improve the existing documentation coverage, filling in stubbed API documentation.
Databinding
We want to build on some existing efforts to provide an integrated databinding capability similar to the .Net databinding capability in winforms.
Indexer Autogeneration
We want to provide autogeneration of indexers and enumerators for types which expose foreach methods. This feature is in the feasibility-study category.
GUI Designer Support Improvements
We want to provide an attribute system to make it easier for Stetic to interface with not only the Gtk# widgets, but third party super-widgets.
Powered by MediaWiki