Skip to content

Archive

Category: F/OSS

There has been quite a bit of activity on The Linux Experiment over the past little while. Check out the site here or quickly jump to the post that I wrote below.

Big distributions, little RAM 3

How do the ‘big time’ distributions handle on constrained hardware? Take a look.

How to install sun-java6-jdk and Netbeans in Ubuntu 11.10

A simple process to install the official SunOracle Java JDK and Netbeans IDE in the latest Ubuntu.

Ubuntu 11.10′s WiFi crashes my router

The new Ubuntu release is pretty good. Unfortunately it also causes my router to crash.

Gentoo (A.K.A. “Compiling!”)

My first post for the second Linux Experiment where I speak about my Gentoo first impressions.

How to enable reboot/shutdown in KDE on Gentoo

Closed source AMD/ATI drivers, wireless networking and Flash in Gentoo

How to update your (whole) Gentoo system

A trio of small posts that walk new Gentoo users through setting up and doing some basic things in their new desktop.

How to play Red Alert 2 on Linux

I managed to get this classic game to run great on Linux. It even includes a bit of a hack that allows you to play LAN games. I don’t think you can even do that on Windows any more.

Oh Gentoo

My final post of the second Linux Experiment. Includes my conclusions on running Gentoo as a day-to-day desktop system.

In case you somehow found your way here and haven’t already seen them over at The Linux Experiment, I have put up two new posts that deal with fixes for your linux desktop.

Two monitors. Different resolutions. One desktop.

If you’ve ever wondered how to use two monitors with different resolutions as a single, unified, extended desktop I highly suggest you do a quick read of this post. I’ve covered how to avoid, and fix, the ‘dead space’ issue where application windows can get lost because of the difference is vertical resolutions.

Fix PulseAudio loopback delay

For some reason I encountered an issue where the PulseAudio loopback module introduced a delay in my sound, causing audio and video to be out of sync. Here is a simple solution to fix the issue.

 

Hopefully the above two posts can be of use to some of you out there. Let me know if you have any issues getting them to work.

As sort of follow-up-in-spirit to my older post I decided to share a really straight forward way to use Objective-C to build GTK+ applications.

Objective-what?

Objective-C is an improvement to the iconic C programming language that remains backwards compatible while adding many new and interesting features. Chief among these additions is syntax for real objects (and thus object-oriented programming). Popularized by NeXT and eventually Apple, Objective-C is most commonly seen in development for Apple OSX and iOS based platforms. It ships with or without a large standard library (sometimes referred to as the Foundation Kit library) that makes it very easy for developers to quickly create fast and efficient programs. The result is a language that compiles down to binary, requires no virtual machines (just a runtime library), and achieves performance comparable to C and C++.

Marrying Objective-C with GTK+

Normally when writing a GTK+ application the language (or a library) will supply you with bindings that let you create GUIs in a way native to that language. So for instance in C++ you would create GTK+ objects, whereas in C you would create structures or ask functions for pointers back to the objects. Unfortunately while there used to exist a couple of different Objective-C bindings for GTK+, all of them are quite out of date. So instead we are going to rely on the fact that Objective-C is backwards compatible with C to get our program to work.

What you need to start

I’m going to assume that Ubuntu will be our operating system for development. To ensure that we have what we need to compile the programs, just install the following packages:

  1. gnustep-core-devel
  2. libgtk2.0-dev

As you can see from the list above we will be using GNUstep as our Objective-C library of choice.

Setting it all up

In order to make this work we will be creating two Objective-C classes, one that will house our GTK+ window and another that will actually start our program. I’m going to call my GTK+ object MainWindow and create the two necessary files: MainWindow.h and MainWindow.m. Finally I will create a main.m that will start the program and clean it up after it is done.

Let me apologize here for the poor code formatting; apparently WordPress likes to destroy whatever I try and do to make it better. If you want properly indented code please see the download link below.

MainWindow.h

In the MainWindow.h file put the following code:

#import <gtk/gtk.h>
#import <Foundation/NSObject.h>
#import <Foundation/NSString.h>

