Good enough

This morning, I committed the ilContrast tool I blogged about on Sunday. It is in the mono-tools product in svn trunk. The tool can compare two individual assemblies which you can provide either by cmdline argument or interactively using the FileChooser.

Some potential features remain for bored hackers and artists to implement:

• It needs a super-sexy icon. I just copied MonoIcon.png.
• It could probably use some persistence mechanism to recall the last "project".
• Multiple assembly comparisons. The mono-api-info tool looks like it can do it, just needs hooking up.
• Maybe a tabbed view for displaying multiple comparisons.
  
• The About dialog could use translation to 67 different languages.
  
• It has a hard dependency on Gecko#. A fallback to GtkHtml like monodoc provides might be useful.

After finishing the standalone tool, it occurred to me that this might have made a nice MonoDevelop plugin instead. But the tool is handy as is, and will probably work its way into my Gtk# hacking.

Update:

In case anyone was actually considering the GtkHtml fallback hack, don't bother. As Miguel pointed out to me, the javascript requirement makes that a non-starter. A more likely hack in that area would be to remove the Gecko# dep by directly rendering the mono-api-diff output with Gtk# itself, perhaps using a TreeView.

ilContrast

After helping Miguel with a corcompare run on IRC Friday afternoon, we decided it would be nice to have a GUI tool that would hook it all up for you. Running the three cmdline tools in the current manner is not the most user-friendly experience.

I threw a few hours at the problem this weekend and have a little Gecko# frontend sort of working. It has a few warts, but it's at least to the point of rendering recognizable information. Look for it to hit the mono-tools module some time this week, hopefully.

Hang on

Delegate persistence is an interesting challenge in a pinvoke binding like Gtk#. Hang on to delegates too long and you tie up the delegate instance memory and keep objects alive which are providing the delegate's invocation target. Release the delegate too soon and you get crashes when the native code tries to invoke it posthumously.

Most of the callback parameters in Gtk+ are destroy notified, taking away the guesswork of when to release the delegate. We have supported notified delegate release for a while now.

Of the non-notified callbacks, most only need to persist for the duration of the method to which they are passed. Foreach methods are a common user of this style of delegate scope. I refer to this as "call" scope. You may have noticed warnings for method parameters defaulted to call scope. The generator treats all callback parameters as call scope if the method signature doesn't contain destroy notification and a scope attribute isn't explicitly provided via metadata.

The challenge appears when a callback parameter doesn't fit into either of these paradigms. There are callbacks which persist until removed by another method. Some of these luckily also provide destroy notification, but not all of them. There is also another class of callbacks that I will call "async" since they are typically provided to allow non-blocking implementations of functionality. The task is queued up by the method call and control returns before the task is actually completed.

Often these async methods take a delegate parameter that is invoked at the completion of the operation to notify the caller the operation is finished. I ran across an example of this method type while documenting the new Gtk printing API from 2.10. Since I was bored of writing documentation, I decided to take a crack at implementing async scope callbacks in the generator.

If you have any async callback delegates in your bindings, you can now add the scope="async" attribute to the parameter with metadata to automatically handle the persistence for this new scope.

Back in the Saddle

After a lengthier than expected hiatus, I've been turned loose again to dedicate most of my time to Gtk#. I'm looking forward to adding some new features and improving the memory management of the existing bindings.

I've completed an initial triage of outstanding bugs, along with some work bringing the documentation up to speed with current monodoc updater. I use the monodoc update as a first check for API stability, in addition to the CorCompare-based audit mechanism in svn, so it's important to me to have the docs updating with as little noise as possible.

My initial focus will be working on the higher priority bugs, while also documenting and auditing the remainder of the new types added in the Gtk# 2.10 release. While I document the new types, I'll be auditing the API for correctness and making any adjustments for members the automated code generator bound incorrectly. Hopefully within a couple of weeks I'll be able to move on to new features like GInterface Registration.