[Kde-bindings] PerlQt is getting old

[Richard Dale]

On Tuesday 07 June 2005 05:15, Ashley Winters wrote:
> PerlQt-3 is nearing the end of its lifecycle. It's not so much dead as
> it is mature. It works fine for what we want it for, and we're done
> fiddling with it. Here's why:
>
> 1. Qt-3.x is ending. In 2 years, Qt3 will be obsolete. Qt4 will require
> a rewrite of your Perl code in any event, and the signal/slot
> metaobject system for Qt4 is very different. We can't just change a few
> lines and have it work with Qt4.
Well I've got Qt 4 hello world working with QtRuby:

http://www.kdedevelopers.org/node/view/1123

It didn't actually need much code change, and I think the qt_metacall() method 
will work very well with Smoke.

> 2. Perl5 is showing its age. Soon, Perl5 won't be a first-choice
> language for new programs. Now that Perl6 is under active development,
> it seems realistic to predict seeing it deployed in production around
> 2008-2010. Currently, I prefer Ruby for writing Qt apps.
Well, QtRuby was all possible because of PerlQt - thanks to you and Germain 
for that great design and implementation.

> 3. Qt4 is a compelling platform for binding development. It'll provide
> GPLed cross-platform support for Unix/Win32/OSX. It has a rich
> metaobject system, and it's cleanly divided up into small(er)
> constituent libraries.
>
> 4. There is no room for a Qt-only language binding anymore. The KDE
> project needs to provide coverage for Qt and its own libraries in all
> languages. This is not something which can be shoved off to the side;
> KDE needs to pull this in front-and-center. IMO, one goal for KDE4's
> build system should be to auto-generate the bindings for every library
> in every KDE4 application. Out of the box.
>
> 5. Smoke may be obsolete as well. Looking at the Qt4 metaobject system,
> we may be better off sharing the metaobject calling convention of Qt4.
It looks to me as though qt_metacall() is closer to the way the args are on 
the Smoke::Stack than Qt 3.

> Every function in every class could be made a Qt4 slot (using a shadow
> class of some sort). We could implement virtual function overrides by
> overriding every virtual function and having it emit itself. We could
> pretend in a hand-wavey sense that overriding a virtual function is
> actually a specialized version of connect(). We could optimize the
> common case (like smoke does now -- if nobody overrides the method,
> just call it directly). That way, you could completely automate the
> Qt/KDE libraries by interfacing with the meta-calling system.
Interesting.. I suppose in C++ you look up method based on its C++ type 
signature, wheras in Smoke we use your munged method name scheme, with #, ?, 
or $ for each arg type. It would be nice to define slots and signals in terms 
of ruby types, so the programmer wouldn't have to see anything like 'const 
QString&' or whatever. 

> I really need to whip out a flowcharting program to diagram this up
> with some slides... if I do, I'll stick it on a blog somewhere for
> y'all.
Yes, that sounds good..

-- Richard