Editing Perl and wxWidgets RAD on Windows (section)

== 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.