The PerlQt project is pleased to announce today the first public release of PerlQt 3, a full-featured object-oriented Perl interface to the Qt3 toolkit.

Key features include

support for nearly all Qt classes through SMOKE, a language-neutral binding library brought to you by Ashley Winters and David Faure (and Richard Dale's kalyptus), unlimited slots and signals, virtual function overloading, and Rapid Application Development (RAD) through puic, a Qt Designer compatible user interface compiler. Here is a screenshot of some PerlQt applications. There is also a tutorial available to help you get started. Enjoy!

Smoke is a wrapper around Qt (later: KDE), which sort of indexes everything in Qt. All classes, all methods, with all arguments, etc. are put into cross-referencing arrays (for fast lookups). So smokeqt is a meta-definition of qt, where one can 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 performance.

At the moment it's only used by PerlQt, but feel free to look into it for developing your next generation language bindings ;)

Note: most of the design of Smoke is from Ashley Winters, the PerlQt guy.
I only helped generating the arrays, hacking kalyptus for that. So... in case of further questions on smoke, better ask on the kde-perl@kde.org mailing-list (which is where the PerlQt development happens).

David is right on the money. In fact, Smoke contains two different types of information.

First, it has a wrapper around every function in every class -- ala. SIP for PyQt. Static languages (Java, C#, etc) can use that part of PerlQt just like they would use SIP.

In addition to that, SMOKE contains meta-information... a sort of reflective introspection of the Qt library allowing queries of what functions are available and their arguments and return-types. The PerlQt binding takes full advantage of that information by providing do-what-I-mean function calling and automagic type coercion and multimethod dispatch. It also helps me make up nonsensical buzzwords to make me look smart.

Scripting languages can take advantage of that added information to provide neato stuff. Neato stuff is the best.

In conclusion (my writing teacher loves when I use that), SMOKE is the best thing since libc. Thank you. Please send your checks to me, since I'm homeless and can't work on PerlQt except to respond to e-mails from the local library. Feel free to Cc me on your Smoke questions to the PerlQt mailing-list if you're patient enough to wait a week for my response. Sadly, my Yahoo account would croak if I subscribed to the PerlQt mailing-list but only checked it once a week.

Sorry to dump it all on you Germain, but you've done a great job. Congratulations!

Wow! Looks like you guys have done some *amazing* work with SMOKE and PerlQt. Congratulations!

Regarding the usefullness of smoke for the C# bindings... I'm not sure this is the way to go. We are in the midst of a major refactor of Qt# with the goal to replace libqtc altogether. We've written a custom parser in C# that takes the Qt headers and outputs an xml representation of them. We will then feed this xml into our generator. We are going to replace libqtc with libqtsharp which will contain all the constructors for the QObjects and then we'll call libqt directly by mangling our function names. The idea is to reduce our dependencies and tailor our glue code to meet the specific needs of the CLR.

SMOKE basically provides a stack of arguments and a way to locate and call easily a given method by name and munged prototype.
It's mainly enormous arrays holding all characteristics of methods and pointers to the corresponding interface. Methods are looked up by binary search (hence the programmer must implement some caching...SMOKE does not do everything).

The main advantage of this strategy is you don't have to rely on manually tweaked interface files, which are the bane of others bindings.

As for Richard, I really have no idea... he was working with us some monthes ago, and then suddenly disappeared... I've sent some mails to him but never had an answer :-/

Hurm. Python libraries for Qt and KDE would be much appreciated. Right now, it takes me about 12 hours to compile them (via the sip library), but much more importantly, not only have I never gotten PyKDE working right. In addition, from browsing mailing lists, many people have to disable core parts of the library to get it to compile. I also have never gotten any binary installs to work, and from reading about it, it appears that the libraries may be somehow minor version specific (!!).

Disclaimer: I tilt at the libraries every couple months. I just subscribed to the PyKDE mailing list to make a serious run at getting everything working. My current problem is that calls don't seem to line up between what KDE provides and what sip generates. Odd.

(Incidently, I have an urge to poke at Smoke now and see if I can get it to create a Zend library just to write a couple dozen KDE apps in PHP to tweak the people on the dot who say PHP is just a web scripting language)

Heh. I'm talking about when I compile PyKDE - the autogenerated .cpp files are making KDE calls that don't exist or are malformed. Nor am I alone (although this particular problem seems to be unreported).

I'm somewhat familiar with Python (not an expert, but I've written a few programs and I know the language passibly well). I haven't gotten to the point of even compiling the PyKDE libraries, running into problems in kdecorecmodule.

I'm not sure, but I'm fairly certain that's a key module I can't just skip (a la what most people seem to suggest on the mailing list when the compile hits a problem). I'm probably going to have to edit the code, but there's something not right in editing autogenerated stubs - I need to see what's generating those incorrect entries.

I am not alone in having this sort of error in compilation (the sip generated code not aligning to the Qt API), but this problems with the wrapper for this particular call hasn't appeared on the list (or anywhere else via Google). The problem of one of the wrappers having this error has been reported, however, and the usual recommendation seems to be to just skip that module. Since this is a core module, I cannot do that.

Again, I'm not slamming this project. I've only tried on SuSE 7.3 and 8.0, and maybe SuSE has directories or library locations different than those that sip assumes. Or maybe sip is borked. Or maybe it's my fault somehow. It's just a fairly common problem according to what I've read, so my only observation is that the compilation process (which, as a side note, does not use autoconf but rather a python script) could be a bit more robust. YMMV.

The end result looks great - it's just a little rough to get it installed in my experience. My monitor died yesterday, so I haven't done anything with it today - maybe I'll have it running in the next twenty minutes :).

What can I say, PyQt has worked for me for a very long time. I've only just recently (in the last couple of weeks) looked into PyKDE, and it worked out of the box too. Perhaps you're not using the latest Qt or KDE? There are always going to be some minor-version incompatibilities - some library developers out there seem to have no problem with changing APIs between minor versions...

And it certainly didn't take _12_ hours to compile on my relatively low-powered Pentium-II 350 .. what are you using, a 386???

:: And it certainly didn't take _12_ hours to compile on my relatively low-powered Pentium-II 350 .. what are you using, a 386???

A dual 700 PIII. And it certainly took me 12 hours of elapsed clock time - but only several hours (maybe 4 to 5) actual compile time. I kicked off the build.py, waited several minutes, realized that takes a long time, came back an hour later, kicked off make, came back an hour later, did make install as root, etc, etc. Then I hit PyKDE, and it didn't work. Okay, start from scratch... repeat. Yeah - the actual compiles took a long time, but the compile process involved quite a bit of "waiting on user", and "user sighing, deleting directories, untarring, trying again" and "user downloading source rpms and trying those". :)

Again, I'm not slamming the project (although by the antagonistic tone here, I feel like I'm having to defend the fact that it didn't work for me). I'm sure it buttered your toast - it just didn't compile out of the tarball on a pretty vanilla SuSE install for me. Cest la vie.

I thought it was designed to be independant of the scripting language on one side and the language of the library on the other side, so that you could create bindings for all kinds of things. One example being Qt to python bindings. Aren't other combinations possible?

Yes, but then you're creating a language that makes calls to a toolkit library. .NET is more like Java, in that it targets a virtual machine, which waaay back in the day we'd call it "like P-Code": a binary file that is executed by an interpreter. .NET and Java can call Qt, since it's a toolkit library (assuming that the VM supports API extensions a la libraries, which they, like all modern VMs, both do).

A .NET binary should run on any machine, but has the overhead hit of being abstracted from the system, with the expected performance and features issues. Java forged the way, so those issues have been minimized, but still exist. A Qt/whatever application can run on any supported platform if you have the right compiler or interpreter, a KDE/whatever application works the same, but you need the kdelibs. It's lower level, and the binary isn't portable, since it's targeted to that platform.

(To *really* confuse things, Java is both a VM and a language, and the language can be compiled and targeted to a platform, resulting in executable code not needing the VM.)

--
Evan (who just woke up, needs to run out the door, and may have said something stupid without rereading. Correct at will, just be gentle. :) )

