November 2005


I’m having some trouble getting the code section of this post right.  Transmissions will be resumed as soon as possible…

– eikogo

I am a “furniture making” programmer, not a “house building” programmer or a “landscaping” programmer, nor a “telephone company infrastructure designer” programmer. This means that I make small programs and make them really well. My programs are analogous to furniture in that each one is small, particularly functioned, and lovingly hand crafted using best practices, accurate design analysis, and a vigorous end-user testing and involvement cycle. I don’t want to build homes, infrastructures, or buildings. But if you need a custom designed couch or kitchen table, I’m your guy.

Python is a very feature rich scripting language that can be used to solve a variety of programming needs, from OS level scripting, to XML transformation, to Client/Server applications. Such scalability makes it an excellent tool for developing applications, particularly those that fit into my “furniture builder” metaphor.

However, the main interface to Python, in its base installation, is console based. While this is OK for us programmers, it’s just plain unacceptable to present an end-user with a console window these days. A GUI must accompany the program if there is to be any customer interaction with the application at all.

There are currently two major GUI development platforms for Python (and a few other languages, including Perl and Ruby). These are TCL and wxPython. These tool kits are quite broad spectrumed, and provide the capability to build very complex GUI’s. However, such low level tools, while necessarily giving greater control and power over the interface, require quite an investment in learning how to use them well. I did find that using PythonCard with wxPython did help substantially in making an application GUI, however, I was left looking for something more. My fear was that I would have to surrender Python in favor of a more complex toolset, perhaps even resigning myself to the Microsoft .Net tools of ASP.NET, VB.NET, or C#.NET. If you love Python like I do, then you can probably imaging the distate I felt in contemplating that decision.

However, whilst reading through some del.icio.us links, I came across the concept of HTA’s. These are HTML applications and are an implemented technology from Microsoft. I have read where the technology is cross-platform to Mac OS X and Linux even, though I have yet to test this and seriously doubt it.

An HTA application runs in an Internet Explorer “window” but does not run over the network. All application code is execute on the client machine. There is no URL bar in the window, nor statusbar, menubar, toolbar, or any other control. Your basic HTA application is just a bare window, ready for you to add controls to.

You can design your GUI by using plain HTML statically, or write code that will dynamically present the GUI. The ability to place labels, text boxes, combo boxes, checkboxes, and more allows quite complex GUI’s to be created simply. Any design that can be created to run in a browser can be designed to work in an HTA.

Ahhh, you ask, but what about the programming languages? Its very astute of you to notice! The usual suspects can be used to develop applications, including VBScript, JScript, or JavaScript in a block. By virtue of running entirely on the client computer, Microsoft has relaxed the security restrictions of a regular browser, giving script code access to the file system, Windows API, WMI, and more. This allows the HTA application to do accomplish powerful tasks that cannot be done via a normal IE browser client/server session.

Python comes into play when it is installed into the Windows environment as a scripting language. The default choices of VBScript, JScript, and JavaScript do not have to be the only scripting languages for Windows. A quick install of ActiveState’s ActivePython will setup Python as a scripting platform for Windows as well. By the way, ActiveState’s ActivePerl will do the same for Perl, setting it up as a scripting platform as well. This means that you can use Python (or Perl even) in a script block for your HTA application just as you could VBScript or JavaScript.

Now that’s power! Python power wrapped up in a GUI platform that works wonderfully under Windows. I will be verifying the cross platform claims made of HTA applications shortly. My home computer is a dual boot Windows XP/Ubuntu 5.10 system so at least the Linux claim can be verified. I’ll coordinate with someone to verify the Mac OS X compatibility too.

In the meantime, look for more articles, ranging from introductory to complex, on how to use these two technologies to create well designed applications that meet customer needs.

– eikogo