[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bindings
Subject:    [Kde-bindings] PerlQt is getting old
From:       Ashley Winters <jahqueel () yahoo ! com>
Date:       2005-06-07 3:15:58
Message-ID: 20050607031558.67187.qmail () web50906 ! mail ! yahoo ! com
[Download RAW message or body]

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.

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.

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

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.

Ashley Winters



		
__________________________________ 
Discover Yahoo! 
Find restaurants, movies, travel and more fun for the weekend. Check it out! 
http://discover.yahoo.com/weekend.html 

_______________________________________________
Kde-bindings mailing list
Kde-bindings@kde.org
https://mail.kde.org/mailman/listinfo/kde-bindings
[prev in list] [next in list] [prev in thread] [next in thread]