Monday, September 26, 2011

Packaging Perl Applications

For some time I've been involved with development for Cava Packager, a tool to package and deploy applications written in Perl.

The project originally grew out of frustration encountered packaging wxPerl based applications where the existing options didn't quite fit my requirement. The project has been through a few incarnations from a purely MS Windows 'free' to use application to a commercially licensed version supporting MS Windows, Linux and Mac OS X.

The latest release has re-adopted the original 'free use' model. Commercial level support is still available separately, but we have separated commercial support from usage and licensing entirely.

Cava Packager does remain closed source and so is 'free beer' without usage restriction.

Monday, August 22, 2011

Citrus Perl - create your own binary distributions

Citrus Perl is a binary distribution of Perl (Currenly 5.12) for Windows, Linux and Mac OS X. The primary aim of the distribution is to provide a standard platform for building and distributing Wx based applications. It also contains builds of several other modules including DBD::Pg, DBD::mysql, DBD::SQlite, TK, GD and GD::Graph.

The latest release (8) allows you to create your own distribution containing any extra modules you have installed.

Citrus Perl attempts to provide one solution to the problem of:

A) A desirable way to distribute a Perl application is to install Perl,
B) It can be quite difficult to get a standard and predictable build of modules such as Wx, GD and DBD::Pg across Windows, Linux and Mac OS X.

The entire distribution is released under the same Artistic License as the distributed Perl with the exception of external libraries and tools ( libmysql, libpq, mingw toolchain etc.) that carry their own licence terms.

Citrus Perl Information and Download

Tuesday, June 28, 2011

Perl5 v Perl6 - again.

It seems that a new bout of Perl5 vs Perl6 is running its course again. I won't add links as the number of blogs, posts, tweets and general opinions has now exceeded the number where I can remember who said what and which bits I agreed with.

Sometimes I am very slow to recognise the obvious - and this is a case in point. The Perl5 vs Perl6 discussion nearly always runs on from or is part of a 'why don't people use Perl' lament. Lots of reasons are put forward, invariably without any real evidence base. That's because, of course, we don't really have the means to gather the evidence. So at best we have to rely on the anecdotal observations of our fellow users of Perl to weight our own opinions. Or maybe we are arrogant enough to be certain that we alone have determined the one true explanation. We all do this sometimes.

So, in this spirit, I'll add my own dash of grist to the mill as the current lament grinds down to the usual unsatisfactory conclusions.

The fact that Perl is not considered for many projects has nothing to do with the features offered by the language or some perceived confusion over Perl5 vs Perl6. Perl has no obvious coherent set of tools for building, testing, deploying and managing your project or application in a reasonable way. Perl being Perl I have no doubt that someone will point me to a selection of modules and approaches that allow this but that, I feel, misses the point. The selection would be the personal choice of a seasoned developer. Knowing how to achieve something is not the same as having a de-facto toolkit.

No-one develops deployable applications in .NET or Java using a text editor and some hand crafted helper scripts.  I'm not sure what the Python folks use and perhaps I should find out. But my general point is that when people discuss the selection of a language for a project, they are really selecting a 'platform' that includes the whole development and maintenance environment.

The thing that I have been slow to recognise is that there has been a project running for quite some time that attempts to start building a modern working environment for Perl. That is Padre. Padre is not just an editor or a graphical debugger, though those two components are essentials. It offers the chance to build a coherent toolkit for managing a project that uses Perl as a language. The future of Perl as a common viable alternative for general application development rests with Padre or son of Padre . Bringing the benefits of modern Perl5 and next generation Perl6 to a wider audience.

Friday, June 24, 2011

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.


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.