Scribbling 3.0 Style

Just a quick update. Got a little farther with the samples the last couple evenings. Fixed up a few bugs causing some issues with a couple of the ones that already build, like native-instantiation.exe. Then I tore into Scribble.cs.

It was originally ported from a gtk example back in the early days. It may have been before we really had much subclassing support in Gtk#. I decided to see if gtk+ was still shipping the sample, and just do a clean port of the current sample instead of trying a minimal update.

The majority of the work needed to port the old sample to 3.0 boiled down to a Gdk.Pixmap to Cairo.Surface port. The ExposeEvent to Drawn event transition was needed as well. This is starting to sound a bit like a broken record, though I would imagine many readers have never heard a broken record.

But I digress.

The finished port of the gtk+ sample is now in master, along with all the fixes to the stack to expose some needed API that wasn't getting generated. The list of non-working samples is getting shorter.

More Progress

Been slogging along with the process of auditing API and fixing samples to compile and not crash instantly. Things got a whole lot more stable in the last couple evenings. I pushed a bunch of updates today that allow the cairo drawing sample in the Gtk# samples to run cleanly.

The configure now requires the gtk+-3.0.0 release since it has hit the streets. There was a bit of API churn between 2.99.0 and 3.0.0, which accounted for one of the more insidious crashes to track down. Geoff Norton helped me figure that one out today, and when I reparsed for the 3.0 API a lot of things fell into place.

The size negotiation and drawing API changes are going to make for a little work when people start switching over. These are the most common trip-ups I'm experiencing in the samples. Any custom widgets which overloaded Widget.OnSizeRequested in 2.x will need to pick one or more of the new negotiation VMs and port to them. For example, in the PolarFixed sample, I made the existing OnSizeRequested method private and delegated to it from new overrides for OnGetPreferredWidth and OnGetPreferredHeight.

In CairoSample, the only substantial change required was converting the old OnExposeEvent override to a new OnDrawn method. The new method utilizes the new AllocatedWidth and AllocatedHeight properties to obtain sizing info to pass into the rendering methods. Of course, the code was already drawing to a Cairo.Context, so the logic was ready to go. A widget using the Gdk drawing API, or Style painting may have substantially more work to make the shift.

I'll try to blog more impressions of the porting effort as I move through the samples, and I encourage anyone who decides to dig in with their own apps to try to capture the knowledge, be it by sending a message to gtk-sharp-list, blogging, or adding them directly to the porting guide I've started on the wiki.

Signs of Life

With gtk+ closing in on their 3.0 release, many folks have been inquiring about Gtk# 3 lately. We've had a number of offers to help as well. I've been tied up with another project at the ol' day job, but I've been dedicating a fair amount of evening and weekend time toward 3.0 bindings since the holidays. It also looks like I'm going to be getting some more cycles to push the effort forward in the near future.

Over the past couple evenings, I've pushed a series of commits to github.com which update master to a 2.99.x API level. Several of the samples are still not being built because of 3.0 API breakage. Most of the samples which currently build also run cleanly, but there are some crashes there to address as well.

I've temporarily created a cairo-sharp.dll from the copy of Mono.Cairo we have been carrying in the tree, with a few updates to expose some of the new 1.10 API. This will likely get merged back into the mcs/class tree, but it's a convenient place for us to move fast with fleshing out the new bits.

The generated APIs are completely unaudited at this point. The improvements in the external Gio and Builder bindings since they spun off remain unmerged. There is plenty of work to go around if people would like to jump in and help. We are going to need migration docs, new API docs, the list goes on...

Since people are likely wondering, the module still starts from a C parse. I have experimented with starting from GIR format but feel at this point, given the current tooling state, that it will be quicker to get to 3.0 using the existing GAPI parser for gtk-sharp. Since this is getting long already, I'll expand on the reasons in another blog, plus talk about the approach I think we can take to begin incorporating GIR as a starting point in new bindings.

Mono Visual Profiler

We're seeking the input of profiler users and other interested parties to help create a visual profiling tool for mono applications. Development is under way in the mono-tools module alongside the current command line decoder. The tool is a UI to interact with the built-in mono logging profiler and graphically display captured profile logs. The visualization capabilities of the tool are still fairly primitive, but it is already capable of creating and displaying log data for instrumented, allocation, and statistical profiles.

I have created a wiki page to track the feature capabilities and plans. There is also a "Visual Profiler" category for bug reporting and enhancement requests in the Mono:Tools bugzilla product. Discussion will occur on mono-devel-list.

Gtk# for .net

Forgot to blog about this when it happened, but since I've gotten a couple of questions lately...

In February, we released a new version of the Gtk# for .net installer. It packages Gtk# 2.12.8 and the associated gtk+ binaries, including the registry keys necessary to build projects with MSBuild and add references using the references dialog in VS.

This single installer combines the managed development functionality previously provided by both the SDK and Runtime installers in a significantly smaller download than the old SDK installer, since it no longer ships many of the C development files packaged in the old installers. This installer also works properly on XP and Vista, unlike previous versions.

In the near future, we will be announcing the availability of additional installers supporting the use of mono libraries like Mono.Posix, Mono.GetOptions, and Mono.Addins on .Net and maybe a new application installer or two as well. Stay tuned.

Gtk# for .Net installers

Today, by popular demand, we announced the availability of win32 installers for Gtk# version 2.12.6. Runtime and SDK installers for .Net similar to those provided in the past by Medsphere are now being provided from the Mono project downloads page.

Hack Week: 1WPF

For Novell Hack week, instead of hacking on exert as I did in the past, I chose to spend some time on a MonoDevelop Gtk designer restructuring project I've been considering: one widget per design file.

The current designer architecture is based on project-level design files, saved in a special hidden directory along with generated source files needed to compile the designs. This design decision builds upon the existing stetic project-based file format. It complicates several common operations, however, some of which have open bug reports.

One problem is the ability to either copy or move widgets between projects. Another, is the ability to add existing widgets to new projects as "external files" so that a single design can be reused by multiple projects. When the design of the widget is saved as a child element of a project-level xml document, all of the above operations are considerably more complicated than if the widget design is contained in a standalone file.

I'm implementing this redesign as a new addin in MonoDevelop, so that I won't have to pay as much attention to feature parity with the existing designer. The hope is that at some point we can just switch the default designer to the new addin, once it reaches maturity. Based on the amount of work remaining, this will clearly be post-2.0.

Thus far, I've ported the existing addin extension code and begun the rework of the stetic WidgetDesigner. Currently supported features include:

• SolutionPad display bindings and extensions
• Grouping of related source, design, and codebehind files.
• A CodeDom based project template to create Application projects in mulitple languages.
• Project Compilation extensions to generate codebehind files, capable of compiling template projects.
• CodeDom templates for ActionGroups, Dialogs, Widgets, and Windows.
• Toolbox provider and loader.
  
• WidgetEditor built on existing stetic wrappers and class descriptions, currently view-only.

Here's a screenshot of a template project in C#. The template also compiles already in VB.net.



Once I get the widget editor working, I'll probably go ahead and check in the addin for people to play around with. No current estimates on when that might be other than, "when it's ready."