//A pointer to this object (set on init) so C functions can call
//Objective-C functions
id myMainWindow;

/*
* This class is responsible for initializing the GTK render loop
* as well as setting up the GUI for the user. It also handles all GTK
* callbacks for the winMain GtkWindow.
*/
@interface MainWindow : NSObject
{
//The main GtkWindow
GtkWidget *winMain;
GtkWidget *button;
}

/*
* Constructs the object and initializes GTK and the GUI for the
* application.
*
* *********************************************************************
* Input
* *********************************************************************
* argc (int *):    A pointer to the arg count variable that was passed
*             in at the application start. It will be returned
*            with the count of the modified argv array.
* argv (char *[]):     A pointer to the argument array that was passed in
*            at the application start. It will be returned with
*            the GTK arguments removed.
*
* *********************************************************************
* Returns
* *********************************************************************
* MainWindow (id):    The constructed object or nil
* arc (int *):        The modified input int as described above
* argv (char *[]):    The modified input array modified as described above
*/
-(id)initWithArgCount:(int *)argc andArgVals:(char *[])argv;

/*
* Frees the Gtk widgets that we have control over
*/
-(void)destroyWidget;

/*
* Starts and hands off execution to the GTK main loop
*/
-(void)startGtkMainLoop;

/*
* Example Objective-C function that prints some output
*/
-(void)printSomething;

/*
********************************************************
* C callback functions
********************************************************
*/

/*
* Called when the user closes the window
*/
void on_MainWindow_destroy(GtkObject *object, gpointer user_data);

/*
* Called when the user presses the button
*/
void on_btnPushMe_clicked(GtkObject *object, gpointer user_data);

@end

MainWindow.m

For the class’ actual code file fill it in as show below. This class will create a GTK+ window with a single button and will react to both the user pressing the button, and closing the window.

#import “MainWindow.h”

/*
* For documentation see MainWindow.h
*/

@implementation MainWindow

-(id)initWithArgCount:(int *)argc andArgVals:(char *[])argv
{
//call parent class’ init
if (self = [super init]) {

//setup the window
winMain = gtk_window_new (GTK_WINDOW_TOPLEVEL);

gtk_window_set_title (GTK_WINDOW (winMain), “Hello World”);
gtk_window_set_default_size(GTK_WINDOW(winMain), 230, 150);

//setup the button
button = gtk_button_new_with_label (“Push me!”);

gtk_container_add (GTK_CONTAINER (winMain), button);

//connect the signals
g_signal_connect (winMain, “destroy”, G_CALLBACK (on_MainWindow_destroy), NULL);
g_signal_connect (button, “clicked”, G_CALLBACK (on_btnPushMe_clicked), NULL);

//force show all
gtk_widget_show_all(winMain);
}

//assign C-compatible pointer
myMainWindow = self;

//return pointer to this object
return self;
}

-(void)startGtkMainLoop
{
//start gtk loop
gtk_main();
}

-(void)printSomething{
NSLog(@”Printed from Objective-C’s NSLog function.”);
printf(“Also printed from standard printf function.\n”);
}

-(void)destroyWidget{

myMainWindow = NULL;

if(GTK_IS_WIDGET (button))
{
//clean up the button
gtk_widget_destroy(button);
}

if(GTK_IS_WIDGET (winMain))
{
//clean up the main window
gtk_widget_destroy(winMain);
}
}

-(void)dealloc{
[self destroyWidget];

[super dealloc];
}

void on_MainWindow_destroy(GtkObject *object, gpointer user_data)
{
//exit the main loop
gtk_main_quit();
}

void on_btnPushMe_clicked(GtkObject *object, gpointer user_data)
{
printf(“Button was clicked\n”);

//call Objective-C function from C function using global object pointer
[myMainWindow printSomething];
}

@end

main.m

To finish I will write a main file and function that creates the MainWindow object and eventually cleans it up. Objective-C (1.0) does not support automatic garbage collection so it is important that we don’t forget to clean up after ourselves.

