Recently in Perl Category

Perl 5.12 Arrives

| 0 Comments
Perl 5.12 has arrived and so have wxPerl PPMs for this latest version of Perl. The repository now supports Wx PPMs for:

Windows:
Perl 5.12 32 bit
Perl 5.10 32 bit
Perl 5.8  32 bit
Perl 5.12 64 bit
Perl 5.10 64 bit

Linux:
Perl 5.12 32 bit
Perl 5.10 32 bit
Perl 5.8  32 bit
Perl 5.12 64 bit
Perl 5.10 64 bit

MacOSX
Perl 5.12 universal
Perl 5.10 universal
Perl 5.8  universal

I had been thinking about dropping builds for Perl 5.8 but a review of the download logs show that it is still by far the most popular platform for Wx PPM users.

Wx Spell Checker

| 0 Comments
Following on from work enabling native spell checking on MacOSX, I've been searching for a spell checking engine or method for Wx on Windows. There are a few CPAN modules available but I kept coming back to Text::Aspell.

Aspell is pretty much universally available on Linux distributions and seems to be easily built on the Mac. It has a widely usable license in LGPL 2.1 so might provide the  solution I need. Windows support is different though with the last 'recognised' Windows port dating back to December 2002. If I could build the current stable Aspell on Windows it would give me solutions to my spell checking requirements on all platforms. Mailing lists and support forums suggested there are quite a few source changes needed to compile natively on Windows. (assuming you don't count Cygwin / MSYS as native).

I took a look again at the forked gcc compiler for windows, mingw-w64. I've used this to provide 64bit PPMs of Perl modules building natively on a Windows x64 machine. This compiler also provides cross compilers for Linux hosts targeting both 64 and 32 bit Windows binaries.

Installing the mingw-w64 cross compilers on Linux was as simple as the Windows versions. Just extract the tar-ball to a directory and add the contained bin directory to your path. I initially had some difficulty as my standard Linux build environment is CentOS 5 (a RHEL5 'equivalent'). This comes with some static versions of libraries that prevent (or at least prevented me) using the cross compilers. Switching to a different distribution solved these problems (I used Debian).

Once I had a usable Linux distribution, there were just minor changes needed to the source. As with most Linux builds, the install location is hard coded in the binaries by the Aspell build process. This is not practically usable in a Windows environment so some code is added to locate the binaries at runtime. There was just a single #include that needed to be added in the rest of the source code to get a working build of Aspell for both 32 and 64 bit Windows. 

I've made these Aspell builds available as part of the Text::Aspell PPM module available in the repository. You can also get a standalone install plus patches, source and build scripts from the Aspell Page.

The last thing to do was enabling builds of Aspell dictionaries. Normally this is done via './configure' on Linux platforms but there is really no need for any compiler to be present to carry out the installation.  I created an install script to parse the dictionary bundles and run the necessary install commands, then packaged this as an executable for my binary distribution.

That, I think, is my spell checking requirements taken care of. I can offer a common solution across all platforms and then perhaps add in support for switching to 'native' solutions if available and required. 

Learning to use wxOSX

| 0 Comments
I've been putting the necessary things in place to make one of my wxPerl applications more Mac friendly. The first thing I discovered was the availability of automatic spell checker access for Wx::TextCtrl. By default, this is not switched on but you can switch on and off globally in your application with:

Wx::SystemOptions::SetOptionInt("mac.textcontrol-use-spell-checker", $bool);

You can also control individual Wx::TextCtrl instances by

$textctrl->MacCheckSpelling($bool);

Now all I need is spell checking for wxGTK and wxMSW.

I also sorted out the application menu, which had been irritating me. A full explanation is at the wxWidgets wiki but in short:

$app->->SetExitOnFrameDelete(0);

prevents your application closing when all top level windows are closed. Use the identifiers; wxID_ABOUT, wxID_EXIT, wxID_PREFERENCES for the appropriate Wx::MenuItem id's and name your 'Help' menu 'Help'. You can add a Wx::MenuBar with these items in to your application with:

Wx::MenuBar::MacSetCommonMenuBar( $mymenubar );

and this menubar will be used when no top level windows are open. Unfortunately, MacSetCommonMenuBar is not wrapped in the current Wx CPAN release (0.9701) but it is in SVN so should make the next release.

In The Beginning

| 0 Comments

In the beginning, I decided it would be a nice idea to provide wxPerl PPMs for Linux along with the MSWin32 binaries that have exisited for quite a while. I have been deploying some wxPerl applications to Linux users and thought it was time to clean up the necessary hacks and release PPMs. Of course, if you are building Wx yourself on your local Perl, then there is no problem. A CPAN install of Wx should work just fine.  But in my case, I wanted to deploy wxPerl applications to different machines over which I had no control - and be sure that they'd work as intented for users who knew nothing about Perl. So a local Perl install wasn't really an option.

Whilst I was doing this, why not get a Mac OSX PPM together, I thought, for the 'full set'. That's 'full set' apart from the multitude of other systems that Perl runs on.

Making a choice about which versions of what to support turned out to not be too difficult. First choice was ActivePerl as a base to build the binaries against. One of the difficulties in building a binary for Linux (and I guess Mac OSX) is your dependence on installed libraries and their respective versions. This isn't an issue if you build for Linux in the normal way targetting a specific distribution, or build locally on the target machine. But for a distributed PPM it is an issue. The ActivePerl distribution and the ActiveState PPM repository provide binaries that are built against a fixed set of dependencies - so all the work was already done for me regarding the dependecies of any modules Wx might reference - I just had to worry about the specific dependencies of wxWidgets. It also solves the same problem for any user who might want to distribute a wxPerl application using PerlApp or PAR. There's a fixed set of dependencies and therefore a fixed minimum version of the target operating system or distribution that you want to deploy to.

For my own purposes, I need the facilities provided by wxGraphicsContext, which fixes the minimum versions of some major dependencies on Linux. For GTK builds I need a gtk built against the cairo graphics library, so I get a minumum gtk version of 2.8. I also wanted to build on one of the standard distributions - preferably one of the 'enterprise' types which does not bundle the latest packages with every release. I ended up using CentOS 5 - which gave me the base dependencies of glibc 2.5 and gtk 2.10. Checking on distrowatch, most major distributions use these and upwards from around 2007. The one 'latecomer' was Debian for which 5.0 / Lenny is required. Even 2007 seemed a bit recent to me so the decision was 'should I provide PPMs that I can't and don't use myself?'. So you've got glibc 2.5 and gtk 2.10 as base dependencies on Linux.

On Mac OSX I wanted universal binaries so building to support 10.4 Tiger and upwards was the only choice. I have an Intel Mac with Snow Leopard installed, which turned out to be a pain to build on for a newcomer like myself. Still, all the answers were on the wxWidgets wiki so reading the manual could have saved me considerable grief here. Also, since the current release of ActivePerl pre-dates Snow Leopard, there were some problems building support modules such as OpenGL - but the solution was quick - armed with my new knowledge gained by 'reading the manual' for wxWidgets. (see Building under Snow Leopard).

So, now the PPMs are built and available, I hope they encourage even wider use of the brilliant wxPerl.

Links:
wxPerl Homepage
wxWidgets Homepage
ActivePerl

About this Archive

This page is an archive of recent entries in the Perl category.

wxOSX is the next category.

Find recent content on the main index or look in the archives to find all content.

Categories