Editing Perl and wxWidgets RAD on Windows

== Perl and wxWidgets RAD on Windows ==

This page provides background on earlier efforts to support Perl-based desktop GUI development on Windows, especially through wxWidgets, wxPerl, GUI builders, packaging tools, and installer systems.

The short version is that Perl has had many of the pieces needed for Windows GUI development, but it has not had a durable, unified rapid application development environment comparable to Lazarus for Free Pascal.

Review the main article on this setting up and creating applications in this way [[Developing and Distributing wxPerl Applications on Windows|here]].

== Big Picture ==

Perl's Windows GUI story has never lacked raw capability. The pieces have existed: Perl on Windows, wxWidgets bindings, GUI designers, packagers, and installers. What Perl lacked was integration: one maintained, documented, beginner-friendly path from "I know Perl" to "I can ship a Windows desktop application."

That is why the Lazarus comparison is useful. Free Pascal's Lazarus gives users an IDE, form designer, widget library, project model, compiler integration, and distribution path in one recognizable environment. Perl's wxWidgets path has historically required knowing which distribution of Perl to use, which wxPerl build worked, which GUI builder could output Perl or XRC, how to preserve hand-edited code, how to find DLLs, how to package with <code>pp</code> or <code>wxpar</code>, and how to turn the result into something a Windows user can install.

== Foundation: wxWidgets and wxPerl ==

