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

List:       kde-perl
Subject:    [Kde-perl] Re: Smoke and PerlQt
From:       Ashley Winters <qaqortog () nwlink ! com>
Date:       2002-06-07 14:37:05
[Download RAW message or body]

On Friday 07 June 2002 03:44 am, you wrote:
> Hi there!
>
> I've been working with Adam Treat's Qt-CSharp package and discussing
> various things that need to be done. I asked how I could help out, and one
> of the items on the TODO list is to investigate the Smoke bindings to see
> if they might be a better choice for Qt-CSharp than the current model,
> which calls functions from qtc. Apparently Richard Dale told Adam that
> qtobjc might use Smoke in the future.
>
> I've gotten kdebindings from CVS and compiled smoke. I've seen that it
> creates a shared library, but I don't see the Perl bindings themselves.

PerlQt is on SourceForge at the moment.

cvs -d:pserver:anonymous@cvs.perlqt.sf.net:/cvsroot/perlqt co PerlQt-3

> I'd like to find out what Smoke does better than the old approach using
> qtc. And I'm wondering if these advantages are applicable to a language
> like C#, as opposed to a scripting language like Perl.

Smoke doesn't necessarily do anything "better". Smoke provides a focus for 
development (like SWIG does) so effort from various Qt bindings can be 
shared. Every binding to Qt has to override EVERY virtual function in EVERY 
class to provide widget extensions. Smoke already does that, and has a 
callback from every virtual method from which you can tell the class, method 
name, number of arguments, type of arguments, etc. Perl and scripting 
languages like it can take maximum advantage of that introspective ability, 
but C# and other compiled languages could just use the callbacks alone.

Besides providing pre-generated virtual method callbacks, Smoke can also 
change how methods are called. Implementing a Smoke method-calling interface 
in a language is like implementing a really small CORBA interface. The Qt 
functions would not be directly called; instead every method is called from 
the same function. Each method has a number, and it's the number which you 
use to call the method. However, it's an optional ability which you could 
skip.

Kalyptus, the tool used to generate the Smoke library itself, could also 
generate the C# source-code which would provide the stubs for calling every 
Qt method using the Smoke method-calling interface. I don't really know C# 
syntax, so I can't give any reasonable examples of the source-code Kalyptus 
would generate. However, it would be an almost exact port of the generated 
source-code for virtual methods. Just imagine having this (slightly doctored 
code, to remove an efficiency hack) generated (in C#, rather than C++) by 
Kalyptus:

    virtual void closeEvent(QCloseEvent* x1) {
        Smoke::StackItem x[2];
        x[1].s_class = (void*)x1;
        qt_Smoke->binding->callMethod(11660, (void*)this, x);
    }
    virtual bool cmd(int x1, QPainter* x2, QPDevCmdParam* x3) {
        Smoke::StackItem x[4];
        x[1].s_int = x1;
        x[2].s_class = (void*)x2;
        x[3].s_voidp = (void*)x3;
        qt_Smoke->binding->callMethod(6650, (void*)this, x);
	return (bool)x[0].s_bool;
    }

That's essentially Smoke calling into itself for the virtual method callbacks. 
As you can see, every method ends up being a call to callMethod(), with the 
first parameter being the "id" of the method, and the arguments being passed 
in a "Variant" array.

It's also possible to skip Smoke completely and have Kalyptus generate the 
whole interface for Qt-CSharp from scratch. There are several design options 
to choose from.

> I appreciate whatever guidance you can give about. Is there a forum for
> discussing Smoke?
>
> Thanks,
> Marcus

I Cc'd this message to perl-kde@mail.kde.org, which is as close as anything.

Ashley Winters

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