english

FAQ

Questions générales

D'où vient PerlQt ? Existe-t-il depuis longtemps ?
Oh oui ! Pour citer son père spirituel, Ashley Winters (novembre 2002) : "Le sixième anniversaire de PerlQt est pour le mois prochain -- C'est le 26 décembre 1996 en effet que les assauts conjugués de mon orgueil et des fières annonces d'Arnt Gulbrandsen à propos du concours de programmation organisé par sa 'toute nouvelle' boite à outils de composants graphiques m'entraînèrent sur la pente fatale de PerlQt."
Qu'est-ce que Smoke ? Pourquoi est-ce nécessaire ?
SMOKE est une fine surcouche logicielle se greffant sur Qt (et bientôt KDE).
Il a été conçu par Ashley Winters dans le but de maximiser le partage des ressources que tout type de binding doit nécessairement implémenter.
Non seulement il fournit un enrobage de toutes les fonctions, mais il contient aussi des méta-informations permettant de s'enquérir du nom exact des fonctions disponibles, de leur valeur de retour, de chacun de leurs arguments - à la manière de CORBA, finalement.
Toutes les méthodes, toutes les classes et arguments, de même que leur caractère statique ou virtuel, etc. sont stockés dans des tableaux croisés permettant une recherche rapide. On peut donc lire( et invoquer) l'ensemble de l'API Qt simplement en consultant quelques tables.
Son principal objet est de faciliter la création de nouveau bindings pour les langages de haut niveau - en mettant l'accent sur la flexibilité.
Bon, mais j'ai entendu dire que Smoke faisait partie de KDE. KDE est donc requis ?
Non, pas du tout. PerlQt contient sa propre copie de Smoke, qu'il construira au besoin. Si KDE est présent, son arborescence sera utilisée lors de l'installation de puic et Smoke ira rejoindre les autres bibliothèques partagées de KDE.
Sinon, on utilisera la valeur de l'option --prefix ou, à défaut, l'un des chemins standards (/usr/local par exemple).
Les liens logiciels sont généralement fragiles, sujets aux erreurs de segmentation et cessent souvent de fonctionner entre deux versions mineures des logiciels qu'ils assemblent. Qu'en est-il de PerlQt/Smoke ?
Comme Smoke reflète uniquement l'interface publique de Qt, il restera toujours compatible jusqu'à la version majeure suivante (c'est-à-dire vraisemblablement plusieurs années).
Quant à PerlQt, qui se trouve au carrefour de deux mondes très différents, il restera naturellement plus sensibile au changement, mais comme il est de très petite taille, sa recompilation éventuelle est l'affaire de quelques minutes.
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).
Mais pourquoi devrais-je utiliser PerlQt, au fait ? A-t-il un avantage décisif sur les autres solutions GUI ?
Il en a même beaucoup,mais tout dépend de vos besoins...
Si vous recherchez la solution la plus portable, PerlQt ne vous conviendra peut-être pas : il nous a été rapporté qu'il compilait correctement sur plusieurs variétés d'Unix, dont Solaris et Mac OS X (Fink); mais la compilation sous Windows reste inexplorée.
Cela dit, c'est bien son seul désavantage : non seulement la souplesse, la puissance et le design élégant de Qt, qui ont fait sa renommée, se traduisent très naturellement dans PerlQt - mais il est de plus pourvu d'un environnement de développement rapide complet(RAD).
L'association de Qt Designer et de Puic (le compilateur d'interfaces PerlQt) permet de construire une application en l'espace de quelques minutes, littéralement.
PerlQt est notemment précieux pour la construction de prototypes, en ce que tout effort engagé dans la construction d'une GUI via le Designer est immédiatement réutilisable en C++, attendu que le format XML des fichiers du Designer est unique.
Les physiciens et les chercheurs apprécient de pouvoir construire rapidement des applications internes et recyclables pour traiter signaux et données, d'autres aimeront la rigueur du modèle orienté objet qu'il apporte à Perl (grâce à l'emploi de this, des attributs et des slots/signaux), d'autres enfin aiment simplement la qualité des widgets fournis par Qt et la facilité avec laquelle on peut dériver de nouveaux objets : chacun voit midi à sa porte !

Problèmes particuliers

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



L'association d'une image de chameau au langage de programmation Perl est une marque déposée d'O'Reilly & Associates, Inc.
Le logo de Qt(TM) est une marque déposée de Trolltech (TM) AS, Norvège.