Archive

Archive for October, 2008

Giving Glade a fair shake

October 14, 2008 Leave a comment

As soon as I mentioned XAML and XUL, somebody pointed out to me that Gnome on Linux also allows you to define your user interface declaratively using XML with Glade. The v3 release of Glade uses XML to define the properties and layout of GTK widgets in a way very similar to WPF and XAML. Since XAML is only supported on Windows right now and Mono is probably a long way from any WPF support, I thought I’d give Glade a try. If it works well enough, loose XAML pages could be just an XSL transform away from Glade XML for creating GTK apps.

Since Ubuntu is the “Red Hat of the future” for bringing Linux to the mainstream desktop, I decided to do this on Ubuntu and found that getting a usable application together is pretty simple. To avoid trashing an existing PC, I installed Sun’s VirtualBox to create an Ubuntu installation there.

Once Ubuntu is up, go to Applications | Add/Remove Programs, and search for “Glade”. Add “Glade Interface Designer” (if you see more than 1, choose the more popular one just like you’re building the perfect kickball team). At this point, you can go through this tutorial to learn the basics of Glade.

Once you have a basic UI defined in Glade’s XML, this is fairly analogous to your XAML file in WPF, and you’ll need to write some code to load up the application and handle UI events (signals). This is all defined in the tutorial, but what the tutorial doesn’t cover is how to set up your development environment, so I’ll go through that here.

Ubuntu doesn’t come with all the development tools or GTK header files installed, so you need to download those. For C/C++, you need to execute apt-get at a terminal to download and install the development tools you’ll need:

sudo apt-get install build-essential
sudo apt-get install libgtk2.0-dev
sudo apt-get install libgtk2.0-doc
sudo apt-get install libglib2.0-doc

If you go through all the forums, you’ll find that everybody wants you to use GEdit and make for writing your code. I tried that first, and aside from the fact that you have to do command line debugging, it works pretty well. But if you like an IDE with an integrated debugger, Eclipse is the best (and still open source so hopefully I don’t get attacked for recommending it). However, Eclipse will flip out if you don’t configure it correctly, so follow these steps.

You can get Eclipse using the same Add/Remove Programs in Ubuntu, but you need to switch “Show:” to “All Open Source applications” or “All available applications” and search for “eclipse”.

Once Eclipse is installed, you need to get the tools for C/C++ development, run it, and from the Help menu, choose “Software Updates” –> “Find and Install…” Select “Search for new features to install”, click “Next”, check “Callisto Discovery Site”, click “Finish”, choose the nearest mirror site. When you get back the “Search Results” screen, expand “Callisto Discovery Site” and check “C and C++ Development Tools.” Click Next to continue through the installation process. When prompted, go ahead and restart Eclipse.

When Ecplise starts back up, go to the File menu, click New | New Project, and then expand the C or C++ node to get to a Managed Make C or C++ project (whichever you want). Once you get the project up, you can create a “main.c” for creating the code per the Glade and GTK+ tutorial I mentioned above. When it starts complaining about not being able to find gtk.h, whatever you do, don’t start trying to add Includes and Link Libraries . This is not the Linux way. Instead, right click on your new project and go to Properties, then go to the settings for C/C++ Build.

Under the GCC C Compiler (or GCC C++ Compiler if you’re build .cpp files), go to Miscellaneous. At the end of the “Other flags” text box, add the following, which will execute pkg-config to get the correct includes for your system:

`pkg-config --cflags gtk+-2.0`

Also, under the GCC C++ Linker, Miscellaneous, “Other flags”, add the following, which will get the correct libraries and tell the linker to export any signal handlers you add to widgets in Glade:

`pkg-config --libs gtk+-2.0 gmodule-export-2.0`

Now you should be able to build and run your code directly from Eclipse. If you get warnings on the Eclipse console about “Could not find signal handler”, either you are missing the “gmodule-export-2.0” or your method signature for your signal handler doesn’t match what is specified in the XML file created by Glade Interface Designer.

