Adam Kennedy

For a long time now I've been saying to anyone that would listen that the only thing preventing Perl from being a good language for desktop development was a lack of decent library support, and a lack of decent tools to make development relatively efficient.

With Padre, we've certainly gone a long way towards demonstrating that building large desktop applications in Perl is possible, and the stresses caused by Padre on it's underlying libraries has driven the improvement of Perl support for the dominant cross-platform GUI toolkit wxWidgets.

With library support relatively mature, and a number of people working on improving installers for Padre and Perl desktop applications, the next outstanding problem is the complexity of the Wx.pm API and the fairly steep learning curve when it comes to producing Wx.pm GUI and dialog code.

So it with great pride that I present the first working production release of Padre Form Builder, the first native cross platform GUI design solution for Perl.

http://svn.ali.as/cpan/releases/Padre-Plugin-FormBuilder-0.02.tar.gz

The main challenge when writing any GUI design tool is the sheer amount of code you have to write to get to even a minimally useful product.

First you need a deep understanding of the target API. Next you need some kind of meta-model for representing the design, and a file format to encode it. Then you need to hand-roll a GUI application which can do user-interactive on the fly generative layout. And then finally you need to write all the codegen stuff which turns your meta-model into working code.

Padre Form Builder shortcuts most of this by leveraging the popular existing wxFormBuilder tool.

With wxFormBuilder we have a stable, popular and working design tool capable of spitting out fairly decent C, or relatively ordinary Python code with exactly the same line-by-line structure as the C code. What wxFormBuilder does not do, however, is generate Perl code. And even if it did create Perl code, judging by the Python it produces the Perl code wouldn't be particularly amazing either.

In addition, adding Perl support for wxFormBuilder would violate my rule that good development tools for a language should be written in the same language.

So instead I've taken the alternative approach of parsing wxFormBuilder's native XML save file and generating Perl from that instead.

At the base of this Padre Form Builder implementation sits FBP.pm, a parser and object model for the wxFormBuilder file format. This file format is superior to the native Wx XRC format for several reasons, no least because it has support for specifying event bindings for widgets and codegen properties such as whether a particular widget should have a public accessor or be private and inaccessible from outside of the dialog class.

With a working object model for a wxFormBuilder project, the second layer of functionality is provided by FBP::Perl. FBP::Perl provides the core code generation functionality for producing elegant, readable and scalable Perl code for the different types of widgets supported in wxFormBuilder.

Support for wxFormBuilder elements is as close to complete as possible. In addition to the normal widget and layout generation, FBP::Perl support many of the more fiddly bits of GUI development such as custom colours or fonts, tooltips and localisation of GUI elements via Wx::gettext.

And all of the event binding via Perl Wx::Event::EVT_EVENT_NAME calls are supported as well, with stub event methods added to the generated code.

Finally, on top of this code, is Padre::Plugin::FormBuilder itself.

Padre::Plugin::FormBuilder provides a GUI for selecting a wxFormBuilder save file, choosing elements within it to generate, and setting options on the generated code.

In addition, it provides a custom sub-class of FBP::Perl that can generate Padre-specific GUI code so that for one design you can produce either a standalone dialog, or a dialog tailored for use inside of Padre or a Padre plugin.

Right now, the Padre Form Builder plugin is only capable of relatively straight forward functionality, generating a single dialog at a time into a new document and leaving it up to the user to save it over the top of the old version.

In future releases, however, I plan to expand the functionality of the plugin to generate (or regenerate) multiple dialogs at once, or to allow a wxFormBuilder save file to bootstrap an entire working Perl GUI app distribution (similar to our current Module::Starter integration).