What are the disadvantages of the Tk module compared to other solutions to create a GUI in Perl?
What are the disadvantages of the Tk module compared to other solutions to create
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
What are the disadvantages of the Tk module compared to other solutions to create a GUI in Perl?
I toured the various gui modules for Perl recently, and here is my summary (disclaimer: ultimately I found that none of the existing modules met my needs so I started writing my own gui toolkit).
Tk – Decent to work with and the interface is very perlish. The gui itself is a bit dated looking, and doesnt take advantage of any of the operating system’s native widgets (like filepickers). On most systems it will require a C compiler to install.
Wx – Difficult to work with, un-perlish interface. Large programs almost require a gui builder to keep track of everything. Support for os level widgets is mixed. Nicer looking than Tk IMO. Compilation is involved, requires installing several libraries, can be difficult to get running on windows. The assembly of programs is very procedural, and does not map cleanly to what the program will actually look like.
Qt – last I looked this module was more or less abandoned and only supports Qt3. I didn’t try to install it, but i imagine it needs a compiler.
Prima – Similar to Tk it has a dated appearance. Requires a compiler.
W32::GUI – I ruled this out early since it is not cross platform.
XUL::Node / POE::XUL::Node – rather heavy dependency tree that includes C code. Seems unmaintained and I had mixed experiences getting it to install. Windows was a no go, OSX was a no go, it had limited functionality on OpenSUSE. It also only supports a subset of the XUL language.
I found that none of the existing gui toolkits made it easy enough to distribute your application to end users. It is ok to expect programmers to jump through the hoops of resolving library dependencies and compiling code, but end users aren’t going to do that. So the first requirement I had was to be pure Perl.
Secondly, nearly all of the existing gui toolkits force you to work in a very procedural manner: Create a container. Create a packer for the container. Create an object. Set properties on that object. Add the object to the packer. Run the packer to fill the container object. Repeat.
Instead, I find that nested design (like HTML) is easier to follow for two reasons. First off, since objects are nested, there is no need to name everything (label_456, label_457…). Secondly, the structure of the program mirrors the structure of what is displayed.
So I started work on XUL::Gui, and its been coming along rather well. It is pure Perl, and only depends on core modules for ease of installation. It has one external requirement, which is that a recent (3+) copy of Firefox is installed. It uses the familiar design pattern of web development with nested tags styled with CSS. It is certainly at a level where you could write fully featured single window applications with it.
Hopefully this helps you to figure out which toolkit is best for your project.