Germain Garand
This document describes a set of Perl bindings for the Qt toolkit. Contact the author at <germain@ebooksfrance.com>
PerlQt-3 is Ashley Winters' full featured object oriented interface to Trolltech's C++ Qt toolkit v3.0.
It is based on the SMOKE library, a language independent low-level wrapper generated from Qt headers by Richard Dale's kalyptus thanks to David Faure's module.
This document describes the principles of PerlQt programming. It assumes you have some basic Perl Object Oriented programming knowledge.
Some C++ knowledge is recommended but not required. It would mostly help you to find your way through Qt's excellent online documentation which is our ultimate and only reference.
To compile and use PerlQt, you'll need :
Perl and Qt's installation is out of the scope of this document. Please refer to those projects' documentation.
PerlQt uses GNU's Autoconf framework. However, the standard ./configure script is preferably driven by the Makefile.PL wrapper. All options are forwarded to ./configure :
perl Makefile.PL
If SMOKE is missing, configure will generate its sources (4 minutes on an average system).
Then :
make
(40 minutes average if Smoke needs to be built)
make install
This will install PerlQt, Puic and Smoke (if needed).
The preferred install location for SMOKE and Puic is in the KDE3 file system.
If you don't have KDE3 installed, specify a location with configure's
--prefix option. e.g:
perl Makefile.PL --prefix=/usr
If Smoke's linking fails or your Qt library was built with very specific options, run Makefile.PL again with:
perl Makefile.PL --with-threshold=0
When building smoke, configure will check for OpenGL and try to compile support for it if it is properly installed and supported by Qt.
You may disable this checking with:
--disable-GL
Also, default behaviour is to prefer the Mesa GL library over a proprietary implementation. If your system features a proprietary OpenGL library, and you'd like to use it, specify:
--without-Mesa
A typical Qt program using GUI components is based on an event loop.
This basically means that such a program is no more envisioned as a straight flow where you would need to handle yourself every single events (such as a mouse click or a key press).
Instead, you just create an Application object, create the GUI components it uses, define what objects methods need to be called when an event occurs, and then start the main event loop.
That's all! Qt will handle all events and dispatch them to the correct subroutine.
Lets see how this process is implemented in a minimal PerlQt program.
1: use Qt;
2: my $a = Qt::Application(\@ARGV);
3: my $hello = Qt::PushButton("Hello World!", undef);
4: $hello->resize(160, 25);
5: $a->setMainWidget($hello);
6: $hello->show;
7: exit $a->exec;
This program first loads the Qt interface [line 1] and creates the application
object, passing it a reference to the command line arguments array @ARGV
[l.2].
This application object is unique, and may later be accessed from
anywhere through the Qt::app() pointer.
At line 3, we create a PushButton, which has no parent (i.e : it won't be contained nor owned by another widget). Therefore, we pass to the constructor an undef value for the parent argument, which is PerlQt's way of passing a Null pointer.
After some layouting at [l.4], we tell the application object that our main widget is this PushButton [l.5]... that way, it will know that closing the window associated with this widget means : quit the application.
Now the last steps are to make this widget visible (as opposed to hidden, which is the default) by calling the show method on it [l.6] and to start the application loop [l.7].
Syntax elements summary :
You don't need to say new Qt::Foo or Qt::Foo->new() as most Perl
programmers would have expected.
Instead, you just say :
my $object = Qt::<classname>(arg_1, ..., arg_n);
If you don't need to pass any argument to the constructor, simply say :
my $object = Qt::<classname>;
Pointers are arguments preceded by an *
character in Qt's documentation (e.g: ``QWidget * widget'').
Before we can discuss how Perl subroutines can be called back from Qt, we need to introduce PerlQt's inheritance mechanism.
PerlQt was designed to couple as tightly as possible Qt's simplicity and Perl's power and flexibility.
In order to achieve that goal, the classical Object Oriented Perl paradigm had to be extended, much in the same way than Qt itself had to extend C++'s paradigm with metaobjects.
Lets rewrite the ``Hello World!'' program, this time using a custom version of PushButton:
1: use strict;
2:
3: package Button;
4: use Qt;
5: use Qt::isa qw(Qt::PushButton);
6:
7: sub NEW
8: {
9: shift->SUPER::NEW(@_[0..2]);
10: resize(130, 40);
11: }
12:
13: 1;
14:
15: package main;
16:
17: use Qt;
18: use Button;
19:
20: my $a = Qt::Application(\@ARGV);
21: my $w = Button("Hello World!", undef);
22: $a->setMainWidget($w);
23: $w->show;
24: exit $a->exec;
Here, we want to create our own version of the PushButton widget. Therefore, we create a new package for it [l.3] and import Qt [l.4].
We now want to declare our widget as subclassing PushButton.
This is done through the use of the Qt::isa pragma [l.5], which accepts a
list of one or more parent Qt classes.
It is now time to create a constructor for our new widget. This is done by creating a subroutine called NEW (note the capitalized form, which differentate it from the usual ``new'' constructor. PerlQt's NEW constructor is called implicitly as can be seen on line 21).
Since we want our widget to call its parent's constructor first, we call the superclass's constructor (here: Qt::PushButton) on line 9, passing it all arguments we received.
At this time, a class instance has been created and stored into a special
object holder named this (not $this but really just this).
Each time you invoke a method from within your package, you may now
indifferently say method() or this->method();
When building a new composite widget, you may just create its different parts inside my variables, since widgets are only deleted by their parents and not necessarily when their container goes out of scope.
In other words, PerlQt performs clever reference counting to prevent indesirable deletion of objects.
Now, you'll often want to keep an access to those parts from anywhere inside your package. For this purpose, you may use the this object's blessed hash, as is usual in Perl, but that isn't really convenient and you don't have any compile time checking...
Here come Attributes. Attributes are data holders where you can store any kind of properties for your object.
Declaring new attributes is done through the use Qt::attributes pragma, as is
demonstrated in the following package implementation :
1: use strict;
2:
3: package Button;
4: use Qt;
5: use Qt::isa qw(Qt::PushButton);
6: use Qt::attributes qw(
7: itsTime
8: pData
9: );
10:
11: sub NEW
12: {
13: shift->SUPER::NEW(@_[0..2]);
14: itsTime = Qt::Time;
15: itsTime->start;
16: pData = " Foo ";
17: }
18:
19: sub resizeEvent
20: {
21: setText( "w: ". width() ." h: ". height() .
22: "\nt: ". itsTime->elapsed . pData );
23: }
24:
25: 1;
An attribute itsTime is declared at line 7, and loaded with a Qt::Time object
at line 14.
Since we reimplement the virtual function ``resizeEvent'' [l.19]. each time the main widget is resized, this function will be triggered and our Button's text updated with values coming from the object [l.21] and from the attributes we defined [l.22].
Recapitulation
use Qt::isa pragma.
e.g:
use Qt::isa "Qt::widget";
my $o = MyButton->NEW("Hello");
But say :
my $o = MyButton("Hello");
When a member function is called, arguments are loaded as usual in the @_ array, but without the object pointer itself.
Hence, you shouldn't say :
sub myMember
{
my $self = shift;
my $arg = shift;
$arg->doThat($self);
$self->doIt;
}
But :
sub myMember
{
my $arg = shift;
$arg->doThat(this);
doIt;
}
Furthermore, if you want to call a base class method from a derived class, you'd use the specal attribute SUPER :
sub example
{
print "Now calling the base class\n";
SUPER->example(@_)
}
Note that the :
this->SUPER::Example(@_);
construct is also available, but will pass the object as first argument.
use Qt::attributes qw(
firstAttribute
...
lastAttribute);
and then use it as a convenient accessor :
firstAttribute = myContainedWidget( this ); firstAttribute->resize( 100, 100 );
We'll now learn how Qt objects can communicate with each other, allowing an event occuring, for instance, in a given widget to trigger the execution of one or several subroutines anywhere inside your program.
Most other toolkits use callbacks for that purpose, but Qt has a much more powerful and flexible mechanism called Signals and Slots.
Signals and slots are used for communication between objects.
This can be thought off as something similar to the wiring between several Hi-fI components : an amplificator, for instance, has a set of output signals, wich are emitted wether a listening device is connected to them or not. Also, a tape recorder deck can start to record when it receives a signal wired to it's input slot, and it doesn't need to know that this signal is also received by a CD recorder device, or listened through headphones.
A Qt component behaves just like that. It has several output Signals and several input Slots - and each signal can be connected to an unlimited number of listening slots of the same type, wether they are inside or outside the component.
The general syntax of this connection process is either :
Qt::Object::connect( sender, SIGNAL 'mysignal(arg_type)', receiver, SLOT 'myslot(arg_type)');
or
myObject->connect( sender, SIGNAL 'mysignal(arg_type)', SLOT 'myslot(arg_type)');
This mechanism can be extended at will by the declaration of custom Signals and
Slots, through the use Qt::signals and use Qt::slots pragma.
Each declared slot will call the corresponding subroutine in your object, each declared signal can be raised through the emit keyword.
As an example, lets rewrite again our Button package :
1: use strict;
2:
3: package Button;
4: use Qt;
5: use Qt::isa qw(Qt::PushButton);
6: use Qt::attributes qw(itsTime);
7: use Qt::slots
8: wasClicked => [],
9: change => ['int', 'int'];
10: use Qt::signals
11: changeIt => ['int', 'int'];
12:
13: sub NEW
14: {
15: shift->SUPER::NEW(@_[0..2]);
16: itsTime = Qt::Time;
17: itsTime->start;
18: this->connect(this, SIGNAL 'clicked()', SLOT 'wasClicked()');
19: this->connect(this, SIGNAL 'changeIt(int,int)', SLOT 'change(int,int)');
20: }
21:
22: sub wasClicked
23: {
24: my $w = width();
25: my $h = height();
26: setText( "w: $w h: $h\nt: ". itsTime->elapsed );
27: emit changeIt($w, $h);
28: }
29:
30: sub change
31: {
32: my ($w, $h) = @_;
33: print STDERR "w: $w h: $h \n";
34: }
35:
36: 1;
In this package, we define two extra slots and one extra signal.
We know from the Qt Documentation that a clicked PushButton emits a clicked()
signal, so we connect it to our new slot at line 18.
We also connect our signal changeIt to our own change slot- which is
quite stupid, but as an example.
Now, whenever our Button is clicked, the clicked() signal is raised and
triggers the wasClicked() slot. wasClicked then proceeds to emit
the changeIt(int,int) signal [l.27], hence triggering the change(int,int)
slot with two arguments.
As efficient and intuitive as Qt can be, building a complete GUI from scratch is often a tedious task.
Hopefully, Qt comes with a very sophisticated GUI Builder named Qt Designer, which is close to a complete integrated development environment. It features Project management, drag'n drop GUI building, a complete object browser, graphical interconnection of signals and slots, and much much more.
Qt Designer's output is XML which can be parsed by several command line tools, among whose is puic (the PerlQt User Interface Compiler).
Assuming you have already built an interface file with the Designer, translating it to a PerlQt program is simply a matter of issuing one command :
puic -x -o program.pl program.ui
This will generate the package defined in your ui file and a basic main package for testing purposes.
You may prefer :
puic -o package.pm program.ui
This will only generate the package, which can then be used by a separate program.
If you need to embed images or icons, it can be done in two ways :
puic -o Collection.pm -embed unique_identifier image-1 ... image-n
Then add a use Collection.pm statement to your program's main package.
If you've created a project file in Qt Designer, and added all images you want to group (through ``Project->Image Collection''), you'll find all those images inside the directory where your project file (*.pro) is stored, under /images. You can then generate the corresponding image collection by issuing :
puic -o Collection.pm -embed identifier ../images/*
You can use as many image collections as you want in a program. Simply add a use statement for each collection.
It will often happen that you need to regenerate your user interface -either because you changed your initial design, or you want to extend it. Thus writing your program's code straight in the auto-generated Perl file is quite a bad idea. You'd run constantly the risk of overwriting your handcrafted code, or end up doing lot of copy-paste.
Instead, you may :
Keeping all the defaults, it should look like this :
void Form1::newSlot()
{
}
The slot declaration is actually C++ code, but simply ignore it and write your Perl code straight between the two braces, paying special attention to indent it at least by one space.
void Form1::newSlot()
{
print STDERR "Hello world from Form1::newSlot();
if(this->foo())
{
# do something
}
}
All Perl code written this way will be saved to the ui.h file, and puic will take care of placing it back in the final program.
Here, after running puic on the Form1.ui file, you'd have:
sub newSlot
{
print STDERR "Hello world from Form1::newSlot();
if(this->foo())
{
# do something
}
}
You'd typically generate the derived module once, and write any handcrafted code in this child. Then, whenever you need to modify your GUI module, simply regenerate the parent module, and your child will inherit those changes.
To generate the base module :
puic -o Form1.pm form1.ui
(do this as often as needed, never edit by hand)
To generate the child :
puic -o Form2.pm -subimpl Form2 form1.ui
or
puic -o program.pl -x -subimpl Form2 form1.ui
(do this once and work on the resulting file)
PerlQt-3 is (c) 2002 Ashley Winters
Kalyptus and the Smoke generation engine are (c) David Faure and Richard Dale
Puic is (c) TrollTech AS., Phil Thompson and Germain Garand,
The mentioned software is released under the GNU Public Licence v.2 or later.
Whenever you want to use a class/method described in Qt's documentation from PerlQt, you need to follow some simple translation rules.
Qt::Bar::Foo( arg-1,...,arg-n);
The only notable exceptions concern global functions :
qApp() will map to Qt::app() qVersion() will map to Qt::version()
$widget->show;
There are no fundamental differences between methods and signals, however PerlQt provides the emit keyword as a convenient mnemonic, so that it is clear you are emitting a signal :
emit $button->clicked;
Thus for a constructor prototype written as follow in the documentation :
QSize ( int w, int h )
You'd say :
Qt::Size(8, 12);
$keyseq = Qt::keySequence( &Qt::CTRL + &Qt::F3 ); $widget->setAccel( $keyseq );
or
$widget->setAccel(Qt::keySequence( &Qt::CTRL + &Qt::F3 );
If the argument isn't qualified as const (constant), it means the passed object may be altered during the process - you must then provide a variable.
Similarly, if the argument isn't const, the passed object may be altered by the method call.
A C++ example would be :
enum Strange { Apple, Orange, Lemon }
where Strange is the generic enumeration name, and Apple, Orange,
Lemon its possible values, which are only aliases for numbers (here 0, 1
and 2).
Access to enumerations values in Perl Qt is very similar to a static function call. In fact, it is a static function call.
Therefore, since you probably want to avoid some readability problems, we
recommend the use of the alternate function call syntax : &function.
Lets now go back to our Strange example.
If its definition was encountered in the class QFruits, you'd write from
PerlQt :
$apple_plus_orange = &Qt::Fruit::Apple + &Qt::Fruit::Orange;
PerlQt handles internationalization by always converting QString back to utf8 in Perl.
Conversions from Perl strings to QStrings are made according to context :
This is the most convenient and seemless way of internationalizing your application. Typically, one would just enable
the use of utf8 in source code with the use utf8 pragma and write its application with an utf8 aware editor.
Once a string contains utf8, you can convert it back to any locale by setting up converters :
$tr1=Qt::TextCodec::codecForLocale(); # this one will use current locale
$tr2=Qt::TextCodec::codecForName("KOI8-R"); # that one forces a specific locale (Russian)
print $tr1->fromUnicode(Qt::DateTime::currentDateTime()->toString)."\n\n"; print $tr2->fromUnicode($my_utf8_string);
Or, with Perl >= 5.8.0, you may use Perl's Encode modules (see perldoc Encode).
The Qt::debug module offers various debugging channels/features.
You may enable or disable it scope-wise :
use Qt::debug;
<...>
{
no Qt::debug;
<...>
}
<...>
use Qt::debug qw|calls autoload verbose|;
<...>
With the simple use Qt::debug statement, the verbose and ambiguous channels are activated.
If you specify a list of channels within the use statement, then only the specified channels will be enabled.
Available channels :
Together with ambiguous, tell you the nearest matches in case a method or function call fails. e.g:
use Qt;
use Qt::debug;
$a= Qt::Application(\@ARGV);
$a->libraryPath("foo");
--- No method to call for :
QApplication::libraryPath('foo')
Closer candidates are :
static void QApplication::addLibraryPath(const QString&)
static QStringList QApplication::libraryPaths()
static void QApplication::removeLibraryPath(const QString&)
static void QApplication::setLibraryPaths(const QStringList&)
A marshaller is a piece of ``glue code'' translating a given datatype to another.
Within PerlQt, most Qt objects keep their object nature, so that one may invoke methods on them. However, some classes and datatypes map so naturally to some Perl types that keeping their object nature would would feel unnatural and clumsy.
For instance, instead of returning a Qt::StringList object, which would require an iterator to retrieve its content, PerlQt will translate it to an array reference containing all the object's strings.
In the other way, instead of providing a Qt::StringList object as an argument of a method, one would simply provide the reference to an array of Perl strings.
Here is the list of Marshallers as of PerlQt-3.004 :
----------------------------------------------------------------- float, double <=> Perl real (NV) char, uchar, int, uint, enum long, ulong, short, ushort <=> Perl integer (IV) QString, -&, -* => Perl string (utf8) QString, -&, -* <= Perl string (utf8 or iso-latin1 or locale) QCString, -&, -* <=> Perl string (utf8 or bytes, according to content) QStringList, -&, -* => Reference to an array of Perl strings (utf8) QString, -&, -* => Perl string (utf8 or iso-latin1 or locale) int&, -* <=> Perl integer (IV) bool&, -* <=> Perl boolean char* <=> Perl string (bytes) char** <= Reference to an array of Perl strings (bytes) uchar* <= Perl string (bytes) QRgb* <= Reference to an array of Perl integers (IV) QCOORD* <= Reference to an array of Perl integers (IV) void* <=> Reference to a Perl integer (IV) QValueList<int>, - *, - & <=> Reference to an array of Perl integers (IV) (QUObject*)