New Citrus Perl keeping ahead of the $->MainLoop

I've been putting some effort into improving the user experience when installing and using Citrus Perl and I've taken the opportunity to add a couple of features that may make the distributions more attractive as a platform for application distribution.

The latest releases also come in two flavours with wxWidgets 2.8.12 stable or development wxWidgets 2.9.3. It is probably time for existing users of wxPerl to think about looking how their code works under the development version and also time to take a look at the many new features and controls in the development version.

First time users should probably stick with the stable version for now. There are still one or two issues with 2.9.3 that could leave a new user scratching their head wondering why oh why the code doesn't work like the docs say.

It is a distribution to support GUI development in the main so it has, at last, grown some GUI tools and installation methods.

A Citrus Utilities Application helps you set up ( relocate ) Perl and carry out some platform specific tasks.

Citrus Utilities Management Tab

Citrus Perl also allows you to create new distributions. To make this more obvious and simpler to do, this feature gets a tab in the utilities application too. All the essential stuff is covered like "What shall I call it?" and "Can I have my own splash logo?". As an added bonus it actually works too.

This is, I think, a particularly interesting feature if you wanted to put together a distribution of something like BioPerl and your end users would not be able to successfully put together all the dependencies themselves.

Citrus Utilities Distribution Tab

And finally on the feature front, if you feel that your end users should be able to point and click everything, the utilities app will create dependent executables for you that you can ship and relocate with your custom distribution.

Citrus Utilities Executable Tab

I haven't got around to adding features for creating desktop and application menu icons yet - but the code's open and has a hook already  for a post installation script so you can always write this yourself.

As always, the distributions include Tk to help Tk applications developers with migration of code to wxPerl. It really is time you all did this :-)

The Utilities Application works with a set of modules I've called "CP::Wx" which is showing mild signs of developing into a sort of mini Wx framework.

my $obj = CP::Wx::Widget->new($prnt, style => wxSTYLE_I_WANT);

is something I've been wanting to do for a while.

Full source for everything is included in the distribution so you can stare aghast at the quality of code I'm willing to distribute.

A MinGW for Perl

I have been compiling 32 bit and 64 bit versions of mingw-w64 for use in Citrus Perl and since November 2011 the compiler distribution has been available separately  from Citrus MinGW.

As mingw-w64 does not really have an official binary release I thought it would be useful to have a distribution put together with Perl users in mind.

Included in the distribution is a config file that makes use with ActivePerl simple - just set PERL5OPT=-MConfig_MinGWFP.

The binary distribution is contained in a single archive and includes gfortran in addition to gcc and g++.

In addition to the binaries, there's a full environment for building the compilers from source if you really want to. There are just four 7-zipped files to download and two commands to build the whole thing.

I hope it proves useful.

Regards

Mark

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.

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

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.

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.