Of course, repo.bzr is your old bzr repository here, while repo.git is your newly created git repository. The fast-export/fast-import commands convert the repository’s history from bzr to git. To populate our directory with the bzr repository’s files, however, we also need to perform a hard reset. If you need to convert multiple bzr branches to git, have a look at this post.

I started experimenting with distributed version control systems (DVCS) while working on my MSc thesis (around 2005). I originally maintained Cassowary.net using darcs (a DVCS written in Haskell), and switched to bzr later. Back in the early days of Uiml.net, we used CVS, which was horrible at moving or renaming files, not to mention the inability to work offline and still commit your work.

I preferred darcs and bzr over git at the time because they were a lot easier to use. These days, git seems to have catched up to bzr in that regard. Back in 2006, I also did a few performance tests and found that bzr was a lot slower than git. Things seem to have improved somewhat, but git is still The King of Speed. Oh, and GitHub is great!

I am currently working together with Jan on improving the Gummy tool (website still under construction). We have come a long way since Jan wrote the first version for his Master’s thesis. I figured it might be interesting to share a few screenshots of different phases in the development:

Here’s the first version (June 2007):

A version with roughly the same UI but lots of architectural improvements (November 2007):

The current version with an improved UI (March 2008):

I think the most significant improvement is the new toolbox. Designers can now more easily distinguish between different widgets. In previous versions, some widgets were hard to distinguish. We added labels to each widget in the toolbox, and improved the inline rendering of the widgets. Notice that these images are still not predefined icons, but real widgets rendered to a bitmap. However, in the current version we chose to render them at their optimal size and then scale the images down.

Rendering widgets to bitmaps also forced us to migrate to Windows. We started our development on GNU/Linux using Mono but had to switch due to an annoying bug in Mono’s implementation of Control.DrawToBitmap. Future versions should be able to run in Mono again when this bug is fixed though.

Update: Jan sent me a screenshot of an even older version of Gummy, dated back to December 19, 2006:

In this paper we introduce a multi-platform user interface design approach, and Gummy, a design tool to support that approach. This work originated out of Jan Meskens’ Master’s thesis, in which he created a UIMLGUI builder. While there are several tools for developing multi-platform user interfaces, these have a number of problems: (1) the resulting user interfaces often lack the aesthetic quality of manually designed interfaces; (2) the tools are not intuitive since designers have to deal with abstractions and do not directly manipulate the user interface design; and (3) designers can not accurately predict what the resulting user interface will look like. Our goal was to allow designers to reuse their skills of existing user interface design tools (such as GUI builders) as much as possible and try to maintain a high level of fidelity (unlike sketch-based design tools).

We also had a short paper/poster about Gummy accepted to CHI 2008 Work-in-Progress. In this paper we explain how the tool can be used to involve domain experts in the user interface design process.

We received lots of input on the prototypes and early drafts of the papers, so thanks to everyone at our lab who contributed in one way or another Additional thanks go to Karel Robert for creating the Gummy logo (have a look at his portfolio).

I spent some time the last weeks to support type decoding plugins in Uiml.net. This is mainly useful when you want to interact with applications or web services that have their own types that need to be converted to something the widget set understands. Suppose for example a web service returns a set of Persons, which need to be represented in a list view. The renderer does not know how to transform a Person into an item of a list view, so you need to define a custom component that sits between the renderer and the web service, and can provide this conversion. However, since you don’t know which widget set is used, you have to do this for every possible widget set (e.g. System.Windows.Forms, Gtk#, System.Windows.Forms on the Compact Framework, etc.). Furthermore, it would be better to let the renderer manage this code.

So I created a type decoder plugin system and while I was at it, also cleaned up the code. This resulted in only one general TypeDecoder instance being created in the renderer, while we previously had one instance per backend. Now we have a container class in each backend to host widget set-specific type decoders. This container class get registered with the TypeDecoder, and is in fact also a plugin.

Instead of going into the implementation details, let’s have a look at an excerpt from the System.Windows.Forms container class (SWFTypeDecoders.cs):

The only thing we have to do to define a type decoder method is add the [TypeDecoderMethod] attribute and support as a parameter the type we want to convert from. The return type is what we will convert to. In the above listing, the DecodePoint method converts a string to a System.Drawing.Point. The [TypeDecoderMethod] attribute is used to declare that the corresponding method is a type decoder. This way other auxiliary methods will not be registered and won’t pollute the type decoder registry.

To test the implementation, I created a simple class that connects to del.icio.us and gets all my tags. I use this class to show them in a Gtk# UIML GUI. To be able to convert between the XML document that is returned by del.icio.us and the user interface, I wrote a custom type decoder, and connected it to the renderer. I also have a short screencast showing its workings.

I have extended the Uiml.net type decoder to combine existing type decoding methods if direct conversion is not supported. In this example I created a type decoder to convert from a System.Xml.XmlDocument to a Uiml.Constant. But the Gtk.TreeView widget requires a Gtk.TreeModel. The renderer will therefore look for a conversion from a Uiml.Constant to a Gtk.TreeModel and apply the type decoders in sequence. Although we could have converted directly to this data type, this is not as flexible since it is widget set-specific. Although the interface will remain the same, I will probably change the underlying implementation to a graph with the types as vertices, and type decoders as edges to better support these indirect conversions.

In my previous post I wrote about this year’s Master’s thesis students that will be working on Uiml.net. However, I hadn’t blogged about what last year’s students accomplished yet.

Ingo Berben chose a Bachelor’s thesis to improve the standards compliance of our renderer. He eventually concentrated on the behavior section, and more specifically on supporting conditions other than events. The movie below shows how this can be used to support form validation. The renderer checks if every field is filled in, and displays a message accordingly.

[youtube:http://www.youtube.com/watch?v=_klRnaicdVg]

Rob Van Roey worked on support for multimodal user interfaces for his Master’s thesis. He implemented a new X+V backend for Uiml.net, which is thereby the first backend that renders to another XML document. The movie shows a multimodal user interface for controlling a smart home, in which Rob turns off the lights and turns on the alarm after saying the correct password.

[youtube:http://www.youtube.com/watch?v=d94WX16ac2s]

Finally, Jan Meskens created a UIML design tool on top of Uiml.net. The workspace of the tool is generated dynamically according to the loaded vocabulary. The movie shows the basic working of this tool. Jan joined our ranks after his studies, and will continue to improve the UIML designer.

[youtube:http://www.youtube.com/watch?v=p26-BtXxKaM]

Ingo’s code is already available in a separate Uiml.net branch, and will soon be merged into the mainline. Jan is also working on integrating his work. When I find some time, I will probably merge Rob’s code as well.