Wonderful job on the packaging. Downloaded it. Followed the instructions (33 minute compile on a P3 700 with 256). Copy/paste code from the tutorial - came right up. I'm excited to have some free time to work on some perl applications.

This would be fantastic for x-platform if it worked on Win32. I suppose the only issue is, will smoke build on win32 since the other components already exist. Any thoughts? Is it worth pursuing a port?

Hi,
to me, the main issue is : PerlQt and Smoke are GPL, Qt-win free edition isn't...
Maybe we can add a license exception for Qt-win free, if it does build...
Otherwise, there is still the Cygwin solution. Should work.

Following is a note that I sent to Germain. I'm not familiar with the protocol for this group so I'm also posting it here in the event that his is more appropriate than direct mail.

Hello Germain,

First, let me thank you very much for picking up the work on PerlQt. I had
used it several years ago for a number of applications and loved it. Now I am
looking at it again and pleased to see that it is still alive and going
strong.

qt built successfully but I had problems with PerlQt. A comment from you at:http://dot.kde.org/1032279318 dated 17 Sept 2002 indicates that kalyptus
can't parse Qt-3.1b1 yet. Although I am using 3.1.0, and not the beta
release, your comment may still be applicable. That may explain the problem
but let me ask it anyway since two months have passed and perhaps that
situation has changed.

The configure command for PerlQt dies with the following messages appearing
at the end of the output to the terminal:

Is this because I am using qt 3.1.0? If so, when do you expect to support
that version of qt? I am unable to find a previous version of qt at the
trolltech website and so I'm pretty much stuck with this.

The actual error is :
"generateVirtualMethod: QDnsSocket: No method found for
QDnsSocket::className() const"

The config.status error about not finding smoke/Makefile.in arises because
generate.pl fails and a "cd ../.." following it in the configure script is
not executed thus causing the script to be executing in an unexpected
directory. The return from generate.pl should probably be tested in a more
robust manner.