May 29, 2004
§ ¶Timing
My timing with a digital camera is impeccable...
May 17, 2004
§ ¶Initialize this!
One of the interesting unsolved challenges in Gtk# is the burden of calling init functions on the underlying libraries. It would be nice if the framework had an easy mechanism to execute code when an assembly is loaded by the runtime. If I could write a class like:
[AssemblyInitialization]
public class MyInitializer : IAssemblyInitializer {
public static void Initialize ()
{
do_some_stuff ();
}
}
to cause an initialization method to run automatically when an assembly is loaded, I'd be a happy hacker. A cleaner approach might be to have an attribute on the assembly itself that identified an IAssemblyInitializer implementor so that less reflection would need to be done at load time to identify whether an implementor exists.
I've been thinking about this problem because of the receipt of another bug report for crashes in a gtkhtml-sharp application because the app wasn't calling the ObjectManager.Initialize method to register the assembly's GType mappings. In all fairness, it's completely unreasonable to expect anybody to know they would need to manually call that method. I've been wanting to automate that registration ever since the ObjectManager functionality was added.
Lacking a nice clean mechanism like IAssemblyInitializer, I came up with a hack that generates .cctors which call the ObjectManager.Initialize method if an object's GType name is going to have to be registered with GLib.ObjectManager at runtime. This solution will most likely work for most users of gtkhtml-sharp, since a "new Gtk.HTML ()" statement is likely to be used pretty early, but it doesn't take much thought to come up with scenarios that will break it.
Generating a ton of .cctors also isn't a reasonable solution for scenarios like the automatic invocation of gtk_init. We'd probably need something like the IAssemblyInitializer solution to correctly deal with that problem.
May 07, 2004
§ ¶Can I see your license and registration?
I finally landed the patch that started several weeks ago with an idea/patch from Ben for how we could eliminate the need for boilerplate code to register new GTypes with the native type system. There's a fair amount of irony in the amount of effort it's taken in order to eliminate an 8 line copy/paste by users.
The patch currently generates an InvalidOperationException throw when it detects a subclassing scenario that it can't automatically handle. This happens when a ctor has parameters, but there is not a corresponding object property for each parameter. We have to call g_object_newv with a list of properties corresponding to the parameter list in order to instantiate the native object with a proper GType for the subclass.
If you run across one of these exceptions in your application, there are two ways we can resolve them. If there is a corresponding property, but it has a different name than the constructor parameter, we can add metadata to the API xml file to identify the correct property to set. There are examples in Gtk.metadata for this already. grep for property_name to find them.
The other option is to hide the ctor with metadata and manually implement it in a .custom file. There is an example of how to do this already in gtk/MenuItem.custom.
Hopefully this won't cause too much pain, but I believe it's a step forward for the binding to take type registration completely out of the user's hands. Some grepping of the generated source indicates that less than 20% (96 ctors, currently) of the ctors in gtk-sharp still need some manual intervention. I encourage everyone to try their apps out with CVS HEAD as soon as possible, so that we can fix these quickly. Also, if anyone has some spare time and wants to get proactive, you can grep the generated source for InvalidOperationException and get started mapping params to props.
May 05, 2004
§ ¶Transition
We released the first "beta" version of mono yesterday, after a hellish week of work. It never ceases to amaze me how much fun it is to develop software, and how little fun it is to release it. The weeks leading up to a release are like a run-away freight train. At least I think they are. I've never seen a run-away freight train larger than HO scale.
Gtk# is close to being ready. There are still a few details in the subclassing arena that need to be tied up. We also need to audit a ton of API. We've had several early adopters out there auditing API in realtime, but there's still a huge amount of API in Gtk# that has never been exercised, I'm sure. We're going to need help to get it all cleaned up in the next two months before 1.0 goes out the door. If you'd like to help make Gtk# as perfect as it can be, please contact me and I'll get you started with your own little corner of the API.