#import “MainWindow.h”
#import <Foundation/NSAutoreleasePool.h>

int main(int argc, char *argv[]) {

//create an AutoreleasePool
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];

//init gtk engine
gtk_init(&argc, &argv);

//set up GUI
MainWindow *mainWindow = [[MainWindow alloc] initWithArgCount:&argc andArgVals:argv];

//begin the GTK loop
[mainWindow startGtkMainLoop];

//free the GUI
[mainWindow release];

//drain the pool
[pool release];

//exit application
return 0;
}

Compiling it all together

Use the following command to compile the program. This will automatically include all .m files in the current directory so be careful when and where you run this.

gcc `pkg-config –cflags –libs gtk+-2.0` -lgnustep-base -fconstant-string-class=NSConstantString -o “./myprogram” $(find . -name ‘*.m’) -I /usr/include/GNUstep/ -L /usr/lib/GNUstep/ -std=c99 -O3

Once complete you will notice a new executable in the directory called myprogram. Start this program and you will see our GTK+ window in action.

If you run it from the command line you can see the output that we coded when the button is pushed.

Wrapping it up

There you have it. We now have a program that is written in Objective-C, using C’s native GTK+ ‘bindings’ for the GUI, that can call both regular C and Objective-C functions and code. In addition, thanks to the porting of both GTK+ and GNUstep to Windows, this same code will also produce a cross-platform application that works on both Mac OSX and Windows.

Source Code Downloads

Source Only Package
File name: objective_c_gtk_source.zip
File hashes: Download Here
File size: 2.4KB
File download: Download Here

These posts were originally featured on The Linux Experiment

One week, three distributions (Day 0)

With the recent releases of Linux Mint Debian Edition, Ubuntu and Kubuntu 10.10 I am once again starting to feel that need to hop around and try something new out. …I’ve set myself up a little experiment of sorts: try each distribution for two days each and on the 7th day choose the best from among the three. Now obviously this isn’t a very fair test, 48 hours is hardly enough to definitely test which of these distributions is truly the best…

One week, three distributions (Day 2: Kubuntu 10.10)

…When I first booted into the desktop I was very pleasantly surprised. I haven’t used KDE since version 4.3 when I had given up on it because, while beautiful and functional, there were just too many rough edges. It seems to be an Internet cliché at this point but I am going to throw it out there anyway: KDE 4.5 is the KDE release you have been waiting for…

Kubuntu 10.10
One week, three distributions (Day 4: Ubuntu 10.10)

…It’s hard to place exactly what makes this theme so nice but Canonical has done a wonderful job iterating the old theme from 10.04 and making some subtle changes that have an incredible overall effect… This level of polish even extends to the new sound menu. Canonical has implemented new sound APIs which allow media players to integrated natively with the sound menu in a way that is just awesome…

Ubuntu 10.10

One week, three distributions (Day 6: Linux Mint Debian Edition)

…I have to say that my first impression of LMDE was a mixed one. On one hand it spewed text everywhere as it booted, which I assume came from its Debian heritage. On the other hand the boot was ridiculously fast… Once at my desktop I was presented with a very familiar Linux Mint set up…

Linux Mint Debian Edition

One week, three distributions (Day 7: Conclusions)

…What makes a great distribution great? This is a very interesting question that I’m sure would generate a wide array of unique and passionate responses. Some prefer ease of use, while others demand nothing less than complete control over what they can tweak. There are people who swear by using nothing but open source solutions, while others are happy to add proprietary code into the mix as well. This is the great thing about Linux, we get so many choices which means we get to decided what we want…

This post was originally featured on The Linux Experiment

Open source software (OSS) is great. It’s powerful, community focused and, lets face it, free. There is not a single day that goes by that I don’t use OSS. Between Firefox, Linux Mint, Thunderbird, Pidgin, Pinta, Deluge, FileZilla and many, many more there is hardly ever an occasion where I find myself in a situation where there isn’t an OSS tool for the job. Unfortunately for all of the benefits that OSS brings me in my daily life I find, in reflection, that I hardly ever do anything to contribute back. What’s worse is that I know I am not alone in this. Many OSS users out there just use the software because it happens to be the best for them. And while there is absolutely nothing wrong with that, many of these individuals could be contributing back. Now obviously I don’t expect everyone, or even half for that matter, to contribute back but I honestly do think that the proportion of people who do contribute back could be much higher.

