Writing proper GTK+ Widgets is difficult and time consuming. One of the big problems is the intricacies of the Gnome Object Model; the amount of boiler plate code that needs to be written to write a new class. Even writing a class that simply inherits from an existing class and adds some new state or behavior in tedious.

The problem is the syntax - the Gnome Object Model is a library for the C programming language that supplies a complete object model with inheritance, interfaces, reflection (for introspection) and so on. Where you might expect to see language features in an Object Orient language, you instead find naming conventions, macros and library function calls. Mastering the Gnome Object Model is no mean feat, and since C language bindings are preferred (possibly even expected, new Gnome libraries really need to be written in C. Or so that was the case until Vala came along.

Vala is a new language with syntax similar to C#. Vala does not compile directly to machine code, nor does it run on a virtual machine like .NET and Java. Rather, it translated into portable C code that is then compiled to machine code. The beauty of this is that the developer gets the benefit of writing in a higher level language than C which has appropriate language features while still being able to produce and distribute standard C language bindings for the Gnome Platform.

In this blog entry I demonstrate how to write a proper GTK+ Widget in Vala and compare it to what is required to write the same widget in C.

Future releases of ADO.NET Data Services will provide a data replication and synchronisation feature that will enable data centric applications to work transparently in both online and offline modes. The project charged with implementing the replication and synchronisation features is known as "Astoria Offline" and has just reached its first Community Technical Preview (CTP).

While it's still early days for Astoria Offline, there is enough information around to get an idea of what Astoria will and won't offer to developers.

A Visual Studio 2008 Solution with the complete code listing for this posting is attached.

Through the use of ControlTemplates we are able to customise the look and feel of all WPF controls. Here I will demonstrate using a ControlTemplate to make the ScrollBars of the ScrollViewer draw on top of the content it is scrolling rather than beside and below the content. Making the ScrollBars semi-transparent allows the content below to be seen through the ScrollBars.

Following on from my series on embedding DLR scripts in XAML, I present an implementation of John Conway's Game of Life in XAML/WPF using embedded Python scripts. The game is loaded completely from loose XAML. Even the initial game state is defined in dynamically loaded XAML files!

The game is hosted in the very dynamic application described in a previous post. Below is a screen shot of the hosted Game of Life applicaiton.

A Visual Studio 2008 Solution with the complete code listing for this series is attached to this post.

To conclude this series of posts, I will build a simple application using many of the DLR Scripting goodies presented in this series. I will use Python as the scripting language, but you could use Ruby, JScript or any other language that has bindings to the DLR.

The idea here is to write a minimalist WPF application in C#, pushing as much logic as possible into the XAML and DLR Scripts, and as you will see, we end up with very little logic in the C# code!

A Visual Studio 2008 Solution with the complete code listing for this series is attached to the final part.

As discussed in the previous article, GUIs are all about layout, style and wiring. WPF has the first two in spades; XAML is an excellent language for doing layout and styling of WPF GUI elements. However, sorely lacking in WFP is the ability to route commands and events in dynamically loaded XAML. This makes any attempt to build truly dynamic XAML based GUIs near on impossible as at some point you will have to handle an event, but it is hard enough to route an event to a static method let alone have a script execute in response to an event being fired!

Inspired by Josh Smith's work, I demonstrate how to use an attached property to establish a DLR script as an event handler for any WPF routed event.

A Visual Studio 2008 Solution with the complete code listing for this series is attached to the final part.

GUIs are all about layout, style and wiring. WPF has the first two in spades; XAML is an excellent language for doing layout and styling of WPF GUI elements. However, sorely lacking in WFP is the ability to route commands and events in dynamically loaded XAML. This makes any attempt to build truly dynamic XAML based GUIs near on impossible as at some point an event is going to need handling or a command issued.

Continuing the series on embedding DLR scripting in XAML, here I demonstrate how to implement a scripted WPF Command, making dynamically loaded XAML one step closer to being a first class citizen in the WPF world.

A Visual Studio 2008 Solution with the complete code listing for this series is attached to the final part.

The WPF Binging class is very powerful and its use should be encouraged. However, it can be cumbersome to do some very simple things with it, introducing a barrier to its use. One such barrier is defining a ValueConverter.

A ValueConcverter is a class that can convert the source property value of a binding before it is set on the target property. Often such conversions are simple expressions that do not warrant the creation of a new class - though this is what is done.

The first article in this series demonstrated how to host the DLR and presented some utility methods that make executing scripts simple. Here we build upon this to create a ValueConverter that evaluates a DLR expression that supports two way binding.

A Visual Studio 2008 Solution with the complete code listing for this posting is attached.

It is quite common to augment data with metadata. An example is the set of tags on this post. How would we represent such metadata in a XAML document?

XAML provides a method for augmenting our objects - the Attached Property. It would be very simple to have a "Metadata" Attached Property whose type is a collection of metadata objects. When this attached property is set, the metadata is stored in the appropriate place and cross referenced with the data object to which the metadata refers. Simple! Well, not really.

The Attached Property method is all well and good so long as the data object is a DependencyObject because Attached Properties can only be attached to DependencyObjects. It is possible, however, to use a MarkupExtension to do a lot of what an Attached Property does.

In this article I demonstrate how to use a custom MarkupExtension to register metadata for non-DependencyObject types.

A Visual Studio 2008 Solution with the complete code listing for this series is attached to the final part.

This article demonstrates how to embed DLR scripts in XAML using a custom MarkupExtension. The scripting language can be any language supported by the DLR, such as Python or Ruby.

The first article in this series demonstrated how to host the DLR and presented some utility methods that make executing scripts simple. Here we build upon this to create a simple MarkupExtension that evaluates a DLR expression.