Sunday, January 22, 2006

GUI frameworks available for .NET: GTK#

This is my second post about user interfaces available for the .NET, which I will probably call the "CLR" from here on out, since its easier on my fingers. The first part is here, be good to it.

As a special note, GTK#, the toolkit I'll be talking about, just recently had a new release. I'm going to be discussing an older version because I have not really had a chance to explore this version in depth.

Now we're going to discuss...

GTK#
A binding to the graphical user interface called GTK+, GTK# is easily a step above the rest when it comes to API quality and expressiveness, when you consider the alternatives. On the pecking order, GTK# comes in closely behind WinFX, and way, way ahead of S.W.F and wx.NET. I'm going to ignore GTK+ entirely, and write this blog post as if GTK# was the whole kettle.

GTK# uses a container based layout system, which is basically a fancy way of saying that you drop down a container, tell it how you want it to layout your controls, then start flinging those controls like spaghetti onto an artist's canvas. Although this sounds pretty haphazard in theory, its possible to make a beautiful and usable user experience using GTK#.

GTK# uses an xml-based serialization format, called Glade, that enables an abstraction between user interface design and wiring up the controls to the data-driven back-end. Unfortunately there are very few graphical designers that support GTK# and Glade, and so inevitably you have to rely on The One True Glade Designer. Its got an awful user interface and should not be used to judge the abilities of GTK#, because it falls short. Very, very, very short. Midget short.

There's plenty of base controls, in particular the powerful TreeView that allows for different styles of data visualization. However, there is a distinct lack of convience when dealing with GTK#: although virtually nothing is impossible due to the robust way GTK# is built, some of the most commonly repeated idioms do not have any convient shortcuts, which means that for even some of the simpliest scenarios--like simple listboxes filled with text--require an inordinate amount of effort given the task you want to accomplish. It would be nice if GTK# shipped with a lot of prefabbed controls for the most common user interface idioms, but that does not seem to be the kind of development paradigm they're going for.

GTK# is crossplatform in theory, but the platforms with the strongest support are really just various Linux distributions and of course Microsoft Windows. It can run under Mac OSX, but I have been told that it is not a pleasant experience by some. Not having a Mac, I can't really say anything more. I myself have successfully gotten GTK# programs to run on Windows and Ubuntu without recompiling.

There's a lot of things that seem to be amiss if you touch on GTK# after having done WPF development for awhile; most notably, you can't arbitrarily place a control inside of a control: you'll have to "paint" it by hand yourself, and, as far as I know -- I haven't done anything beyond *drawing* the controls -- wire up the events as the parent control receives them. It is nothing brutal, but the time spent custom painting controls could be better spent doing something--anything--else. Most toolkits suffer this flaw, so if you have no experience with WinFX, then custom drawing is standard. Other things WPF developers will find lacking is "styling" and the magic of the, uh, what'chu'call'it, DataContext, I think, but that's about it.

All in all, its a pretty good toolkit if you need to write an application targeting Mono and any of the platforms it supports. I think if a lot more effort was put into making the API more agile then it could see itself being on common footing with WinFX. It compares quite nicely at its current state, however, so don't dismiss it outright. ;)

Score: 7/10

No comments: