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.
