Wallasey Does Perl GUI Development

It is my first blog post here and I should give a little information about myself. I have a commercial connection to Cava Packager, a tool for packaging and distributing Perl applications. I chip in with some contributions to Mattia Barbon's wxPerl. I am involved with the maintenance of Citrus Perl, a binary distribution of Perl intended for GUI application development. I also maintain a PPM repository for wxPerl related modules for the ActivePerl user community at wxPerl PPMs. I occasionally lurk on IRC channels as 'wallasey'.

Given all of the above you might be surprised to learn that I don't actually like GUI programming. I've worked on projects with a GUI element involved but near the top of my design goals list was always a proper separation of any GUI elements. Apart from being practically useful and beneficial this also meant I could hand off GUI development to a separate team or individual with more talent and enthusiasm in that area. A win win situation.

Personally I find GUI design and development hugely unrewarding. The level of effort required to translate a requirement to working code seems totally disproportionate to me. I know what I want, the end user knows what they want, and I'm happy that the two things are roughly the same.  It always seems to me that translating that into code takes an inordinate amount of time which could be better spent doing interesting things with the 'real' application work.

This view is however, tempered by experience. There are great GUI designers and developers who actually enjoy translating complex interactions into simple and enjoyable end user experiences. Take the example of a command line utility with say 20 different possible options, with each option taking several possible values. You might call it as:

mycommand --opt1=a --opt2=b --opt3=25 --opt4=g --opt5=k 

That seems totally reasonable to me. If it is useful I don't mind learning all the options. It seems the natural thing to do. However, this possibly represents a huge amount of wasted effort on the part of all the users of mycommand. If you asked a room of developers to each provide a GUI for mycommand, you would get a large number of implementations which just gave you option choices to select. Probably from me too. The important thing is what mycommand actually does, and the GUI is just eye candy, right?

Well, no. I'd contend this can be very wrong. A GUI backed by great design removes the need for the user to understand the implementation. It asks the user what they want to do, not how they want to interact with the underlying implementation. Great GUI design does happen and when it does it translates complex operations into simple end user interactions.

I would say that often, the people who understand how to implement systems to handle the complex operations robustly are not the people who can create and implement great GUI designs. GUI development in Perl has the flavour of a niche in a niche. Almost a minor interest hobby for Perl developers.

Why?

Ask about tools for cross platform GUI development and generally you'll get back 'Java with Eclipse'. You may get a mention of QT and perhaps wxWidgets for C++. From the end user perspective - that is the user experience of applications built using these tool - I don't think there's a great deal of difference. wxWidgets looks most native to me. Java looks 'Java' - to me at least, but maybe I'm looking for it.

Mattia Barbon's wxPerl is a great technical implementation of a Perl wrapper for wxWidgets. I always consider the design approach really smart. The API presented to the Perl user follows the C++ API as closely as possible. This provides you with two main advantages. The minimum abstraction from the underlying wxWidgets API makes maintenance viable for an open source project maintained largely by 1 person. The C++ API documentation is directly usable as documentation for the Perl API. I also find some of the internal implementation of wxPerl quite spectacularly clever.  It is quite simply, awesome.

So Perl, the most cross platform of cross platform languages has a great GUI toolkit at its disposal but it gets little use in GUI development. There may be great GUI designers who also use Perl but there seems to be very few who engage in both activities at the same time.

Consider Padre, probably the most widely known wxPerl application. From following the Padre mailing list and occasional visits to the Padre IRC channel, I think the difficulties experienced by the active Padre developers who are both talented and skilled expose some fundamental problems creating a GUI in Perl.

It is always dangerous and to assume you understand someone's opinion and experiences  from a few comments on mailing lists and IRC. However, I get the impression that the general feeling within the main contributors to Padre is that they want to get on and do great things but are hampered because the  level of effort required to translate a GUI requirement into working GUI code seems totally disproportionate.

And that is, I would say, the core of the problem regarding GUI development in Perl. It doesn't attract many people whose primary interest is GUI design and development. It just attracts people whose primary interest is Perl. Like myself, these users see the benefit and flexibility of

mycommand --opt1=a --opt2=b --opt3=25 --opt4=g --opt5=k 


Once you are fully conversant with mycommand's options, and how they all work together there seems no motivation to work on a GUI to replace mycommand ? And for your own usage, there isn't. But if you have a notion of making the power of Perl available generally to GUI designers and developers, you need tools that abstract the underlying implementation almost completely.

wxPerl needs a decent application design environment to abstract its own 'mycommand' syntax. One that requires no knowledge of Perl to create your first 'Hello World' application. The basic options available to you when starting the GUI elements of your design should be available on a 'do what I want' basis. Select your application options - say threaded / none threaded, your help editor, and the platforms you want to target  - design your first form by drawing it. Select it as your 'startup' form - and run.

It won't do much as you need to write event handlers in Perl - so at that point you can feel smug with yourself followed by reading the 'Application Basics' and 'Event Handler' tutorial in the manual - possibly via some Perl manuals if it is your first experience of the language.

Of course, this means being prescriptive about a great many things in the overall application design. But you need that to give new users the helping lift they need when first starting.

Perhaps those who have spent months or even years reinventing the wheel with our own wxPerl applications should consider how we can put the power of a wxPerl GUI in the hands of those who currently would not consider it. Take the hard won lessons from Padre, mix them with a bit of experience from elsewhere to produce the first Wx application design tool in Perl. Then developers who are better at that sort of thing can jump in and start improving it. Perhaps if we build it they will come.

It'll mean I have some chance of handing off my GUI design and development to someone else and we can both get on with doing the sort of work we enjoy most.