[Kde-bindings] Default values?

[Richard Dale]

On Sunday 22 June 2008 04:31:51 Sohail Somani wrote:
> Hey,
>
> I'm part of the way through generating a C-API for Qt but am confused
> about Smoke and default values.
>
> The idea is that given the constructor:
>
> QLabel(QWidget* parent=0, Qt::WindowFlags f = 0);
>
> I would generate:
>
> q_label*
> q_label_0();
>
> q_label*
> q_label_1_widget(q_widget* parent);
>
> q_label*
> q_label_2_widget_window_flags(q_widget* parent, q_window_flags flags);
>
> This does not seem to be currently possible. For example, using rbqtapi,
> one sees the following constructors for QLabel:
>
> QLabel* QLabel::QLabel(QWidget*)
> QLabel* QLabel::QLabel(QWidget*, const char*)
> QLabel* QLabel::QLabel(QWidget*, const QString&, QWidget*)
> QLabel* QLabel::QLabel(QWidget*, const QString&, QWidget*, const char*)
> QLabel* QLabel::QLabel(QWidget*, const QString&, QWidget*, const char*,
>                         Qt::WFlags)
> QLabel* QLabel::QLabel(QWidget*, const char*, Qt::WFlags)
> QLabel* QLabel::QLabel(const QString&, QWidget*)
> QLabel* QLabel::QLabel(const QString&, QWidget*, const char*)
> QLabel* QLabel::QLabel(const QString&, QWidget*, const char*,
>                         Qt::WFlags)
>
> I would have expected QLabel::QLabel() to be one of these overloads.
The reason is that your version of rbqtapi is introspecting the Qt3 api, which 
didn't have a no arg QLabel constructor.

> The reason I am doing this is that I want to generate bindings for a
> language that has only a C interface and I wanted to do as much as
> possible in the language rather than in C++. I foresee the definitions
> of each C function to be quite straightforward.
>
> Does anyone know if a C-binding for Qt has been developed (or am I doing
> it totally wrong?)
I wrote on to implement Objective-C bindings and it was also used for an older 
version of C# Qt bindings called Qt#. However, I think the way smoke works is 
a lot better once you understand it. The C bindings lib used a very simple 
name mangling scheme - giving the methods numbers just like you propose 
above.

But Smoke is a dynamic runtime, and instead of statically linking against a 
library which has one C method for every C++ method in the lib you are 
wrapping, smoke allows you to look a method up. Having found the method you 
want to call, you marshall the arguments from your bindings target language 
to the 'smoke stack' which is language independent.

This is an example of a method call in the Qyoto C# bindings:

		public QLabel(QWidget parent) : this((Type) null) {
			CreateProxy();
			interceptor.Invoke("QLabel#", 
                           "QLabel(QWidget*)", 
                          typeof(void),
                          typeof(QWidget), parent);
		}

It calls 'interceptor.Invoke()' and passes it sufficient data for the method 
to be looked up in the smoke library. The "QLabel#" is a simple name mangling 
scheme where the types of the args to the method are classified as 
either '$', '#' or '?' and it helps dynamic languages find the method easier. 
The second arg is the C++ type signature of the method, which should be an 
exact match for the corresponding method in the smoke lib. The following 
arguments are the type of the return value and then pairs of type/values for 
each argument in the C# call.

-- Richard