wxPerl Binary Oasis

wxWidgets 2.9.3 - Binary Oasis

2012-03-17T04:41:16Z

Wx 0.9905 has been released to the CPAN and includes working bindings for a few new controls in wxWidgets 2.9.3. You will also need Alien::wxWidgets 0.56 or above as prior versions didn't know about the new control libraries.

My favourite is Wx::PropertyGrid which provides a family of controls designed for the edit and display of settings. Many of the controls have built-in custom editors although you can assign editors of your own.

Wx::Ribbon provides a fully customisable modern ribbon bar control.

Reasonably complete conversions of the wxWidgets sample code for each module are included in the latest Wx::Demo 0.15 release.

wxWidgets 2.9.3 also contains a built in implementation of Wx::TreeListCtrl. This is somewhat different to the separate CPAN module which cannot be used with wxWidgets 2.9.3.

The other common binary modules, Wx::GLCanvas on all platforms and Wx::ActiveX on Windows build without problems.

It is worth pointing out that wxWidgets 2.9.3 is still regarded as a development version so you are more likely to come across problems. This is particularly true of the MacOSX port which is really a major rewrite since 2.8.12.

Linux and MacOSX users - you should have no problem building from CPAN. Or, at least no more problems than you might encounter with wxWidgets 2.8.12. Windows users will have more or less luck depending on their Perl. If you are a Strawberry Perl user you will have to wait for the next Strawberry release I'm afraid. ActivePerl users should have no difficulty with recent versions of MSVC. There is also my MinGW distribution from MinGW GCC For Perl which will work well with ActivePerl. CitrusPerl users can expect a new release within the next few days.

Perl 5.14 Support - Binary Oasis

2011-05-19T10:42:33Z

PPMs for Perl 5.14 have been added to the repository for:

MS Windows x86

Linux x86

Linux x86_64

ActivePerl 5.14 for Mac OS X is now an Intel only i386 / x86_64 universal binary which runs as a 64 bit Perl on supporting machines. wxWidgets 2.8.12 cannot be built for x86_64 architecture (it uses carbon which is 32 bit only). It ought to be possible to build an i386 only wxPerl + wxWidgets against ActivePerl 5.14 and make the special wxPerl binary run as 32 bit i386 only. We have not managed it yet so no PPMs are available for Perl 5.14 on Mac OS X.

PPMs Updated - Wx 0.99 / wxWidgets 2.8.12 - Binary Oasis

2011-05-09T13:04:47Z

The PPMs for ActivePerl at the wxPerl repository have been updated to the latest versions of Wx and wxWidgets stable.

Wx 0.99
wxWidgets 2.8.12

On Mac OS X, the PPM provided Wx still requires that you use the 'wxperl' launch executable. This is because the binary components of the PPM dists have paths encoded that work when packaged using PDK (and Wx::Perl::Packager) as well as when run with 'wxperl'. There are better way to accommodate this but I have not implemented one yet.

Cava Packager - Binary Oasis

2010-12-20T08:33:07Z

Cava Packager, our Perl packaging application, has reached Version 2.0 and added support for Linux and MacOSX platforms to go alongside the existing Windows version.

It is a cross-platform wxPerl application.

Cava Packager

Latest Wx 0.98 - Binary Oasis

2010-09-09T07:58:19Z

Catching up after summer here in the north, I have updated all Wx PPMs to version 0.98 plus amendments for Wx::SetCursor and Wx::Window::Navigate from SVN.

The way the PPMs are built for MacOSX means that you must still use 'wxperl' to run your scripts when using the PPM based Wx installation. Hopefully the MacOSX PPM installation will support using standard 'perl' command line (as a CPAN installation does from version 0.98) in the near future.

Perl 5.12 Arrives - Binary Oasis

2010-04-14T07:07:17Z

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 - Binary Oasis

2010-04-06T18:20:00Z

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 - Binary Oasis

2010-03-26T19:30:57Z

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 - Binary Oasis

2010-02-03T15:41:07Z

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