Why should I?

This is perhaps the easiest to answer. While you don’t have to contribute back, you should if you want to personally make the OSS you love even better.

How to I contribute?

Contributing to a project is incredibly easy. In fact in the vast majority of cases you don’t need to write code, debug software or even do much more than simply use the software in question. What do I mean by this? Well the fact that we here on The Linux Experiment write blog posts praising (or tearing to shreds supplying constructive criticism) to various OSS projects is one form of contributing. Did I lose you? Every time you mention an OSS project you bring attention to it. This attention in turn draws more users/developers to the project and grows it larger. Tell your family, write a blog post, digg stories about OSS or just tell your friends about “this cool new program I found”.

There are many other very easy ways to help out as well. For instance if you notice the program is doing something funky then file a bug. It’s a short process that is usually very painless and quickly brings real world results. I have found that it is also a very therapeutic way to get back at that application that just crashed and lost all of your data. Sometimes you don’t even have to be the one to file it, simply bringing it up in a discussion, such as a forum post, can be enough for others to look into it for you.

Speaking of forum posts, answering new users’ questions about OSS projects can be an excellent way to both spread use of the project and identify problems that new users are facing. The latter could in turn be corrected through subsequent bug or feature requests. Along the same lines, documentation is something that some OSS projects are sorely missing. While it is not the most glamorous job, documentation is key to providing an excellent experience to a first time user. If you know more than one language I can’t think of a single OSS project that couldn’t use your help making translations so that people all over the world can begin to use the software.

For the artists among us there are many OSS projects that could benefit from a complete artwork makeover. As a programmer myself I know all to well the horrors of developer artwork. Creating some awesome graphics, icons, etc. for a project can make a world of difference. Or if you are more interested in user experience and interface design there are many projects that could also benefit from your unique skills. Tools like Glade can even allow individuals to create whole user interfaces without writing a single line of code.

Are you a web developer? Do you like making pretty websites with fancy AJAX fluff? Offer to help the project by designing an attractive website that lures visitors to try the software. You could be the difference between this and this (no offense to the former).

If you’ve been using a particular piece of software for a while, and feel comfortable trying to help others, hop on over to the project’s IRC channel. Help new users troubleshoot their problems and offer suggestions of solutions that have work for you. Just remember: nothing turns off a new user like an angry IRC jerk.

Finally if you are a developer take a look at the software you use on a daily basis. Can you see anything in it that you could help change? Peruse their bug tracker and start picking off the low priority or trivial bugs. These are often issues that get overlooked while the ‘full time’ developers tackle the larger problems. Squashing these small bugs can help to alleviate the 100 paper cuts syndrome many users experience while using some OSS.

Where to start

Depending on how you would like to contribute your starting point could be pretty much anywhere. I would suggest however that you check out your favourite OSS project’s website. Alternatively jump over to an intermediary like OpenHatch that aggregates all of the help postings from a variety of projects. OpenHatch actually has a whole community dedicated to matching people who want to contribute with people who need their help.

I don’t expect anyone, and certainly not myself, to contribute back on a daily basis. I will however personally start by setting a recurring event in my calendar that reminds me to contribute, in some way or another, every week or month. If we all did something similar imagine the rapid improvements we could see in a short time.

Windows?? *GASP!*

Sometimes you just have to compile Windows programs from the comfort of your Linux install. This is a relatively simple process that basically requires you to only install the following (Ubuntu) packages:

To compile 32-bit programs

  • mingw32 (swap out for gcc-mingw32 if you need 64-bit support)
  • mingw32-binutils
  • mingw32-runtime

Additionally for 64-bit programs (*PLEASE SEE NOTE)

  • mingw-w64
  • gcc-mingw32

