I'm searching for options to make a GUI based application.
Application needs to intact with http servers, database and GUI.
so best option that I know is to have perl.
I'm searching for a way to Compile the code to ensure the security
also easy development of GUI.
I have started the same with Perl/TK but writing each and every lines of GUI is taking lot of time also its really hard to debug.
Is there any option to that the GUI building can be like QT or .NEt so that the GUI controls can be easily dragged and drop.
If I'm using PerlQT, is drag and drop possible?
Is it possible to compile the code in PerlQT?
Whether this will work in both linux and windows?
Is there any other option like PerlGTK or something else?
If you think “compiling” a Perl script will solve any problems, you are likely to face a disappointment.
Usually, the perl interpreter is just bundled with the plain source code and any used modules into one gargantuan executable. The script isn't really compiled. This makes nothing easier. Also, compilation has nothing to do with security, and can provide a bit of obscurity at best.
Otherwise, you could tread the crazy route and use something that serializes the Perl opcodes into C code, and compile that. Do note that while perl compiles the source into opcodes, it already executes parts of it, so that running the opcode serialization is not the same as running the actual program.
On *nix systems, compiling a Perl script is silly, as the interpreter is readily available.
If you want to fuse Perl and foreign code into one program (!= one executable), take a look at the XS language (binds C to Perl), or at the Inline family of modules.
(Perl-)Qt is pretty awesome, but the last time I looked at the recent bindings, that stuff looked undermaintained and experimental. I am sure that you could leverage the QtDesigner somehow for the designing part, and hook up Perl code with that. This should be pretty portable if you have a compiler on every target system. har har.
Other GUI Toolkits you should seriously consider are GTK and Wx. .Net is right out.
Please realize that Perl is a very dynamic language. While compilation isn't likely to be useful, you can use functional programming techniques like anonymous subroutines and metaprogramming techniques like compile time code generation to simplify your GUI coding. If you write Perl like you would write Java, or other fairly static (& compiled) languages, I wouldn't be suprised if Perl seems painful.
Related
I am decent with Perl, and I've chosen to start learning making GUI interfaces for my Perl programs. That said, I've found it hard to learning how to make a GUI with Qt. I have the bindings from http://code.google.com/p/perlqt4 which seem to be the most recent, but as to how to use them I'm still a bit stumped. All the books and tutorials on the net that I can find are either geared towards using Qt with C++ or with Python.
I'm an absolute Qt beginner and would like to learn how to use it with Perl, but unfortunately the net seems scarce on material for me to use. I can make a GUI design with QtDesigner but don't know how I can fit the code that it generates together with Perl. I can copy the examples from http://code.google.com/p/perlqt4/source/browse/qtgui/examples/tutorial , but those are simple programs withe no accompanying documentation that would allow me to know what is going on or why the code was written that way.
I don't know how Qt or the bindings work but I'd like to learn. Everything that I can find is either obsolete or written for bindings for other languages which I don't understand. I was hoping that some people who've already done this would give me some solid advice or point to some good resources so that I could start learning.
If making a GUI is what you want to do, please consider CitrusPerl that builds on top of wxPerl which is nothing more than a wrapper around wxWidgets. It also makes it very easy to create installers or packagers with the use of Cava Deployment Tools.
TIMTOWTDI
After struggling a further day with the stuff qt4 + perl ..it works in that (stackexchange) way. I use a standard debian wheezy distribution with the packages libqtcore4-perl and libqtgui4-qt etc. Sources from Chris Burel can be found under CPAN or GIT. Regards
I'd like to write some interactive GUIs in Perl. I've used TclTk but it looks dated. I've written QT code for C++, but the PerlTk module hasn't had a release in several years. Googling around I see other possible options.
What are good packages for this, including basic windowing, menus, drawing canvas, scrollbars, and so on.
Gtk2 has glade2 which can write out an XML file usable by Gtk2::GladeXML. Here is an example of how to bundle the XML with the app in the same file.
I misread the question at first. I thought you wanted a GUI editor for making GUIs (which is what glade2 is). You can also create GUIs using Gtk2 without glade2:
#!/usr/bin/perl
use strict;
use warnings;
use Gtk2;
Gtk2->init;
my $window = Gtk2::Window->new;
my $vbox = Gtk2::VBox->new;
my $label = Gtk2::Label->new("Hello World");
my $button = Gtk2::Button->new("Press me");
$window->add($vbox);
$vbox->add($label);
$vbox->add($button);
$window->set_default_size(200, 200);
$window->signal_connect(
destroy => sub {
Gtk2->main_quit;
}
);
my $i = 0;
$button->signal_connect(
clicked => sub {
$label->set_text("button pressed " . ++$i . " times");
}
);
$window->show_all;
Gtk2->main;
Try wxPerl!
From the web site:
wxPerl is an extension module allowing
the creation of GUI (Graphical User
Interface) from Perl; it is built as a
wrapper for the awesome wxWidgets C++
GUI toolkit.
Echoing Chas Owens, glade is quite usable with Gtk2 in Perl. In addition, Gtk2 also supports GtkBuilder files (which you can create the latest glade too).
The main problem with wxPerl (and wxWidgets itself) is that it doesn't let you install file event watchers into its main loop (it only has GUI, Socket and Timer events), unlike Tk and Gtk.
The Qt, Tk and Gtk2 event loops can be used in Perl with AnyEvent, and Gtk2 can be hooked into applications running the Event or Ev mainloop with Glib::Event and Glib::EV modules.
A GUI builder for WxPerl would be wxGlade or wxFormBuilder, both open-source.
I would probably use Gtk2, but Tk is definitely not dead. The lack of releases is due to the bugs being ironed out over the years. A lot of people still use it, and it generally works fine. (Tk's event loop is somewhat silly, but that is a detail that probably shouldn't concern you.) The only disadvantage is that your GUI looks like it is from 1996, but who cares?
(The gitk tool included with git showed that Tk GUIs look fine as long as they're useful.)
Recently I was made aware of another GUI toolkit for Perl called Prima. Its claim to fame is that it was written in C especially for Perl, not a port from TCL or bindings to something else. Assuming you have some rather standard libraries on your system, it will install directly from CPAN and its cross-platform!
David Mertens has been writing a new plotting library for PDL using it, and a REPL too!
Regarding quality of widgets, all three gtk2, wx and qt4 are equally good -- gtk2 is fastest, qt4 has best resolution, whereas wx is somewhere between the two in terms of both the parameters.
But tk is behind all the three both in terms of speed and resolution, but remains firstly because it is the original widget for all unix based interpreted languages, and secondly because it is native-widget of freebsd.
As on today in case of perl, documentation of perl-gtk2 is slightly more developed than both perl-qt4 which is in turn is more developed than wxperl. In fact, if you browse the web, you will find that tutorials for perl-gtk2 is more extensively available than even pygtk (which is also very well established) and ruby-gtk2. In case of python, wxpython documentation leads over PyQt and pygtk, whereas in case of ruby, ruby-qt4 leads over ruby-gtk2 and wxruby. However, others are developing very fast (e.g. ruby-gtk2) and after some time all nine will be equal in all aspects.
The perl-qt4 specific problem is: In case of non-kde desktops, perl-qt4 may not run. I tried running all in ubuntu and sabayon and found that perl-gtk2 and even wxperl (and wxruby also) runs fine whereas I'm not able to run even a single perl-qt4 programs in gnome-desktop where I have installed complete qt4 support without kde.
perl-qt4 asks for installation of not just qt4-libraries, but also kde-desktop libraries. This problem is uniquely perl-qt4-specific, does not exist in case of PyQt and rubyqt4 since they both run fine with qt4 runtime under gnome.
Hence, in this way eight (plus three tk) out of nine options did well (I havent tested PySide yet).
In case of perl-tk, widget is well developed and established and unlike tkinter, pmw and rubytk, its documentation is the best among all of these mentioned above.
But maybe after some time all the documentations become developed and any would become equally good.
After taking a balance between speed, clarity and cross-platform into consideration choose either perl-gtk2, or perl-qt4 or wxperl.
perl-tk, perl-gtk2 and perl-qt4 syntaxes nicely go well with perl programming language syntax, whereas wxperl syntax look more like proper c++ blended into perl which is different from the respective language syntax (just like in case of wxpython and wxruby).
But if you are already keeping in mind that wx code is uniquely different then you can straightaway begin with wxperl.
Otherwise, best way out is: begin with perl-tk, then switch over to perl-gtk2 then perl-qt4 or wxperl alike but make sure that you learn all four instead of only one (the same sequence should also apply to python and ruby too despite the fact that documentation support is reverse, but in case of perl even for this aspect it is same).
I don't have a real answer for you, but often you have to consider your deployment targets. Some of the GUI libraries are very nice, but only if you can get them to work on your operating system. I don't necessarily think that all frameworks need to be cross-platform compatible, a very laudable goal to work toward in a perfect world, as long as the one you choose doesn't lock out a significant portion of your users because the foundation GUIs libraries are hard to install or support on a particular platform.
I just want to let everyone know PerlQt is great and this site has a lot of tutorials on how to use it and lots of examples to download.
PerlQt Wiki tutorial
PerlQt is a very fast and easy way to create great looking GUI programs using the Qt drag and drop form designer and Perl. PerlQt is powerful enough for advanced developers and easy for beginners as well.
The solution I'm going with is Gtk-Perl. At first I had difficulty installing it, but in the end I found Camelbox Perl+Gtk2 in one package.
I have used Tk, but in the last few days I have been playing around with Continuity (CPAN entry), a stateful (persistent state per user) web application/server, and it could easily be a way to add "GUI" features into an application, while making it multi-user and portable at the same time.
Edit: At the time I wrote this, I was most interested in the fact that Continuity had its own built-in webserver. This is now true of other webframeworks for Perl as well. I have been using Mojolicious though I hear good things about Dancer too.
Is Perl a good option for writing (possibly and partially) platform independent desktop applications? I know there are interesting widget libraries like GTK2 Perl and wxWidgets but I'm not familiar with development on Windows.
Is it possible to write a good application with Perl and those tools, maybe embedding everything needed to avoid asking the user to install external (and probably non conventional for many) libraries? Are there examples of this kind of apps around?
Sort of. You can certainly write Perl scripts that provide a Tk GUI that will work on any platform, and you can even package the libraries they need to work with PAR to put together an application that will run anywhere with an appropriate version of perl installed without requiring the end use to install a bunch of stuff from CPAN to get it to work.
However, an application that will run anywhere without requiring an existing perl installation (and it's probably not safe to assume the average Windows user will have perl) isn't really viable. One solution would be to distribute an "everywhere but Windows" version that simply uses PAR to include the necessary libraries, and a PAR::Packer-built version for Windows, which would be a fully-functional .exe including the perl interpreter and the libraries.
EDIT: following daotoad's response, it does appear that ActiveState's PerlApp can build cross-platform binaries for for Windows, Mac OS X, Linux, Solaris, and AIX; I haven't tried this but if it works as advertised it would seem to meet your requirements.
My employer uses ActiveState's PerlApp to produce executable versions of our apps with great success.
We tested PAR and PerlApp before selecting our packaging method. At that time, PerlApp had faster load times. Several versions of each tool have come and gone since then, so I would recommend testing with each before selecting a tool.
Executable packaging has been very effective for us.
There are a few portability issues issues with Perl, but if you pay attention to perlport, it's easy to avoid most issues. Our biggest problems are always with Win32. From time to time, some simple thing will require stupid, bizarre work-arounds or digging into Win32 API for a platform specific hack.
We have used both Wx and Tk guis.
Frozen Bubble is a well known and widely available app you can look at.
Check out PAR (available via CPAN) with respect to your bundling requirement.
Consider having a look at Padre for an example of a complex application written in perl using Wx.
So yes. All of your requirements are achievable, including portability.
I am working on the module XUL::Gui on CPAN, which uses Firefox to display cross platform gui apps from Perl. It is under development, but stable, and may be complete enough for your needs. You can build your gui in HTML and/or XUL (the Mozilla gui language that Firefox itself is written in), and then style everything with CSS. Let me know if you have any feature requests.
I'd like to write some interactive GUIs in Perl. I've used TclTk but it looks dated. I've written QT code for C++, but the PerlTk module hasn't had a release in several years. Googling around I see other possible options.
What are good packages for this, including basic windowing, menus, drawing canvas, scrollbars, and so on.
Gtk2 has glade2 which can write out an XML file usable by Gtk2::GladeXML. Here is an example of how to bundle the XML with the app in the same file.
I misread the question at first. I thought you wanted a GUI editor for making GUIs (which is what glade2 is). You can also create GUIs using Gtk2 without glade2:
#!/usr/bin/perl
use strict;
use warnings;
use Gtk2;
Gtk2->init;
my $window = Gtk2::Window->new;
my $vbox = Gtk2::VBox->new;
my $label = Gtk2::Label->new("Hello World");
my $button = Gtk2::Button->new("Press me");
$window->add($vbox);
$vbox->add($label);
$vbox->add($button);
$window->set_default_size(200, 200);
$window->signal_connect(
destroy => sub {
Gtk2->main_quit;
}
);
my $i = 0;
$button->signal_connect(
clicked => sub {
$label->set_text("button pressed " . ++$i . " times");
}
);
$window->show_all;
Gtk2->main;
Try wxPerl!
From the web site:
wxPerl is an extension module allowing
the creation of GUI (Graphical User
Interface) from Perl; it is built as a
wrapper for the awesome wxWidgets C++
GUI toolkit.
Echoing Chas Owens, glade is quite usable with Gtk2 in Perl. In addition, Gtk2 also supports GtkBuilder files (which you can create the latest glade too).
The main problem with wxPerl (and wxWidgets itself) is that it doesn't let you install file event watchers into its main loop (it only has GUI, Socket and Timer events), unlike Tk and Gtk.
The Qt, Tk and Gtk2 event loops can be used in Perl with AnyEvent, and Gtk2 can be hooked into applications running the Event or Ev mainloop with Glib::Event and Glib::EV modules.
A GUI builder for WxPerl would be wxGlade or wxFormBuilder, both open-source.
I would probably use Gtk2, but Tk is definitely not dead. The lack of releases is due to the bugs being ironed out over the years. A lot of people still use it, and it generally works fine. (Tk's event loop is somewhat silly, but that is a detail that probably shouldn't concern you.) The only disadvantage is that your GUI looks like it is from 1996, but who cares?
(The gitk tool included with git showed that Tk GUIs look fine as long as they're useful.)
Recently I was made aware of another GUI toolkit for Perl called Prima. Its claim to fame is that it was written in C especially for Perl, not a port from TCL or bindings to something else. Assuming you have some rather standard libraries on your system, it will install directly from CPAN and its cross-platform!
David Mertens has been writing a new plotting library for PDL using it, and a REPL too!
Regarding quality of widgets, all three gtk2, wx and qt4 are equally good -- gtk2 is fastest, qt4 has best resolution, whereas wx is somewhere between the two in terms of both the parameters.
But tk is behind all the three both in terms of speed and resolution, but remains firstly because it is the original widget for all unix based interpreted languages, and secondly because it is native-widget of freebsd.
As on today in case of perl, documentation of perl-gtk2 is slightly more developed than both perl-qt4 which is in turn is more developed than wxperl. In fact, if you browse the web, you will find that tutorials for perl-gtk2 is more extensively available than even pygtk (which is also very well established) and ruby-gtk2. In case of python, wxpython documentation leads over PyQt and pygtk, whereas in case of ruby, ruby-qt4 leads over ruby-gtk2 and wxruby. However, others are developing very fast (e.g. ruby-gtk2) and after some time all nine will be equal in all aspects.
The perl-qt4 specific problem is: In case of non-kde desktops, perl-qt4 may not run. I tried running all in ubuntu and sabayon and found that perl-gtk2 and even wxperl (and wxruby also) runs fine whereas I'm not able to run even a single perl-qt4 programs in gnome-desktop where I have installed complete qt4 support without kde.
perl-qt4 asks for installation of not just qt4-libraries, but also kde-desktop libraries. This problem is uniquely perl-qt4-specific, does not exist in case of PyQt and rubyqt4 since they both run fine with qt4 runtime under gnome.
Hence, in this way eight (plus three tk) out of nine options did well (I havent tested PySide yet).
In case of perl-tk, widget is well developed and established and unlike tkinter, pmw and rubytk, its documentation is the best among all of these mentioned above.
But maybe after some time all the documentations become developed and any would become equally good.
After taking a balance between speed, clarity and cross-platform into consideration choose either perl-gtk2, or perl-qt4 or wxperl.
perl-tk, perl-gtk2 and perl-qt4 syntaxes nicely go well with perl programming language syntax, whereas wxperl syntax look more like proper c++ blended into perl which is different from the respective language syntax (just like in case of wxpython and wxruby).
But if you are already keeping in mind that wx code is uniquely different then you can straightaway begin with wxperl.
Otherwise, best way out is: begin with perl-tk, then switch over to perl-gtk2 then perl-qt4 or wxperl alike but make sure that you learn all four instead of only one (the same sequence should also apply to python and ruby too despite the fact that documentation support is reverse, but in case of perl even for this aspect it is same).
I don't have a real answer for you, but often you have to consider your deployment targets. Some of the GUI libraries are very nice, but only if you can get them to work on your operating system. I don't necessarily think that all frameworks need to be cross-platform compatible, a very laudable goal to work toward in a perfect world, as long as the one you choose doesn't lock out a significant portion of your users because the foundation GUIs libraries are hard to install or support on a particular platform.
I just want to let everyone know PerlQt is great and this site has a lot of tutorials on how to use it and lots of examples to download.
PerlQt Wiki tutorial
PerlQt is a very fast and easy way to create great looking GUI programs using the Qt drag and drop form designer and Perl. PerlQt is powerful enough for advanced developers and easy for beginners as well.
The solution I'm going with is Gtk-Perl. At first I had difficulty installing it, but in the end I found Camelbox Perl+Gtk2 in one package.
I have used Tk, but in the last few days I have been playing around with Continuity (CPAN entry), a stateful (persistent state per user) web application/server, and it could easily be a way to add "GUI" features into an application, while making it multi-user and portable at the same time.
Edit: At the time I wrote this, I was most interested in the fact that Continuity had its own built-in webserver. This is now true of other webframeworks for Perl as well. I have been using Mojolicious though I hear good things about Dancer too.
Are there any libraries out there that do this? Playing around with Common Lisp it seems like this would be one of the most useful things to lower barrier of entry for newcomers. ASDF seems mostly designed for deployment, not for rapid prototyping and development. Following threads on comp.lang.lisp it seems like people agree that CL's package system is powerful, but lacks the ease of something like Python's dead simple module system. It is FAIL in the sense that it's designed for power not usability.
Glad to know if I'm wrong. If I'm right, I'm stunned that noone has tried to build a Python module-like system on top of ASDF.
Zach Beane wrote how he nowadays starts new Common Lisp projects by using Quicklisp and Quickproject. This might be along the lines you want.
Not sure if it's ready for prime time or whether it fits your requirements at all, but here's a link to XCVB.
I don't know. I mostly use ASDF for my in-development compilation needs. Once you notice that you'd benefiot from more than one source file, open <projectname>.asd, slap in a basic ASDF system definition template and start slapping filenames in. As and when you notice a cross-file dependency, update the dependency list.
But, then, I use the exact same method dealing with Makefiles (yes, I know there are automatic dependency checkers that can do it for you, but since I mostly code on my own, it's easier to just amend the Makefile/ASDF definition as I go).
In SBCL, there's a hook on REQUIRE that checks for ASDF systems, so you end up with something that is about as convenient as Python's import, but somehow I suspect that is not what you meant.
This may not be the answer you want, but clearly you have some idea of what you want in a module system. Have you considered creating one yourself? That is, taking your limited domain, your limited requirements, your environment and simply pounding out whatever abstractions will quickly make your life easier?
That's one of the key benefits of Lisp I'm sure you know, is that these simple abstractions and little tools are typically very easy to craft in Lisp.
I'm not suggesting solving everyone who has a problem with the package system or ASDF, I'm simply suggesting solving your own problem as you understand it, which is likely simpler and smaller than some more powerful larger scope.
There is Mudballs now, too.
If you're looking for a piece of software to add this functionality to then it's a good bet.
If you want a command line tool that just uses bash to generate new common lisp project directory and file layouts, you may find one that I created for myself useful: lispproject. If it doesn't match your needs, go ahead and fork it or the repo it gets it templates from to suit your needs: lisp-project-template. Look at the sh file in lispproject repo to see how the templates are used. Also, please note that you may need to adjust the calls to sed to fit your platform as I am using this on macOS. Alternative sed calls are in the main script but just commented out if you need them.
it's designed for power not usability
that's how most Lisp gurus like it.