One last thing – in the Glade and GTK+ tutorial, they use gtk-builder-convert to convert the file from libglade format to GtkBuilder format. It makes sense to do this in a pre-build step, which you can also do from the project properties. Under C/C++ Build, click the Build Steps tab, and under the Pre-build step Command, enter something like this:

gtk-builder-convert ~/workspace/MyGladeProject/GladeUI.glade ~/workspace/MyGladeProject/GladeUI.xml 

That way any changes you make in Glade Interface Designer will make it over into the file you’re loading in your GtkBuilder calls. It would be nice if there were an Eclipse plugin for Glade Interface Designer that would load the application within Eclipse and provide a fully integrated environment, but until that happens, the Pre-Build step saves a lot of headache.

All this took me about a day to figure out, mostly spent messing with different Ecplise options before I decided to stop trying to configure the Includes and Libraries and just use Miscellaneous to make the call to pkg-config. Hopefully this saves someone else a lot of time.

As far as my XAML to Glade/GTK+ XML comparison, they are actually very comparable for the most part, but the one major thing missing from GTK+ in general is declarative data binding. You still end up writing a lot of code just to get and set data in your UI. This guy seems to agree, and there is a Gtk-Databind project for GTK#, but unfortunately it doesn’t seem to be getting much attention by the core GTK development group.

XAML and Code Separation

October 7, 2008 3 comments

XAML allows you to create a user interface to display and interact with data declaratively, with little or no code. Microsoft obviously wants you to create a code behind file for every XAML window or control you build, but if you can avoid that, you’ll gain some terrific flexibility in your application. XAML becomes nothing more than your presentation layer – a complete user interface definition in XML – no business logic or data access code intertwined with your UI. If your user interface is just a string of XML, you have a lot more options for deploying, maintaining, and extending that user interface beyond just compiling it into your application. Store it in a file system, store it in a database, generate it dynamically at runtime with XSL…

XML based UI technologies have come a long way over the years with technologies like XUL which powers Mozilla applications and MXML for Macromedia’s Flex. The real strength of XAML is in data binding and its tight integration with the .NET CLR, which is generally the platform of choice for business applications. With data binding, your UI elements are truly observing your underlying data which means when the data changes, the controls update automatically without any extra code. Of course, extensibility is one of the most important features of any API, and with XAML and WPF there are many options for extensibility that are in easy reach of any developer familiar with .NET.

To build the WPF extensions necessary for a loose XAML application, you will probably need to become familiar with a few things that aren’t in a traditional Windows or Web application developer’s toolkit.

  1. Reflection
  2. Application tracing
  3. Command interface (System.Windows.Input.ICommand)

Reflection will allow you to make components that are highly configurable, which means they are very reusable in many different scenarios. You can adjust the configuration at runtime using CLR properties and WPF dependency properties. Just about everything in XAML uses reflection to some degree, so becoming familiar with the technology is very helpful.

Probably the most frustrating thing about declarative data binding is there is no source code so you can’t easily debug your application to find out why something isn’t binding or updating. However, .NET has plenty of built in tracing features that will help to explain why things aren’t working as expected.

One of the first problems that occur when trying to use loose XAML is that event handlers can only exist in a code-behind class, which you won’t have in a XAML only scenario. With WPF, Microsoft added the System.Windows.Input.ICommand interface, which is a way to receive input from your application without event handlers. ICommand has two methods, CanExecute(object):bool and Execute(object):void, and you can use command binding on buttons, hyperlinks, and menu items to send data to any ICommand implementation in the form of a CommandParameter.

Once you’ve mastered these three technologies, you’ll likely never want or need code-behind again, and you can achieve complete seperation of presentation and application logic. Then it is on to the real extensibility of WPF, with Dependency Properties, Attached Properties, and Markup Extensions. Dependency Properties allow you to create special properties on your own classes that support data binding. Attached Properties allow you to create special properties on a static class that you can “attach” to any Dependency Object, which means you don’t always have to extend a class just to give it more properties. And in a pinch, when you find there is a little feature missing in WPF, like getting the index of an item in a WPF ItemTemplate, you can use a Markup Extension, which will be replaced by the XAML parser with whatever data is returned by its ProvideValue method at runtime.

Categories: Uncategorized