-21

There could be a C-binding for Qt/KDE.
Motivation: A lot of languages can link against C, so you could easier create bindings for other languages.

It should be for gcc only. (so you can use some fast features)

How to do it:
-Use Smoke\'s Introspection to generate code
-Use pointers instead of references
-Create a simple struct named bool and define true and false
-For classes implement the g++-layout as C-structs:
1. No inheritance

Code: Select all

struct QObject<br />{<br /> char privateByte1;<br /> char privateByte2;<br /> char privateByte3;<br />};

2. Single inheritance

Code: Select all

struct QMainWindow<br />{<br /> QWidget qwidget;<br /> char privateByte1;<br />};

3. Multiple inheritance

Code: Select all

struct QWidget<br />{<br /> QObject qobject;<br /> QPaintDevice qpaintdevice;<br />};

Virtual inheritance isn\'t used in Qt/KDE, but it would also be possible.
4. Something like dynamic-Cast:
For all classes needing this-pointer-adjustments create a this_cast-function, for example:

Code: Select all

extern "C++"<br />{<br /> void* this_cast_void(void* x);<br /> QPaintDevice* this_cast_QPaintDevice(QPaintDevice* x);<br />}<br />#define this_cast(to, value) this_cast_ ##to ((to*)value)<br />

The implementations could use the vtable to do the adjustments.
5. Put normal functions into \'extern "C++"\'.
6. Functions with reference-type-arguments maybe need a layer between C and the Qt/KDE-API. (I\'m not sure)
But there could be a simple dummy function dereferencing the pointers from C.
7. Element-Functions can be represented in this way:

Code: Select all

extern "C++"<br />{<br /> QString* name(const QObject*);<br />}

Implementation:

Code: Select all

QString* name(const QObject* <br />{<br /> return &o->name();<br />}

For non-references:

Code: Select all

extern "C++"<br />{<br /> int x(const QPoint*);<br />}

Implementation:

Code: Select all

int x(const QPoint* p)<br />{<br /> return p->x();<br />}

8. Rename overloaded operators.
9. Constructors
a) new-expression:

Code: Select all

extern "C++"<br />{<br /> QString* QString_new(const char*);<br />}

b) init-function (using operator=)
10. Destructors
Create a C++-function "free" for each type. Don\'t forget to use virtual-destructors.
11. Inheritance

Code: Select all

struct MyQWidget<br />{<br /> QWidget parent;<br /> int extraData;<br />}

12. Overwrite virtual-functions

Code: Select all