Once you have those packages you just need to swap out “gcc” in your normal compile commands with either “i586-mingw32msvc-gcc” (for 32-bit) or “amd64-mingw32msvc-gcc” (for 64-bit). So for example if we take the following hello world program in C

#include <stdio.h>
int main(int argc, char** argv)
{
printf(“Hello world!\n”);
return 0;
}

we can compile it to a 32-bit Windows program by using something similar to the following command (assuming the code is contained within a file called main.c)

i586-mingw32msvc-gcc -Wall “main.c” -o “Program.exe”

You can even compile Win32 GUI programs as well. Take the following code as an example

#include <windows.h>
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
{
char *msg = “The message box’s message!”;
MessageBox(NULL, msg, “MsgBox Title”, MB_OK | MB_ICONINFORMATION);

return 0;
}

this time I’ll compile it into a 64-bit Windows application using

amd64-mingw32msvc-gcc -Wall -mwindows “main.c” -o “Program.exe”

You can even test to make sure it worked properly by running the program through wine like

wine Program.exe

You might need to install some extra packages to get Wine to run 64-bit applications but in general this will work.

That’s pretty much it. You might have a couple of other issues (like linking against Windows libraries instead of the Linux ones) but overall this is a very simple drop-in replacement for your regular gcc command.

*NOTE: There is currently a problem with the Lucid packages for the 64-bit compilers. As a work around you can get the packages from this PPA instead.

After reading up on how you can use SWT to give Java a more native look and feel I was interested in giving it a shot first hand. I decided to break out old faithful (Hash Verifier) and re-write it completely in Java/SWT. The end result was an application that has essentially equivalent functionality (see below for differences) but is completely cross-platform. No matter what operating system you end up running this on (Windows, Mac OSX, Linux) it should have a native look and feel. I will explain how I accomplished this literal “write once, run anywhere” code below.

Easy deployment

The download consists of three different programs. The first, and main, named HashVerifier.jar is not actually the Hash Verifier program, but rather a simple sequential application launching system that I wrote to make cross-platform deployment even easier. When you run HashVerifier.jar, either by double-clicking on it or by running it from the terminal with java -jar HashVerifier.jar, it opens up the included rules file and begins to execute the lines one after another. If there is a special platform specific file (such as rules.mac) it will run that instead. Let’s take a look at rules:

java -jar AdaptiveSWT swt.jar
java -XX:+AggressiveOpts -XX:+UseParallelGC -jar HashVerifierApp

As you can see each line is a separate command to be run.

Getting that right look

When HashVerifier.jar starts it reads each line and runs that as a shell command. The line java -jar AdaptiveSWT swt.jar starts the second included program. AdaptiveSWT uses Java’s built in cross-platform UI toolkit, Swing, and displays a small dialog while it downloads the platform’s native SWT library. This is necessary because otherwise I would need to create separate downloads for each platform, each with their unique native SWT library. By using AdaptiveSWT I can instead let it handle all of the dirty work for me. This is really the trick that lets me release exactly one version of the program that looks correct for everyone. The AdaptiveSWT program is even smart enough to know not to re-download the library if you already have it. That being said if you ever do have an issue where you need to re-download the library either delete the swt.jar file in the program directory or change the first line to java -jar AdaptiveSWT -force swt.jar. This forces the download to happen regardless of it you already have it or not.

Hash Verifier

The next line logically starts the actual Hash Verifier application (with a couple of extra performance enhancing flags passed along as well). This version should work almost identically as the previous with a few key differences:

  • I have removed the Export to Hash File menu option as I simply just didn’t use it enough to warrant me spending the time to re-develop it.
  • I have removed the old Help menu option and replaced it with a visit website option.
  • RIPEMD-160 has been replaced with MD2, mostly because that is what the JVM supports “out-of-the-box”.

That’s about it. Please let me know if you have any issues running it on your platform of choice.

Requirements

  • OS: Windows, Mac OSX or Linux (Gtk+)
  • Internet connection
  • Java JRE (targeted at JavaSE-1.6 but might work on the previous version as well)