The technical foundation is [https://wxwidgets.org/ wxWidgets], a cross-platform C++ GUI library originally started by Julian Smart. Its core appeal is important for Perl: it lets applications run across platforms while using native GUI controls rather than drawing fake controls itself. That matters on Windows because commercial desktop users generally expect normal-looking Windows applications.

* [https://wxwidgets.org/about/history/ wxWidgets history]

[https://metacpan.org/pod/Wx wxPerl], distributed on CPAN as <code>Wx</code>, is the Perl binding to wxWidgets. It gives Perl programmers access to the wxWidgets toolkit from Perl code.

The modern GitHub lineage credits Mattia Barbon for the 2000-2010 era, Mark Dootson for 2010-2017, and Johan Vromans for the 2024 revival work.

* [https://metacpan.org/pod/Wx Wx on MetaCPAN]
* [https://github.com/sciurius/wxPerl Modern wxPerl repository]
* [https://dev.to/sciurius/wxperl-revival-5fde wxPerl Revival by Johan Vromans]

This matters because wxPerl was never just a toy binding. It was a serious path for real Perl desktop applications. Padre itself helped prove that large wxPerl applications were possible, while also showing the need for better GUI design tools and installers.

== The Recurring Problem: Windows Setup Friction ==

On Unix-like systems, Perl users usually have compilers, headers, and build tools nearby. Windows historically did not provide that environment by default. That made wxPerl difficult because it depends on compiled XS bindings and wxWidgets libraries.

This is where [https://strawberryperl.com/ Strawberry Perl] became important. Strawberry Perl provides Perl on Windows along with compiler and build tools, making CPAN and XS-based modules much more realistic on Windows.

Even so, Strawberry Perl did not by itself create a Lazarus-like experience. It solved a major prerequisite:

<blockquote>
Can I build and install Perl modules on Windows?
</blockquote>

It did not solve the full application-development path:

<blockquote>
Can I design a GUI, generate sane code, package the executable, track DLLs, and build an installer?
</blockquote>

== Citrus Perl ==

[https://sourceforge.net/projects/citrusperl/ Citrus Perl] was one of the closest earlier attempts to make Perl GUI development easier. It was a binary Perl distribution aimed at GUI application developers and included wxPerl.

SourceForge describes Citrus Perl as a Perl distribution with pre-built wxPerl modules against wxWidgets 3.0.2, built with Perl 5.24.1, and targeted at users developing wxPerl GUI applications.

* [https://sourceforge.net/projects/citrusperl/files/ Citrus Perl files on SourceForge]

The value of Citrus Perl was that it reduced the build-stack problem. Instead of making every Windows developer assemble Perl, wxWidgets, wxPerl, compilers, and supporting libraries, it tried to ship a coherent distribution.

Its limitation was that it was still a distribution, not a full RAD environment. It helped with runtime and module availability, but it did not become a lasting ecosystem with a current IDE, visual designer, packaging workflow, and installer workflow all moving together.

== wxGlade: The Important Survivor ==

[https://wxglade.sourceforge.net/ wxGlade] is the strongest surviving Perl-relevant GUI builder in this story. It is a GUI designer written in Python for wxWidgets and wxPython interfaces, and it can generate Perl, Python, C++, Lisp, and XRC.

* [https://wxglade.sourceforge.net/ wxGlade project site]
* [https://github.com/wxGlade/wxGlade wxGlade on GitHub]

That distinction matters. wxGlade is not Lazarus. It does not give Perl a complete IDE. But it gives Perl something extremely valuable: a maintained visual designer that still knows how to output Perl code.

In the Perl Lazarus effort, wxGlade is the practical RAD-ish form designer, not the whole development environment.

Historically, wxGlade also mattered because it gave Perl programmers a relatively direct path:

# Design a frame or dialog.

# Output Perl code.

# Wire up event handlers.

# Run the application with wxPerl.

# Package and distribute the result.

The hard part has been learning how not to clobber custom code when regenerating GUI code, and eventually learning when to move toward XRC for cleaner separation.

== wxDesigner ==

[https://web.archive.org/web/20131020024033/http://www.wxdesigner-software.de/download.html wxDesigner] was one of the stronger early GUI-builder/RAD tools for wxWidgets and its Perl/Python bindings.

A 2009 wxWidgets news post describes wxDesigner as a GUI builder for wxWidgets and its popular Python and Perl bindings, with a version based on the upcoming wxWidgets 3.0 branch.

* [https://wxwidgets.org/news/2009/03/new-version-of-wxdesigner-based-on-wxwidgets-pre-3-0-released/ wxDesigner wxWidgets news post]
* [https://web.archive.org/web/20131020024033/http://www.wxdesigner-software.de/download.html archived wxDesigner download page]

For Perl history, wxDesigner matters because it appears to have been one of the tools that could directly output Perl code.

wxDesigner was not a failure in the sense of being useless. It belonged to an earlier wxWidgets/wxPerl generation and did not remain a maintained, accessible pillar for modern Perl-on-Windows development.

== VisualWX ==

[http://visualwx.altervista.org/ VisualWX] was an ambitious multi-language RAD project. Its public description says it aimed to be a RAD tool for C++, Python, Perl, Ruby, Lua, and wxWidgets, generating code for those languages.

* [http://visualwx.altervista.org/ VisualWX project page]
* [https://wiki.wxwidgets.org/Tools wxWidgets tools wiki]

VisualWX matters because it shows that the demand existed. People wanted visual wxWidgets development across scripting languages, including Perl.

But VisualWX did not become the enduring answer. It is best treated as an ambitious discontinued or historical effort that demonstrates the same recurring pattern: the idea was sound, but the maintenance burden was high.

== wxFormBuilder, FBP, and Padre Form Builder ==

[https://github.com/wxFormBuilder/wxFormBuilder wxFormBuilder] is important because it became one of the better-known wxWidgets GUI builders, but it does not currently generate Perl code directly.

Its current project summary lists code generation for C++, Python, Lua, and PHP, plus XRC import/export.

* [https://github.com/wxFormBuilder/wxFormBuilder wxFormBuilder on GitHub]
* [https://sourceforge.net/projects/wxformbuilder.mirror/ wxFormBuilder SourceForge mirror]

That gap led to Perl bridge work.

[https://www.cpan.org/modules/by-module/Pod/ADAMK/FBP-0.01.readme FBP] parsed wxFormBuilder project files so Perl code could be generated independently. The FBP README explains that wxFormBuilder was a sophisticated program for designing wxWidgets dialogs, but did not support Perl code generation, so Perl generation had to happen separately.

* [https://www.cpan.org/modules/by-module/Pod/ADAMK/FBP-0.01.readme FBP README]

[https://blogs.perl.org/users/adam_kennedy/2011/07/padre-form-builder---a-cross-platform-gui-design-solution-for-perl.html Padre Form Builder] was a larger attempt to turn that into a Perl-friendly GUI design workflow. Adam Kennedy described it in 2011 as a native cross-platform GUI design solution for Perl.

* [https://blogs.perl.org/users/adam_kennedy/2011/07/padre-form-builder---a-cross-platform-gui-design-solution-for-perl.html Padre Form Builder announcement]

This was one of the most important almost-Lazarus-like moments in Perl GUI history. Padre itself was a Perl IDE built with wxPerl, and Padre Form Builder tried to connect a real visual designer to Perl code generation.

The weakness was that it depended on a chain:

# Padre

# wxPerl

# wxFormBuilder

# FBP parsing

# generated Perl

# packaging and distribution

When Padre momentum declined and the desktop Perl ecosystem cooled, that chain did not become the standard Windows GUI workflow.

== DialogBlocks and XRC ==

[http://www.anthemion.co.uk/dialogblocks/ DialogBlocks] belongs in the history, but with an important caveat: it is a wxWidgets GUI builder that can export C++ and XRC, not Perl directly.

* [http://www.anthemion.co.uk/dialogblocks/features.htm DialogBlocks features]

That still matters for Perl because wxPerl can use XRC through <code>Wx::XRC</code>. XRC is a language-neutral XML resource format for describing wxWidgets interfaces.

In theory, this lets a Perl developer use a GUI builder that knows nothing about Perl, export XRC, and then write Perl code that loads the interface and attaches handlers.

This is probably the more mature long-term architectural path for larger wxPerl applications:

# Use a visual designer for layout.

# Keep layout in XRC.

# Keep Perl code focused on behavior and event handling.

However, it is less beginner-friendly than "generate Perl and run it," so it does not solve the initial RAD onboarding problem by itself.

== Cava Packager ==

The GUI designer was only half the problem. Windows users expect an <code>.exe</code> or an installer, not a <code>.pl</code> file and a list of CPAN dependencies.

[https://www.slideshare.net/slideshow/clujpm-march2014talk/35056878 Modern Perl desktop apps] talks from the earlier wxPerl era presented Cava Packager as one answer to this problem.

* [https://www.slideshare.net/slideshow/clujpm-march2014talk/35056878 Modern Perl desktop apps slides]

Cava Packager addressed the commercial-distribution question:

<blockquote>
How do I give a client something they can install and run?
</blockquote>

Like Citrus Perl, it did not become the lasting default path for modern wxPerl-on-Windows development, but it remains an important part of the history.

== Why the Older Efforts Aged Out ==

The recurring issue was not that Perl could not do GUI programming. It could.

The problem was that a complete Windows GUI workflow touched too many fragile layers:

# Perl version compatibility

# wxWidgets version compatibility

# wxPerl XS binding compatibility

# Windows compiler/toolchain compatibility

# 32-bit vs. 64-bit issues

# GUI builder support for Perl or XRC

# Generated-code quality

# Avoiding clobbered hand-written code

# Packaging with all required DLLs present

# Installer creation

# Long-term maintainership

That is a lot for a volunteer-scale ecosystem to hold together. A Lazarus-like tool succeeds because one project owns the whole developer experience. The Perl ecosystem historically provided excellent pieces, but each piece lived in a different project with different maintainers and different release cycles.

== The Quiet Period ==

By the late 2010s and early 2020s, wxPerl was still known, but it was not widely presented as a modern, easy Windows GUI path.

The clearest sign of the quiet period is Johan Vromans's revival work. His wxPerl Revival post says the <code>wx30</code> branch updated the last official 0.9932 release for modern Perl and wxWidgets 3.0, while the master branch was updated for wxWidgets 3.2 and released as Wx-3.001.

* [https://dev.to/sciurius/wxperl-revival-5fde wxPerl Revival]

That revival is significant. It means the modern story is not merely nostalgia. wxPerl is again being adapted to current Perl and wxWidgets versions.

Windows remains one of the harder environments because it combines Perl, XS, compilers, DLLs, and native GUI libraries.

== The Modern Reset ==

The modern Perl Lazarus direction is best understood as a stack consolidation project, not a new IDE from scratch.

The practical stack is:

* [https://strawberryperl.com/ Strawberry Perl] for Perl and build tools
* [https://github.com/sciurius/perl-Alien-wxWidgets Alien::wxWidgets] and [https://github.com/sciurius/wxPerl Wx/wxPerl] for the wxWidgets binding
* [https://wxglade.sourceforge.net/ wxGlade] for Perl-friendly visual GUI design
* <code>PAR::Packer</code>, <code>pp</code>, <code>wxpar</code>, and related tools for executable packaging
* DLL discovery helpers such as <code>pp_autolink</code>
* installer systems such as [https://jrsoftware.org/isinfo.php Inno Setup], [https://nsis.sourceforge.io/Main_Page NSIS], or [https://wixtoolset.org/ WiX]
* a helper application, Martha, to reduce the packaging and installer gap

The current problem is not merely generating Perl code from wxGlade. The user also needs to distribute the result in the way Windows users expect.

That means building a workflow from:

# install the development stack

# verify wxPerl works

# design the GUI

# generate or load the interface

# write the Perl behavior

# package the program

# find required DLLs

# build an installer

# test on a clean Windows machine

== What the Perl Lazarus Project Is Reviving ==

The Perl Lazarus Project is not reviving a single abandoned application. It is reviving a workflow that existed in pieces.

* Citrus Perl showed the value of a GUI-focused Perl distribution.
* wxDesigner and VisualWX showed the desire for visual wxWidgets design with Perl output.
* wxGlade survived as the practical Perl-code-generating GUI builder.
* wxFormBuilder plus FBP and Padre Form Builder showed another possible route through project-file parsing and code generation.
* DialogBlocks showed how XRC can let Perl benefit from non-Perl wxWidgets design tools.
* Cava Packager showed that GUI development is incomplete without binary and installer distribution.
* Strawberry Perl made the Windows Perl build environment more realistic.
* Johan Vromans's wxPerl revival reopened the door for a modern wxPerl stack.
* Martha aims to help bridge the gap from generated Perl code to executable and installer.

The strongest historical claim is this:

<blockquote>
Perl has already had most of the ingredients for RAD-style Windows GUI development, but they were scattered, aging, or underdocumented. The Perl Lazarus Project is about collecting the viable pieces, documenting tested combinations, and bridging the gaps from GUI design to paid Windows software.
</blockquote>

== Suggested Link Set ==

* [https://wxwidgets.org/about/history/ wxWidgets history]
* [https://metacpan.org/pod/Wx Wx / wxPerl on MetaCPAN]
* [https://dev.to/sciurius/wxperl-revival-5fde Johan Vromans's wxPerl Revival]
* [https://github.com/sciurius/wxPerl modern wxPerl GitHub repository]
* [https://wxglade.sourceforge.net/ wxGlade]
* [https://github.com/wxGlade/wxGlade wxGlade on GitHub]
* [https://sourceforge.net/projects/citrusperl/files/ Citrus Perl on SourceForge]
* [https://wxwidgets.org/news/2009/03/new-version-of-wxdesigner-based-on-wxwidgets-pre-3-0-released/ wxDesigner wxWidgets news post]
* [https://web.archive.org/web/20131020024033/http://www.wxdesigner-software.de/download.html archived wxDesigner download page]
* [http://visualwx.altervista.org/ VisualWX]
* [https://blogs.perl.org/users/adam_kennedy/2011/07/padre-form-builder---a-cross-platform-gui-design-solution-for-perl.html Padre Form Builder]
* [https://www.cpan.org/modules/by-module/Pod/ADAMK/FBP-0.01.readme FBP README]
* [https://github.com/wxFormBuilder/wxFormBuilder wxFormBuilder]
* [http://www.anthemion.co.uk/dialogblocks/features.htm DialogBlocks features]
* [https://www.slideshare.net/slideshow/clujpm-march2014talk/35056878 Modern Perl desktop apps slides]
* [https://strawberryperl.com/ Strawberry Perl]
* [https://jrsoftware.org/isinfo.php Inno Setup]
* [https://nsis.sourceforge.io/Main_Page NSIS]
* [https://wixtoolset.org/ WiX Toolset]