Public Release of PerlQt 3.002 including RAD support

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!

Dot Categories: 

Comments

by Navindra Umanee (not verified)

All I've got to say is *wow* this is absolutely terrific. People have been waiting for a long time for PerlQt 3, and now it comes out with RAD support. Congratulations to the new PerlQt team!

This is also the first I've heard of SMOKE. How does it work? Is it like the libqtc library or something?

Any word on what Richard Dale is up to these days?

by Richard Moore (not verified)

I'd be interested in more info on Smoke as well. I'm going to releasing new (much improved) version of KJSEmbed soon and this could be used to make it even more powerful.

Rich.

by David Faure (not verified)

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 [email protected] mailing-list (which is where the PerlQt development happens).

by Ashley Winters (not verified)

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.

Anyways, Nice Work: Ashley, David, Everyone

Adam Treat

by germain (not verified)

Hello Navindra,
thanks for your kind words :)

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 :-/

G.

by Evan "JabberWok... (not verified)

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)

--
Evan

by Anonymous (not verified)

My current problem is that calls don't seem to line up between what KDE provides and what sip generates. Odd.

Maybe you missed a few spaces. Also check for tabs. Mixing them with spaces is lethal in Python!

by Evan "JabberWok... (not verified)

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.

--
Evan

by Richard (not verified)

"Nor am I alone (although this particular problem seems to be unreported)."

... so is the problem reported, or not?

by Evan "JabberWok... (not verified)

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 :).

--
Evan

by Richard (not verified)

Idiot.

by Marc Schmitt (not verified)

Hi,

I'm packing sip/PyQt/PyKDE for SuSE Linux. I've also provided some .src.rpm
on sourceforge. ( http://sourceforge.net/project/showfiles.php?group_id=61057 ). Try to download the .src.rpms and compile them and bombard me with any questions that arise (English or German, what you prefer).
Also, feel free to post on the mailinglist at [email protected] for any in-depth-questions.

:)

-Marc

by Richard (not verified)

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???

by Evan "JabberWok... (not verified)

:: Perhaps you're not using the latest Qt or KDE?

3.0.5 and 3.0.3. SuSE's RPMs.

:: 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.

--
Evan

by Anonymous (not verified)

That's awsome! Scroll to the end of the tutorial for the wonderful camel/QT logo ;)

by Marc (not verified)

Is SMOKE an answer to .NET's multi laguage capabilities?

Marc

by Adam Treat (not verified)

In a word no. They are completely different beasts. SMOKE allows the binding developer an easier method of creating bindings for Qt/KDE. .Net is a development platform.

by Marc (not verified)

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?

Marc

by Evan "JabberWok... (not verified)

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. :) )

by germain (not verified)

Just thought I'd drop a note for the most "bleeding edge" of you that already use Qt-3.1b1 from CVS:
kalyptus can't parse it correctly yet, so you'll have to wait a bit or use a stock Qt.

G.

by Otter (not verified)

I get it -- Perl + uic -- and maybe it's a pun that works in another language. But, I can tell you that in English that's a pretty distasteful sounding name!

Terrific project, though. Thanks to everyone who was involved!!

by anon (not verified)

The difference is that uic is pronounced "you-eye-see", not "uke".

by GUI (not verified)

Could please have a screenshot of your "RAD". Is RAD stands for Rapid Advanced Development Environment. I guess it is not RAD Environment, it is just UI support. Don't be carried to much.

by germain (not verified)

It seems you are confusing IDE (integrated development environment) and
RAD (Rapid Application Development.)

Anyway, courtesy of Qt Designer, it's kind of both :

perlqt.png

Cheers,
G.

by Paul Seamons (not verified)

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.

Only question is... is PerlKDE on the way?

by Olivier (not verified)

Been waiting for that to happen for quite sometime now. I'm thrilled. I'll be on it in as soon as I am home !

by ritchie (not verified)

What's the status of the ruby bindings. Can they use SMOKE too?

Thanks

Ritchie

by Phil (not verified)

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?

by Germain Garand (not verified)

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.

G.

by Bill Wetzel (not verified)

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.

I downloaded:

PerlQt-3.002.tar.gz

as well as:

qt-x11-free-3.1.0.tar.bz2

and am running under:

RedHat 7.2
Linux officeroom 2.4.9-13 #1 Tue Oct 30 20:11:04 EST 2001 i686 unknown

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:

Generating bindings for smoke language...
Starting writeDoc for qt...
Preparsing...
Skipping union QPDevCmdParam
Writing smokedata.cpp...
ArgList isn't a known type (type=ArgList)
Cardinal isn't a known type (type=Cardinal)
Item isn't a known type (type=Item)
QEventLoop::ProcessEventsFlags isn't a known type
(type=QEventLoop::ProcessEventsFlags)
QPixmap) protected: QPixmap( int isn't a known type (type=QPixmap) protected:
QPixmap( int)
QPtrCollection::Item isn't a known type (type=QPtrCollection::Item)
QtStaticMetaObjectFunction isn't a known type
(type=QtStaticMetaObjectFunction)
Widget isn't a known type (type=Widget)
WidgetClass isn't a known type (type=WidgetClass)
WordWrap isn't a known type (type=WordWrap)
XtAppContext isn't a known type (type=XtAppContext)
XtPointer isn't a known type (type=XtPointer)
bool (* qt_static_property)(QObject* , int, int, QVariant* ) isn't a known
type (type=bool (* qt_static_property)(QObject* , int, int, QVariant* ))
Writing x_*.cpp...
generateVirtualMethod: QDnsSocket: No method found for
QDnsSocket::className() const
config.status: creating smoke/Makefile
config.status: error: cannot find input file: smoke/Makefile.in

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.

Thanks,
Bill Wetzel