GTK# Beginners' Guide

What is GTK#?

This question maybe better answered by the GTK# site or the GTK# page on Mono's website. Simply, it's a wrapper on The Gimp Toolkit, or GTK+, a cross platform GUI framework that got its fame for the GIMP image editor and the foundation of Gnome desktop popular on Linux and FreeBSD desktops.

Currently, it works natively for any X server, Direct Framebuffer system, or even using the native Windows UI. That means, it works on pretty much everything but will look the best on Linux, great on Windows, and be functional on MacOSX (it may look out of place with the Aqua look which is the biggest issue I've seen). GTK+ has been around for years, so it's very complete, heavily tested, and already come preinstalled on almost all desktop Linux machines.

One big misconception is that GTK# requires Mono to work. This is far from true. All that GTK# needs is a .NET compatible runtime. Currently, the only runtimes I know of are MS.NET, Mono, and DotGNU. GTK# is regularly tested on MS.NET, DotGNU, and Mono. This means if you write your applications in GTK# and decide you wish to run on Windows as well, you can choose to deploy with just GTK# and use Microsoft's runtime, or deploy with Mono's runtime for Windows and deploy that way as well.

Download/Install GTK#

First thing you will want to do is get your GTK# install up and running.

Linux, MacOSX, FreeBSD, and others:

See if your distribution has GTK# devel packages as well as any Mono packages first. If not, check out Downloads to find a package that works for you. In the worst case, you may be forced to build yourself from source.

Windows:

If you are on Windows, pick yourself up a copy of the integrated installer from that download page. You also can grab a copy of the GTK# integration package for Visual Studio which will allow you to use GTK# without Mono.

I'm going to use GTK# 2.0 (v1.9.3 as of this writing) which is based on GTK+ 2.4. You may choose to use GTK# 1.0 (based on GTK+ 2.2) and most of what I'm going to go over should still apply. I highly recommend using GTK# 2.0.

There are other libraries that we commonly associate as being part of the GTK# framework, pr., Gecko#, Gtksourceview#, GSF#, Guile#, and GST# which are not packaged with the GTK# releases but in most parts part of the same bout. They are very useful for doing the specific things they provide but we won't touch on them too much here.

Step 1 - Get ready

The first part we need to do is create a new folder for our little project. (Windows users: let's avoid spaces in the folder name just to take out any headaches.)

You will then want to open a shell (if you are on Windows, open the Start menu and go to "Programs->Mono 1.x.x->Mono Command Prompt" and will set up your paths so you don't have to do anything extra). You will want to cd to that directory we just created. We are going to be using this window a lot so leave it running in the background.

Now go ahead, open up your favorite editor (MonoDevelop, vi, Emacs, Notepad, etc.) and setup a new blank project (if applicable) and create a new blank file. Go ahead and save this file as "helloworld.cs".

Step 2 - Laying it out

I'm assuming that you are familiar with C# so most of this will look normal. We will need to create a new reference to GTK#, and create a new class and entry point for our application. It should look something like this:

That should look pretty familiar to you. Just so we can get used to using the command compiler, let's go ahead and save this. Then switch back to our shell window and go ahead and run:

mcs -pkg:gtk-sharp-2.0 helloword.cs

Some of you that have used the CSC compiler on Windows may notice the "-pkg:" as a little odd. This doesn't exist in CSC because Mono comes from the world of Linux. What that does is lookup for a package config file under that name. In the package config folder exists a file named gtk-sharp-2.0.pc which contains (among other information) the location of the libraries for that package. That way we don't have to type out "-r:gtk-sharp-2.0.dll -r:atk-sharp-2.0.dll -r:pango-sharp-2.0.dll ...." all by hand.

Step 3 - The fun part

Now, let's jump back to our code. Go ahead and remove the Console.WriteLine statement. The first thing we are going to do is create a new window. We do this by adding a new Window statement and an application block (to start the main thread loop). Like so:

Now just compile like we did before and run it using 'mono HelloWorld.exe' and you should get something like this:

The first thing that you might notice, if you have used System.Windows.Forms, is that we didn't add any layout code for our label. For example, we didn't say 'myLabel.Left = 100' or 'myLabel.Width = 200' or anything to add the Label to the form, and just simply said 'myWin.Add(...)'. This is because a 'Gtk.Window' is a widget that inherits from a Bin, or single widget hosting Container.

Now you maybe asking yourself, "How do you then add more then one widget to a window if it can only contain one widget?" Well, we have other widgets that have the ability to contain multiple widgets at the same time. Some of those widgets will inherit from a Gtk.Box container widget or from the container widget directly in some cases. A Bin container widget inherits form the container widget directly as well, just like all other widget containers, but a Bin can only contain one control.

In order to have multiple widgets on our Window (since it's a Bin) we need to add one of those widgets that can contain multiple widgets. There are tons of controls that can do this but we really should concern ourselves at this point some of the basic ones like HBox, VBox, or even a Table.

The other part you may be interested in is what the Application.Init() and Application.Run() statements are for. If you have ever used System.Windows.Forms, it's similar to Application.Run() in many ways. Normally, when the application gets done processing any code on its main thread, the application will stop. Since ShowAll() doesn't block, the code would continue on and shut down. The Application.Init() command tells the runtime to listen for any Gtk.Windows launched, and when you run the Run command, it starts the main loop on those windows. That keeps the application running in basically a loop until all the windows are closed. For more information, check out the Monodoc information on the Application object.

It really doesn't get any easier than that. If you are used to System.Windows.Forms, that should be just enough to get you started. Now the documentation libraries for GTK# are all you need to continue on. Have fun.

Points of Interest

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

Share

About the Author

I spend most my days hacking the Mono core as well as helping out in the open source Mono community. I'm also a contributor to many different projects focusing mostly on bring exsiting systems to new operating systems.

I currently contract my services out to anyone not doing anything open source. Contact me if you are looking for a contractor or you have interest in Mono support pacakge.

Comments and Discussions

Well, let's take a look at a couple things. For example, the Gtk.Window class doesn't have a default constructor. The next problem is that Window doesn't support a collection, such as .NET's Controls property. In GTK#, child controls are added with the Add method. This makes it impossible to construct a window declaratively using reflection, hence the custom parsing that glade does.

I realize the architecture is supposed to mirror closely the GTK+ implementation, but I guess, if you're going to code it in .NET, then it should use .NET coding practices--parameterless constructors, collections derived from IList or ICollection, implementing IDisposable (there was a big discussion about that at one point on the GTK# forum), ISupportInitialize or something similar, etc.

It would be very possible to make it support tons of other interfaces and have GTK# do so is not as hard as making SWF do so. We are still in the active development phase of GTK# 2.0 as well so implimenting anything is still possible right as long as it doesn't change to much that the nunit tests start failing to bad. Adding a collection that contained the controls is possible but not to easy. We have a method but its not a native .NET collection. I might look into that later in making Gapi start to do that for a few things. I'm also trying to gain support for abstracting out some elements of System.Drawing's namespace into a stub library for people who can't install libgdiplus (the core to our GDI+ system on Linux) but sometimes can install GDK (our primate graphics library very similar to System.Drawing. Some objects overlap such as Rectangle, Point, etc. Also GTK# has its own timer and threading objects and glib provides and alterantive XML parser even though we don't use it in any exposed code. This are things provided by glib/gtk#. Its sort of a battle. We want to release under X11, but gtk/glib is LGPL.. some parts overlap. Some parts it does do faster and parts it doesn't. We also want to make it compatable but not all things are shareable and were we do it managed one way as a struct, its a real object in GTK# because it needs an underlying pointer or something. Somethings should be possible such as interfaces if don't correctly which is what I need to look at. (but IDisposable is scary for GTK# hehe). Some of this is solved in ngtk as well.

However part of the limited moving room is not all those coding standards are not in the emca docs, so it means we implimented them with the msdn docs. Those technologies could later be patented and if so we would have to remove them from our Mono implimentation. If things are cross linked from GTK# to libraries we provide that are not in corelib, then we can get in to a bit of trouble later with end users, even though we don't see a problem in it right now.

The other great project we are working on is Managed Windows Forms which is a nearly identical clone to System.Windows.Forms provided on Windows except it uses the System.Drawing namespace to do it all instead of invoking native UI elements on WIN32. We emulate as much as possible the way it works in Windows. This it the ablility to work on Linux, MacOSX, FreeBSD, etc, without having to wrap the native UIs of each. However setting Application.UseVisualStyles (i think thats what its called) will make use of a native GUI skinning system if its there like Cocoa and GTK+ . Its in the development releases of Mono right now as well.

Well there do exist GTK+ components that are sold, but they are rare. What does exist is thousand and thousands of open source GTK+ componets. With the Mono gapi tool kit you can quick generate a set up C# that you can compile into a c# library to use it. When I say generate, I know it starts making people feel like loosing their lunch in the windows world, but its far from the case with use of the GAPI tools. They are rather undocumented but amazing things on their own. Yet another good article could be written on this subject as well.. After you learn that all you need to worry about is that most componets do come from the Linux world so while most components are released under X11 (even more freen then BSD) or LGPL some components release under GPL. If you are writing a closed source application you want to avoid GPL. Even in the base pacakge, there are tons and tons of controls. When I write an article on Managed.Windows.Forms (our System.Windows.Forms but using a fully System.Drawing based method) I will post on how you can mix controls that you pay for on there. Dundas (however you spell it) also is working with us to make sure they are Mono compatable.