franšais

PerlQt FAQ

general questions

Where does PerlQt come from ? Has it been around for a long time ?
Quite so! Quoting Ashley Winters (Nov 2002), the father of PerlQt : "The six-year anniversary of the birth of PerlQt is coming up next month -- Dec 26, 1996 is when Arnt Gulbrandsen's boasting about his 'new' GUI toolkit's programming contest and my hubris led me down the fateful path to PerlQt. "
PerlQt-3 is the third incarnation of this long lasting hubris 8)
What is the Smoke library ? Why is that needed ?
SMOKE is a thin wrapper around Qt, and soon KDE.
It was designed by Ashley Winters as a way to share most of what every set of bindings, regardless of the language, must implement.
Not only does it provide wrappers for every function in every class, but it also contains meta-information allowing queries of what functions are available and their arguments and return-types - in a CORBA-like way.
All classes, all methods, with all arguments, along with various flags reflecting staticness, virtuality, etc. are stored into cross-referencing arrays for fast lookups. One can thus read (and call) the whole Qt API by simply reading a few arrays.
The main purpose of SMOKE is to make it easy to write bindings from scripting languages to Qt and KDE - with an emphasis on flexibility.
Fine, but I've heard Smoke is now part of KDE. Does this mean that KDE is required ?
Not at all. PerlQt comes bundled with its own copy of Smoke and will build it if needed. If KDE happens to be there, Puic would use its root as a prefix for installation and Smoke would be stored with the others KDE libraries.
Otherwise, either the --prefix you specified or a default one would be used.
Bindings often tend to break between minor versions, or even to segfault every now and then. They are hudge and slow to compile. What about Smoke/PerlQt ?
Since Smoke reflects only the public API of Qt, it won't break between minor versions. It is as binary compatible as Qt itself.
You would typically compile it once for every major Qt version, getting a resulting shared object about half the size of traditionals, language specific bindings - yet Smoke can be used by other languages. PerlQt itself might break slightly more easily, but recompiling is trivial : it takes at most three minutes on a slow machine to build the small Perl specific object.
For what regards stability, it is worth noticing that most segfaults occur because users aren't familiar with the original language (here C++) and make mistakes. In such cases, the introspection facilities offered by Smoke are of tremendous help. One can track exactly what Qt function is called, what arguments it expects and even receive a list of closely matching functions (see Qt::debug in documentation).
Yet why should I use PerlQt in the first place ? Is there any obvious advantage over other GUI solutions ?
Well, there are plenty, but it mostly depends on your needs...
If you are looking for the most portable solution, then PerlQt might not be the answer yet. It has been known to compile on various Unix platforms including Solaris and Mac OS X (Fink), but Windows remains unexplored.
That's honestly its sole obvious shortcoming.
Consider : not only Qt is renowned for it's clean design, power, flexibility and ease of use, all qualities that map quite naturally in PerlQt- but it also comes with a full fledged RAD environment.
With Qt Designer and Puic (the PerlQt User Interface Compiler) building an application can literally be a matter of minutes.
As a mean of building prototypes, PerlQt is amazing : your GUI design is always immediately reusable in C++, since Qt Designer uses a single XML format.
Physicists and computer scientists like it because it plainly fullfill their needs for quickly developed internal applications treating signals or datas, others like the cleaner object oriented model it brings to Perl through attributes and slots/signals, others fancy the high quality of widgets and their easy subclassing... your mileage may vary.

Specific issues

I can't access some method in some classes... PerlQt says " --- No method to call for : XXX". Yet the method is referenced in Qt's documentation...
Most likely, you are trying to access a method defined in a template, within one of the parent classes.
Templates are special generic C++ classes allowing one to specify a custom type (eg. QValueList<int> for a list of integers, QValueList<float> for a list of reals)...
PerlQt can't handle those at the moment, but it should soon.
I keep experiencing strange behaviours when constructing a widget without parents (thus passing a Null pointer as the parent argument) : sometimes it just doesn't work, sometimes it segfaults. What's going wrong ?
First, while developing, it is always a good idea to use Qt::debug, or even use Qt::debug qw|verbose ambiguous calls|.
You may also enable it from the command line with
perl -MQt::debug=verbose,ambiguous,calls MyProgram.pl
Then, be very careful that Perl's idea of a Null pointer isn't zero, but 'undef'.
If that does not help, please contact us or file a bug report



The use of a camel image with the topic of Perl is a trademark of O'Reilly & Associates, Inc. Used with permission.
The Qt logo (TM) is a registered trademark of Trolltech (TM) AS, Norway.