GUI wrapper/compiler with Perl

[Phil Jacobson]

Hello everyone.

I enjoy working with Perl and like to use it exclusively at work and
home. I've been given a few tasks to complete at work and I'm looking
for a simple way to create GUI applications but still use Perl. The
problem lies in that I need to develop a few apps that will be used at
50 different facilities. I'd rather not hassle my administrator with
getting Perl installed everwhere else so I need something that I can
contain in one reasonably sized file and send to all the other
facilities.

I've already written the apps on the console level. Do any of you have
ideas on simple GUI compilers that I can use to develop the interface
that would wrap nicely around Perl? For example, Rapid-Q makes
creating GUI apps easy, and the executable is a manageble size. It
would be fantastic if I could make the two or three forms I need in
something similar to Rapid-Q and point the menu and button calls to
the Perl code I've already written. Compile it all up into one file
and send it off to the other locations. I know I might lose some
performance doing things this way, but I'm not too worried because the
apps I need to create are pretty simple and my intended audience is
not computer professionals who require loads of options.

I'm using ActiveState Perl on WinXP at home. The other facilities are
all currently running WinNT.

Any thoughts? I thank you for your time.
Phil Jacobson

 

[Ben Morrow]

I've already written the apps on the console level. Do any of you have
ideas on simple GUI compilers that I can use to develop the interface
that would wrap nicely around Perl? For example, Rapid-Q makes
creating GUI apps easy, and the executable is a manageble size. It
would be fantastic if I could make the two or three forms I need in
something similar to Rapid-Q and point the menu and button calls to
the Perl code I've already written. Compile it all up into one file
and send it off to the other locations.

For a GUI I'd use Tk, and for packaging PAR. You don't get a
pointy-clicky gooey designer with Tk, though: you have to write the code
yourself. It's not hard.

Ben

 

[James Willmore]

For a GUI I'd use Tk, and for packaging PAR. You don't get a
pointy-clicky gooey designer with Tk, though: you have to write the code
yourself. It's not hard.

Sorry, but there is a designer for the Tk module.

It's specPerl (http://www.keck.ucsf.edu/~kvale/specperl).

I don't find it to be the greatest tool to use, but it does help in
initial design.

--
Jim

Copyright notice: all code written by the author in this post is
released under the GPL. http://www.gnu.org/licenses/gpl.txt
for more information.

a fortune quote ...
"Whom are you?" said he, for he had been to night school. --
George Ade

 

[Chris]

Hello everyone.

I enjoy working with Perl and like to use it exclusively at work and
home. I've been given a few tasks to complete at work and I'm looking
for a simple way to create GUI applications but still use Perl. The
problem lies in that I need to develop a few apps that will be used at
50 different facilities. I'd rather not hassle my administrator with
getting Perl installed everwhere else so I need something that I can
contain in one reasonably sized file and send to all the other
facilities.

I've already written the apps on the console level. Do any of you have
ideas on simple GUI compilers that I can use to develop the interface
that would wrap nicely around Perl? For example, Rapid-Q makes
creating GUI apps easy, and the executable is a manageble size. It
would be fantastic if I could make the two or three forms I need in
something similar to Rapid-Q and point the menu and button calls to
the Perl code I've already written. Compile it all up into one file
and send it off to the other locations. I know I might lose some
performance doing things this way, but I'm not too worried because the
apps I need to create are pretty simple and my intended audience is
not computer professionals who require loads of options.

I'm using ActiveState Perl on WinXP at home. The other facilities are
all currently running WinNT.

I always try to let my "GUI" be an end-user's Web browser. I know that
isn't the answer perhaps for which you were looking, but it just happens
to be the number one end-point in the world that you can code for at
this point. My opinion.

Chris