This is a critical ability for any freelance Perl developer, since it compliments a Perl journeyman's ability to do many things on servers, such as create remote services. Being able to transfer these skills to the desktop environment, particularly one that is full of users who are okay with paying for software (i.e., Windows). In short, Perl programmers who want to make a living on their own need to know how to create and distribute Windows GUI applications; this page covers a large piece of how to do that.
wxPerl GUI running on Windows as a double-clicable EXE file! Created using RAD-ish tool, wxGlade. See more images on Github.
Instructions are provided with the versions detailed below. If there are newer versions of any of the modules, you may try it out (of course); but understand they have not been tried out and shown to work like version combinations below.
wxGlade is a GUI builder for wxWidgets applications. It is written in Python, but critically supports outputing Perl code. It is actively developed, the developer is very responsive on Github to bugs and feature requests. It is the closest thing we have in Perl to a RAD (rapid application development) environment (e.g., Lazarus for FreePascal).
Last tested on 25 Jan 2025, although later versions of Python 3 were tested (specifically, 3.12.8), wxPython would install but not run wxGlade properly
install as admin (checkbox should be already checked; also opt'd to add "python" to the PATH)
Note: if this fails, you may need to reinstall pip; but it should be available in the CMD window. Based on experience, pip doesn't seem to be available via the Strawberry Perl terminal, so be sure to get a standard Windows CMD window to do this part.
This section outlines some different workflows that are found among members of the community who use wxPerl. Like any workflow, the based on level of experience and particular application.
Example layout with Strawberry Perl for running the application and Makefile, vim under MSYS2 for more streamlined workflow. wxGlade is under there, too; when there is a change to the GUI, the project is saved and code generated using "ctrl-g". vim is used to edit the code and will update whenever wxGlade updates it, if you do it right your custom code won't get clobbered.
The best way to recreate the "edit-run-fix" workflow of code editing enjoyed by vim users is to install MSYS2 and use its terminal to install both vim and git:
pacman -S vim git
Note: you do not want to run the Perl code generated by wxGlade inside of the MSYS2 terminal. When you install git, it will install its own perl and clobber Strawberry Perl in your PATH. Run the Perl code for your project from a Strawberry Perl terminal.
Just like the editor options in Windows is not ideal, neither are the Git options (GH's "Git for Windows" is exceptionally awkward to use, not sure how to it is possible to be good in "Windows" tbh; YMMV.) Under MSYS2's terminal, you may install git and use it as you may be accustomed on Linux. You may want to generate an ssh-key, which will be vailable in `~/.ssh/` by default. So you can do all the normal git workflow stuff from there once your key is created and added to your Github keyset.
Pro Tip: Turn Off MSYS2's vim Mouse Support[edit | edit source]
I have found that this is required to "copy" text from the MSYS2 vim, you may not need it. But by default vim is aware of the mouse.
To turn it off, issue the command,
<ESC>set mouse=<ENTER>
Using wxGlade's "Single file" + "Keep use code" Options[edit | edit source]
wxGlade has some settings that tells it to not overwrite changes you made in the output Perl script, but beware - this option is not on by default. That means that means that your file will get overwritten if you tell wxGlade to generated new code again. The general workflow is as follows:
start a new project (or open an existing one)
click on the root "Application" object in the object viewer
find the output pane, set the output to be "Perl"
set version of wxWidgets to be "3.0"
Recommended settings for using wxGlade for Perl development.check "Keep user code", this will make sure wxGlade doesn't over write code that is outside the bounds of very clearly marked blocks in the code
Using wxGlade's "Seperate file for each class" Option[edit | edit source]
This section is more of a work in progress since a reliable method of distributing single file executables (or developing installation packages for Windows) is still an open question, there is hope that this will end up being a relatively smooth process. Needless to say, it is critical for Perl developer to be able to distribute Perl based GUI applications as single file (.exe) or via installation on Windows. The client should NOT need to be running through any of the instructions above to run a program that you would like to sell them for actual money.
Below are the initial instructions for generating an EXE file. There are also many ways that wxPerl developers go about doing, based on their use case and experience.
PAR::Package, App::PP::Autolink, and WX::Perl::Packager[edit | edit source]
Note: pp_autolink, provided by App::PP::Autolink has proven to be absolutely critical to finding the required DLLs that need to be added manually to the wxpar command below via the --link flag.
Assuming you have a Perl script generated either via wxGlade (see above) or one you have created/updated by hand, the command is as follows:
C:\> wxpar YOURPROGRAM.pl -o YOURPROGRAM.exe
Important Notes About wxGlade Generated Code[edit | edit source]
earlier versions of wxGlade introduced an improper idiom at the bottom of the generated Perl script that caused a problem when running via a PAR::Packed packed executable. TLDR; remove the "unless(caller)" block and just run the Wx event loop unfettered. For more information, please read the PAR::FAQ.
earlier versions of wxGlade also used a non-Exporter import tage that wxpar could not properly follow; see the code "before" and "after" below:
use Wx qw[:allclasses];
use strict;
...
package main;
unless(caller){
my $local = Wx::Locale->new("English", "en", "en"); # replace with ??
$local->AddCatalog("app"); # replace with the appropriate catalog name
my $app = MyApp->new();
$app->MainLoop();
}
Should be modified to look like the following:
use Wx;
use strict;
...
package main;
my $local = Wx::Locale->new("English", "en", "en"); # replace with ??
$local->AddCatalog("app"); # replace with the appropriate catalog name
my $app = MyApp->new();
$app->MainLoop();
See this Github issue for wxGlade, where both were fixed. At the time of this writing, the changes. have not been put out in an official release; but they are applied in the master branch.
(copied from the Makefile) - Note, mentions using App::PP::Autolink to sus out required DLLs (provides pp_autolink, which helped!)
all:
wxpar --verbose -o ./dist/nhc-explorer.exe -l c:/strawberry/c/bin/libcrypto-3-x64__.dll -l c:/strawberry/c/bin/zlib1__.dll -l c:/strawberry/c/bin/libssl-3-x64__.dll ./asgs-storm-bug.pl --gui
wxpar --verbose -o ./dist/DEBUG-nhc-explorer.exe -l c:/strawberry/c/bin/libcrypto-3-x64__.dll -l c:/strawberry/c/bin/zlib1__.dll -l c:/strawberry/c/bin/libssl-3-x64__.dll ./asgs-storm-bug.pl
# It was an adventure finding all the dependencies related to the wxpar command,
# particularly those around what was needed, the basic process entailed:
# 1. use wxpar, which generates an options files with all the Wx DLLs
# 2. installed, App::PP::Autolink, which provides the utility "pp_autolink"; this
# utility scans the .pl file you're packing (in this case, "asgs-storm-bug.pl,")
# for DLLs - lo' and behold, it found the ones I needed; in particular the critical
# one that was not getting picked up by pp or wxpar, "libcrypto-3-x64___.dll!"
# 3. ran the "wxpar" command above
# 4. tested in a non-Strawberry Perl window (MSYS2 terminal) using the command,
#
# PERL_DL_DEBUG=5 dist/nhc-explorer.exe
#
# I learned about this command while searching, here:
#
# https://stackoverflow.com/questions/423330/why-cant-dynaloader-pm-load-ssleay-dll-for-netssleay-and-cryptssleay
#
It is worth repeating that pp_autolink, provided by App::PP::Autolink has proven to be absolutely critical to finding the required DLLs that need to be added manually to the wxpar command below via the --link flag.
If you are having problems finding all the DLLs (some which may not be obvious until the EXE generated is tried on a different machine,) you need to give pp_autolink a shot.
A possible "old school" approach, may be to use Office'97 Office Developer Edition (ODE) - via Access'97 there is an installer builder - this is a last resort and still needs to be verified to work for non-Access distributions
Inno Setup (github) - Inno Setup is a free installer for Windows programs by Jordan Russell and Martijn Laan. First introduced in 1997, Inno Setup today rivals and even surpasses many commercial installers in feature set and stability.
The following sections are "works in progress," and remain open questions (for this author anyway). Contributions to develop these sections are greatly appreciated, but not expected. Over time I will update these sections as I learn more about using wxGlade and Perl on Windows.
Distributing EXEs to other Windows Machines[edit | edit source]
While wxpar does indeed create EXEs that can run on Windows machines that do not otherwise have any required libraries on them, I have found some early problems that are most likely due to lack of experience in this area. An understanding of this area is forthcoming.
XRC is a language agnostic and XML based way of describing the GUI layout for wxWidgets. It appears to be the right way to maintain the GUI layout of your production grade program, while maintaining the set of Perl handlers in your own source tree. Think of XRC as the separation of the controller and view in MVC - it to GUI programming what templates are to web application programming. It seems that as one advances his skills in this area, he will want to use XRC. The benefit also of this is that one may be able to create controllers in multiple languages rather than tie the GUI construction in Perl or some other language exclusive - of course, wxGlade can output in different languages, but none is as abstract as XRC.
Wx::Demo example of loading an XRC file; wxGlade can output directly to XRC, which can then be read in Perl. This is how.
Wx::Demo has a few good examples of running XRX applications; wxGlade can output XRC, but it is not aware of any language bindings or drivers for it.
Experience with managing XRC files may allow us as Perl programmers to use RAD tools and GUI builders that were not intended to support wxPerl, but can output XRC files. DialogBlocks is such a professional and commercial GUI builder for wxWidgets, and it is actively maintained.
This great, but out of print wxWidgets book is available for free (PDF) at https://wxwidgets.org/docs/book/. It mentions wxPerl and has an index of tools and programs that any wxWidgets programmer may find interest.
Cross-Platform GUI programming with wxWidgets (free PDF!!) by Julian Smart and Kevin Hock (with Stefan Csomor) is an old, but nice resource to have. It mentions wxPerl quite a bit and has a nice index of tools to help the wxWidgets GUI programmer, regardless of the language they are using. In particular, "Appendix E: Third-Party Tools for wxWidgets" is a very interesting read.
Longer List of RAD Tools and GUI Builders*[edit | edit source]
wxGlade (Latest at this time, Version 1.1.0, July 7, 2024)
wxDesigner (Latest at this time, 2.14 - wxWidgets 2.8.8/ 2.20a - wxidgets pre-3.0, May 2009)
outputs Perl code
archived but a trial is downloadable [here] (archive.org)
Reliable contact for license: undetermined at this time
DialogBlocks - (Latest at this time, Version 5.18, August 21st, 2024)
can export C++, XRC, which wxGlade should be able to import
No Perl export (see XRC)
Cross Platform (Windows, Mac, Linux)
Registration required, but support is discontinued - email support@anthemion.co.uk, they may just give you a free key if you are nice :-)
*You may want to also check this duplicated internal page.
