Misconceptions about the Glade# Code Generator
So there seem to have been quite a few misconceptions about the Glade# code generator, both recently and a few months ago, that I want to clear up.
New Feature
Before I get to that though, I now have (mostly untested) support for both VB.net and Boo:

If you use either of these languages please test this out and let me know how it goes.
Anyway.. now onto other things…
First of all, what does it do?
The tool generates source code from glade xml files. Specifically, the following is generated:
- Constructor that loads the XML and Autoconnect()s members in the class
- A public Show() method for GtkWindows
- A public Run() method for GtkDialogs
- A public Popup() method for GtkMenus
- Private fields with the [Glade.Widget] attribute reperesenting your widgets
- Empty methods to handle signals (events) you have defined using Glade.
What’s the point?
When writing this application, here is what I had in mind as it’s indended use:
- A good way for new users to get an idea of how to use Glade in their Gtk# applications
- A way for everyone else to save time.
What doesn’t it do?
- It doesn’t write out the whole GUI in Gtk# code. You still use glade# auto connect.
I really think that would be a stupid thing to implement. One of the things that drives me crazy about SWF/VS.net is the fact that everything you do in the forms designer is stored as source code. This is slow – because it has to constantly parse in your code – and stupid – because it’s just straight up not what you should use source code for. I cannot even count the times I have completly broken the vs.net forms designer or actually lost lots of work because of either mistakes in it’s parsing or because I wanted to change something that it wasn’t happy with.By using glade you can keep the basic layout of your GUI seporated out so your source files stay nice and clean – and you still retain the ability to add in custom widgets later on using code.
- It doesn’t try to update existing source files in any way. It’s just a tool for getting started.
Some people say that without this feature the tool is useless. I don’t agree – I already find it to be a good timesaver – but I certainly agree that the lack of support for this makes the tool much less useful than it could be.I have no plans to implement file updating myself. I’m busy, I have other things to do.
That said, if somebody else would like to write a tool that does do this (I hear the stetic developers plan on this) I still feel that this is a good piece of code to start out with, and wish you the best of luck.
Other Notes
- It doesn’t work in Windows
Several people have told me that it fails horribly on windows due to Gtk# problems. If anyone has Gtk# SVN head running on windows please test this and let me know what happens.
I hope this clears up any confusion that any of you may have had.
If you are a Gtk# developer who uses glade, please check out the application and let me know if you find it useful. I really appreceate your comments (as long as they are constructive).
Categorized as Open Source, Mono, Technology, Software Development, Technology
Well I cooked a similar utility, that makes things a bit easier for updating your form (current limitation is that it handles only one Gtk.Window per glade file and nothing else). It is very nice that your utility deals with more kinds of glade top level objects.
Basically what mine does is generate a base class for your form class from which it must inherit. This abstract base class has all widgets as protected fields and all event handlers as abstract methods, what makes mismatched things somewhat easy to spot on compilation not at execution time.
I’m going to change it to use partial classes as mcs works nicely with them now. That still brings the advantages of separate editing and compile-time verification, but doesn’t interfere with the inheritance hierarchy.
Just exchanging some ideas on the topic…