As before the binary only package contains just the executables, whereas the all package contains the source code as well.

Binary Only Package All Package
File name: hash_verifier_0_3_0_0_binary.zip hash_verifier_0_3_0_0_all.zip
File hashes: Download Here
GPG signature: Download Here Download Here
Screenshots:
License: (LGPL) View Here
Version: 0.3.0.0
File size: 68.6KB 107.1KB
File download: Download Here Download Here

NOTE: This software was tested on Windows Vista, Mac OS 10.6 and Linux Mint 9. While it may (and should) run on similar platforms I have not been able to test this. Please remember that this software is provided “as is” and without any sort of warranty. Use at your own risk.

After a little bit of pressure from the people responding to my previous post (My search for the best KDE Linux distribution), I have finally given in and tried out Chakra. The Chakra Project starts with Arch Linux as a base but, instead of forcing you to build your own distro piece of piece, Chakra comes more or less pre-packaged.

Installation

The installation was one of the best I’ve ever seen. For alpha software this distribution’s first point of interaction is already very polished – even warning me that it is not stable software and might therefore eat my hamster.

The install process even let me decide to install some very useful packages, like Microsoft Core TTF Fonts and Adobe Flash, right away. Even the Language & Time step was incredible, offering a rotating globe that I could drag around and manipulate.

The only issue I had was trying to create a disk partition to install the OS to. This was because I was trying this out inside of VirtualBox, and the virtual hard disk did not have any partitions on it whatsoever. There is a bug and (thankfully) work-around for this known issue with their Tribe installer, and after reading a quick walk-through I was once again ready to install.

The Desktop

The desktop is standard KDE version 4.4.2 after install. Opening up Pacman (or is it Shaman?) showed me a list of brand new software that I could install, including the newest KDE 4.5. One of Project Chakra’s great strengths will be in this rolling release of new software updates. The concept of installing once and always having the most up-to-date applications is very intriguing.

Unfortunately, as with most alpha software, Shaman is still pretty buggy and often crashed whenever I tried to apply the updates. Also unfortunate is that Shaman started a trend of applications simply crashing for no reason. I don’t want to give this distribution a bad reputation, because it is still pre-release software, but I think it goes without saying that the developers have some bug squashing to do before a stable release will be ready. Something I found rather strange is that the current default software selection that Chakra ships with includes two different browsers, Konqueror and rekonq, but no office software whatsoever.

Google Chrome much?

Final Thoughts (for now!)

The Chakra Project looks very promising, albeit very unpolished at the moment. If they can manage to fix up the rest of the distribution, getting it just as polished feeling as the installer, this will definitely be one to look out for. I look forward to trying it out again once it hits a stable release.

It’s no secret that while Java possess probably the most widely distributed, cross-platform, and common user interface libraries, graphical Java applications on the whole simply stand out for the wrong reasons. Whether the GUI comes in the form of the Abstract Window Toolkit (AWT) or Swing, each can be far from pretty and often do not mesh well with the platform they are being run on. For instance, running an AWT or Swing application can be an almost alien experience, no matter what operating system you are using, because neither uses the native control widgets. Even AWT, being a ‘thin’ layer above the native controls, often looks completely bizarre. On Windows Vista AWT looks more like Windows 3.1 than anything else. Thankfully there is a nice alternative in the IBM created (and now Eclipse maintained) SWT.

The Standard Widget Toolkit, or SWT, passes all GUI rendering responsibilities onto the host operating system. This allows for some interesting advantages like hardware rendered drawing for free (as an example). It also provides for a native look and feel because its actually using the real native widgets. So when run on Windows it looks like a regular Windows application and when run on Linux it looks like a Linux (GTK+) application. It also works on the Mac as well as a few other obscure platforms.

Unfortunately because the application is now creating widgets outside of the JVM you are suddenly responsible for freeing the memory. There is no automatic garbage collection in the world of SWT. It’s not all bad however as freeing a parent object, like a window (referred to as a shell in SWT lingo), automatically frees all of its related child objects as well. Simply call the .dispose() method and 9 times out of 10 you are done.