void keyReleaseEvent(MyQWidget* mqw, QKeyEvent* event)<br />{<br /> // do something)<br />}<br />void* vtable_MyQWidget = vtable_clone_QWidget();<br />// vtable_index_QWidget_keyReleaseEvent is a preprocessor-definition<br />overwrite_function(vtable_MyQWidget, vtable_index_QWidget_keyReleaseEvent, (void*)(void (*)(MyQWidget* mqw, QKeyEvent* event)));<br /><br />void init(MyQWidget* this)<br />{<br /> set_vtable(this, vtable);<br />}

Some macros could make this easier.

You could create new virtual functions in a similar way.
13. Signals and Slots
Create a Q_OBJECT-macro for C. The tables for signals and slots and the meta-calls could be implemented with some macros. (in C++ it\'s done by moc)


I think, that\'s it.

The User

Why don\'t you like it? Could you explain it, Mr. vote-down?

I\'m not Mr vote-down... yet (soon will be). Several reasons:

1. KDE is heavily oriented towards C++. There would be a significant effort required to generate and maintain C bindings for it and that wold probably involve a few design shifts / philosophical realignments. This might be acceptable if there were actually some *reason* to do it. There is not...

2. A lot of languages can link against C++, and have their own object systems that provide a relatively clean mapping to the existing C++ KDE API. Did you have a particular language in mind? One that is not already in the list at http://en.wikipedia.org/wiki/Qt_(toolkit)#Bindings

3. C is a poor choice of language for doing modern GUI based application development. No further debate will be entered into on this point. It is just a fact.

4. Your intro points tend to indicate you are naieve both of KDE/Qt and of coding in general (no offence intended - its just an observation). For example, Qt API design principles explicitly prefer pointers over references; if you did have to implement your own bool type you should do it as an enum.

Enough reasons... now my vote

@The User:
As andre already wrote, we already have plenty of high quality language bindings, so that would be a poor reason to write another one... Are there any other good reasons you can think of why this would be useful? Because if there aren\'t I think you must agree this is not really needed.

andre_orwell wrote:2. A lot of languages can link against C++

Wait... what? A lot of languages can link against simple procedural C APIs exported from C++. I know of no language that fully implements the C++ ABI and thus can link against it.

Anyway, while I don\'t see a lot of utility to a simple C binding (the binding generators already create their own C bridges), a GObject binding would be cool. Cool as in not necesserily useful but fun to experiment with.

There used to be a C binding until KDE 3.2 but nobody used it, therefore it was removed.

Qt3 C binding:
http://websvn.kde.org/branches/KDE/3.2/kdebindings/qtc

KDE3 C binding:
http://websvn.kde.org/branches/KDE/3.2/kdebindings/kdec

It was used as the base for the Objective C binding, too.

If you are interested in taking over it, drop by #qtruby and #kderuby at FreeNode, or the kdebindings mailing list. Richard Dale and Arno Rehn are the ones to ask for advice.

You wouldn\'t have to maintain it, because you can use Smoke for source-generation.

PS:
Bindings for Java, D and ObjectiveC would be possible. And also the C#-binding could be faster.

Bindings for D

QtD is a D binding to the Qt application and UI framework.

The FreePascal/Lazarus project has something similar, a C library that wraps the QT4 C++ code into procedural calls and which can then be linked from using ObjectPascal, this allows lazarus to offer QT4 as one of it\'s target widget sets.

That one is not complete though, it only wraps those calls which are needed for Lazarus\'s LCL metawidget set.

See here: http://users.telenet.be/Jan.Van.hijfte/ ... pcqt4.html

As far as I know they don\'t have plans to support KDE bindings at this stage, but it does show the merit of the poster\'s idea. If QT and KDE libs C wrappers were already available rather than having to be custom built, projects like these would be much more likely to support it. Lazarus is a nice example as it is used by a lot of people and companies to take old delphi projects and maintain them - often also porting them to GNU/Linux. At this stage though most of those GNU/Linux ports are using the GTK2 export, with a few starting to use the QT export.
Such a library would mean that with fairly little effort those projects could start offering native KDE versions as well, and I\'m quite convinced that there are many other similar projects that would gain the same kind of benefit. - So from my side, I\'m voting it up.

You mean that you haven\'t heard of the D programing language? Look it up at Wikipedia:

http://en.wikipedia.org/wiki/D_programming_language

This doesn\'t seem like a good idea. The C programing language is old, missing basic features, and not currently undergoing development. Inertia seems to be the major reason that it is still used. The same could probably be said of C++.

The major drawback to your idea is C\'s lack of features. Newer languages would have to give up a lot to link to KDE through a C interface. The two most popular modern languages undergoing current development are Java and FORTRAN (perhaps C# should be included). IIUC, we already have bindings for Java (and C#) so the logical choice is FORTRAN (95, 2003 or 2008). Perhaps this could server the same purpose since other languages can link to it as well. The advantage here would be that it would make it much easier to make a GUI based numerical program that needed to get the correct answers. C compilers, by definition, do not get the correct answers to math problems and C++ compilers based on them have the same issues.

At the end of the day it\'s simply a matter of would the development time involved doing this be worth the gain that you\'d get from having C programmers writing KDE apps.

Generally the answer seems to be \'no\'.

Any better solution for Java, D or Fortran bindings?
IIRC, the current C#-binding uses string-based function-calls - not very good.

All bindings except the Python ones use SMOKE already.
Putting another layer in between doesn\'t sound like a very viable choice.

I am not sure there is any value in stand alone C-Bindings either. Developers doing object oriented C programming should be able to use the Qt-style C++ API as well.

Cheers,
_

Jambi is of course good...

Smoke\'s string-based function calls are really bad for compiled languages.