Another other caveat is that you will still need to package the correct swt.jar file for your target platform. For instance Windows has its own version of swt.jar, as does Linux, and Mac, and so on and so forth. While this is rather annoying it does offer some interesting trade-offs. For instance you do not need to recompile your code just because you want to run it on a different platform; simply swap out the swt.jar file and watch as the exact same code generates completely different native GUIs. I even wrote a simple program that first checks what platform it is being run on and then downloads the correct swt.jar file before launching the GUI. This makes releasing the exact same package very simple.

So how do you start using SWT? Head over to http://www.eclipse.org/swt/ and download the newest stable version for your platform of choice. Depending on how you will be programing, all you have to then do is add the enclosed swt.jar to your class path. If you’re using Eclipse, or a similar IDE, you can simply add the source as either part of you project, or as a separate referenced one, and take full advantage of the auto-complete as well. Perhaps I’ll get around to posting a more thorough how-to guide at some point in the future.

Like most things in software SWT is not perfect. There are still other challenges to overcome, such as creating each individual platforms’ unique user experience to compliment their native GUI toolkits. That said if you’re looking for a way to leverage the widespread nature of Java, while still creating an application that looks like it belongs, SWT might just be what you’re looking for.

Recently I have been messing around with the Glade interface designer, a rapid application development tool that allows you to create full GTK+ user interfaces very easily. The neat thing about this tool is that it saves the GUI as an XML document, which is then hooked into your code through various language specific ‘sketchers’. These sketchers read in the XML and generate the corresponding ‘native’ code interfaces – often at runtime. There seems to be a big push toward these types of XML-based user interface solutions, Microsoft is pushing XMAL through its Windows Presentation Foundation technology as just one example, and it got me thinking: is this really the best way to go?

Pros

XML offers a number of unique and interesting benefits when compared to the classic programmatic style of user interface creation. For one it represents a true separation of the “view” from the logic of the application. This is incredibly important to a long-term modular design. In addition, by storing the user interface in a file external to the application itself, it allows for complete GUI changes just by updating the single XML file – you don’t even need to recompile the code! This is a huge benefit when testing how users interact with various interface designs or changes and makes A-B testing a snap. Similarly if you want to have various custom front-ends to the same application, say a basic user interface as well as an administrator interface, you can simply distribute your application with two different GUI files. Finally, and most importantly, XML is completely language independent. Thinking about changing your application code base from C to Python? No need to re-write your GUI. This in turn leads to better GUI-specific development tools (like Glade) that aren’t constrained by any language’s particular quirks. The flexibility of XML is where this approach really shines.

Cons

Depending on how it is used XML can have not only a performance impact but also a security one as well. Both of these are especially prevalent when using external GUI files. For instance, a program that loads the GUI from an external file must first read and parse said file every single time the application starts. This is an operation that would otherwise have been avoided by using a pre-compiled programmatic GUI. Next while the ability to completely swap out the GUI without re-compiling the code is pretty cool it can also lead to some… unintended consequences. Take this bit of Glade XML as an example:

<widget id=”myWindow”>
<signal name=”destroy” handler=”on_myWindow_destroy”/>
<widget id=”myWindow”>
This snippet of GUI XML tells the sketcher to create a a widget called “myWindow” which emits a “destroy” signal that should be handled by a function called “on_myWindow_destroy”. All seems fine… until some mischievous individual goes and changes either the signal or the handler (or both!). Now your debugged and polished program is doing things you absolutely did not expect. I will however take this moment to point out that at least in the case of GtkBuilder (a sketcher that you can use with Glade) you do not always have to load the XML from an external file. Instead you could embed the XML string inside your program if you don’t want people messing around with it.

Conclusion

While there are some definite trade-offs to using XML I kind of like the direction it’s taking overall application design. So long as you adhere to safe programming techniques I see no real disadvantage with using XML as a definition language for your application’s intricate GUI. Just be sure to validate the XML, at the very least, before allowing your application to run with it. There’s a reason why god invented digital signatures ;)