C Mania: KDE 3 Offers C Bindings

Richard Dale recently pleasantly surprised me (and probably others) by announcing that he has committed C bindings for the KDE3/Qt3 libraries to KDE's CVS. Richard generated the C bindings automatically using a hacked kdoc, with relatively little manual intervention. According to him, "The bindings wrap about 800 classes [and] 13,000 methods, with 200k [lines of code] of C/C++ generated." The same hacked kdoc can also generate Objective C and Java bindings, and Richard hopes to be able to consolidate generation of these various KDE bindings (Java/Objective C/C) with this one tool. Currently the C bindings for KDE 3 and Qt 3 are in KDE's CVS, with bindings for KDE 2.2.x/Qt 2.3.x awaiting resolution of a dynamic linking/PIC problem which affects the Objective C bindings (please contact Richard if you are knowledgeable in this area).

Dot Categories: 

Comments

by David golden (not verified)

Chances are the site is being actively astroturfed my microsoft weenies - not necessarily under the official control of MS, but also by lots of VB "programmers" and so on whose livelihood depends on the perpetuation of shoddy MS "solutions". You may scoff at such paranoid allegations - but I remember trolling of OS/2 newsgroups, which was eventually linked back to MS employees apparently acting under orders from their employers.

If you browse at +1, it's still bearable, if you browse at +2, you'll probably miss stuff that's been modded down by wrong-headed moderators.

by Jeremy (not verified)

they need to have a 20 question test, they need to be tested on all the moderations and if they can not mod the post correctly (acording to taco) then they should not moderate.

by Jos (not verified)

I just did a test on slashdot story search:
Microsoft: 1530 stories
RMS: 0 stories!
Gnome: 386 stories
Qt: 0 stories
Trolltech: 26 stories (which contain the word Qt)
KDE: 0 stories

I guess
- their search can't handle small words,
- or (put conspiracy theory here)

by Squink (not verified)

Wow, always up to date Java Bindings! I could see it becoming difficult for Sun to resist bundling KDE with Solaris.

by cylab (not verified)

i dont think, that sun will support the bindings. remember that this kind of stuff created serious trouble with microsoft. suns idea of java is of a platform, dales idea of java is of a language. so dont expect sun to be happy!

by Richard Dale (not verified)

Microsoft tried to change the Java language in incompatible ways such as adding delegates, and they only selectively implemented features of the Java platform, while still wanting to pass it off as standard Java.

The Qt/KDE Java bindings are not claiming to be an implementation of the Java platform. They are use standard JNI + Java foundation classes. Sun has no problem with Apple's Cocoa Java api for Mac OS X, and the KDE Java bindings are in the same category of software as that.

I read an article recently about the reasons why Sun chose Gnome, and Java wasn't mentioned once. I'm surprised they're not doing more Gnome/Java/Swing integration work, or helping with GTK+ Java bindings.

-- Richard

by Marcelo (not verified)

It is cool to have Java bindings, specially when it needed almost no "big" developer effort to do so...

But I really would prefer if more effort was put into QtAWT (http://developer.kde.org/language-bindings/java/qtawt/developer.html), making it ready (including Swing!).

That way, we can have the best of both words: our Java applications will be more integrated into KDE, and we won't loose the portability. Also, it'd be one less library to load in memory (the JVM uses Motif).

by Richard Dale (not verified)

'It is cool to have Java bindings, specially when it needed almost no "big" developer effort to do so...'

I'm not 14, and I didn't knock these bindings up in a couple of weekends. It did involve "big" developer effort - some 15 months in total for C/Objective-C/Java including about 9 months solid for the Java bindings. I needed to work as a contractor on a trading system for a large bank for 3 years to fund this.

-- Richard

by Karl Günter Wünsch (not verified)

I think he meant the "alway up to date" bit of the interface. I don't doubt this will make the big difference in the long run. GTK and GNOME have language bindings that involve manual creation of the apropiate class interfaces for any object orientated language and that might be it's downfall because the binding is tracking a (fast at times) moving target. With an automated build process as you describe the bindings can be kept up to date without too much manual interference so they are usable at any time compared to bindings against GTK/GNOME that require a manual update (and then sticking to the basis of that update for all that it binds to).

Contgratulations for the great contribution...
regards
Karl Günter Wünsch

by Jérôme Loisel (not verified)

"I needed to work as a contractor on a trading system for a large bank for 3 years to fund this."

You mean you stopped working to get the utility and the bindings? That's terrible! Do you believe your tool and bindings will help you make up for that? For example, can you envision some commercial release for the tool?

One question about bindings. Would it be possible/feasible to add generation of Python bindings? PyQt seems to be coming along, but PyKDE never made it to KDE 2.X. So that is definitely a problem for me.

Thanks for your hard work.

by Richard Dale (not verified)

"You mean you stopped working to get the utility and the bindings? That's terrible! Do you believe your tool and bindings will help you make up for that?"

Yes I hope so! I don't intend to make money out of the bindings directly, only
out of providing services such as wrapping existing C++ widgets for Java JNI, and Qt/KDE Java consultancy services if it catches on.

I had originally intended to take a rest from contracting at banks for 6 months, and just 'test the water' with open source contributions. I did an Objective-C support patch for KDevelop, and Sandy Meir put up on the KDevelop site (I found that great fun!). I submitted a few KDevelop fixes as patches.

But the UK government introduced a nasty tax law called 'IR35' attacking freelance contractors. We are no longer allowed to fund software development from doing consultancy work such as contracting at a bank. Hence, I thought this was my last chance... and went for it fulltime from March 1999 onwards.

PyQt and PyKDe are being actively maintained by the Kompany, along with help from third parties. I believe they have a version of Qt 3 designer for python in the works for use in conjunction with the BlackAdder IDE, and PyKDE 2.x bindings have been recently announced.

Shawn Gordan and the Kompany are doing a great job in packaging the PyQt bindings with the BlackAdder IDE. Indeed, I emailed to him saying how nice it would be to do the same thing for the Qt/KDE Java bindings, and got a positive response (they were already thinking about it). It just needs a company like that to get behind the Java bindings in the same way, to make it happen. There are contractual issues to be negotiated with Trolltech when Qt language bindings are used for commercial development.

So BlackAdder or KDevelop 3.0 with the Java/Python/Ruby Qt/KDE bindings, and Qt 3 Designer Java support, will be a very nice combination. I hope experts on that subject should make as much money as people working on trading systems...

-- Richard

by Richard Dale (not verified)

"...fulltime from March 1999 onwards.."

Correction - March 2000 onwards, So 18 months in total of anti-IR35 tax protest.

-- Richard

by Christian Lavoie (not verified)

It's too easy to forget how much effort is put into everything.

I doubt it was meant as lessening your efforts, but rather as praising them: It's too darn easy to have up-to-date Java bindings now, thanx to you. You describe an automated procedure that sounds too good to be true.

Thanx to you, we now have one of the very last interoperability issues dealt with.

Thanx.

by Marcelo (not verified)

>It's too darn easy to have up-to-date Java bindings now,
>thanx to you. You describe an automated procedure that
> sounds too good to be true.

Yeah, that was supposed to be the way I phrased the original post. Sorry for any misunderstanding. :-)

by kdeFan (not verified)

I don't suppose anyone is working on scheme bindings? afaik, gnome has guile and there's always tk, but I'm a kde diehard and I've recently found programming bliss in the world of scheme. Of course, if I could compile python I might be persuaded to settle for that ;) Anyway, I'm just wondering...

by chakie (not verified)

Python bindings are being worked on. See http://www.thekompany.com/projects/pykde/. The page does say that KDE2 bindings are not available, but they are being worked on too, and AFAIK are quite close to being released.

by Jos (not verified)

Together with QDesigner this can unleash a great power.

Well, serious, scripting and Qt wil give nice RAD tools. Just don't integrate all bindings into KHTML and KMail....

by Jeremy (not verified)

well, first we need to have a stable VB interpreter that is compatable with MS VB, for the most part.

by xav (not verified)

Hey, there are some other python bindings with KDE/QT in sourceforge CVS. They are purposedly tiny (in needed memory size) and I expect them to stay this way. They may become quite useful, though. Give it a try if you wish, though my HD has some slightly more recent ones.
The project is named PYK and is hosted by sourceforge. Drop me a line here if you have any comment !

by xav (not verified)

to the original poster you absolutely don't need to compile pyhton to write a binary binding for it ! all you need to do is to compile a shared library.

by Jörgen S (not verified)

The binding generator seems to be a nice hack. However, I have some oppinions about the generated code.

1) Why are C-style casts used in the C++ code? (The bridging code). Why not use reinterpret_cast<> when casting from a C++-type (class) to a C-type (struct)? IIRC Bjarne Stroustrup wrote in some book that for the sake of potential memory alignment problems, cast operators should be used rather than the C-style cast. Although I know he was talking about down casts of virtual classes and objects, but nevertheless, can you really assume that (Type*)expr is the same as reinterpret_cast(expr) on all platforms/compilers?

2) The first argument to all methods is the instance pointer to the actual object. How about calling the parameter "This" or "Self" instead of "instPointer"? Yes, I know, it doesn't really matter to the user of the library, but "This" looks nicer than "instPointer". (And I think its more intuitive when reading the headers, but maybe thats because I'm coming from the C++ world)

3) How about making all wrapper functions inline? The way I see it, the wrappers are only thin thin functions which just passes parameters and return values from and to the real C++ object. An inlined function would do the same trick, with little memory overhead and quite a lot in terms of speed. Since most operations within the functions are casts, I'm sure the compiler will strip away quite a lot of code, resulting in a "clean C++ call". I know this sounds silly since inlines are in header files and are processed during compile time (gcc will have a hard time at cracking C++ code in C-mode!), but isn't there an "extern inline" modifier which allows one to separate implementation from specification? Maybe that was a gcc-specific hack or maybe I just had a wet dream one night.. ;)

Other than that, this seems to be really nice C-binding! Perhaps now it would be easier to port legacy Motif apps to KDE w/o the expense of making everything C++ correct.

My 0.02 SEK

by Guillaume Laurent (not verified)

3) How about making all wrapper functions inline?

You answered this one yourself :
because...
> gcc will have a hard time at cracking C++ code in C-mode!

> but isn't there an "extern inline" modifier which allows one to separate implementation from specification?

Then it wouldn't be inline anymore, would it ? :-)

by Jörgen S (not verified)

> > but isn't there an "extern inline" modifier which allows one to separate implementation from specification?

> Then it wouldn't be inline anymore, would it ? :-)

Well not necessarily. It's not inline text wise, so the compiler would not be able to expand the function during the first pass. But the linker could do some magic to the function itself and expand it where it is called.

From http://www.gnu.org/software/libc/CONFORMANCE :
"glibc's use of extern inline conflicts with C99: in C99, extern inline
means that an external definition is generated as well as possibly an
inline definition, but in GCC it means that no external definition is
generated. When GCC's C99 mode implements C99 inline semantics, this
will break the uses of extern inline in glibc's headers."

It looks like there is support for extern inline in C99. However, I am not sure if it is possible to

header.h: extern inline T1 func(T2);
and
impl.cpp: T1 func(T2 param) { ... }

and get away with it. Does anyone know if it is possible to separate the implementation and specification of an "extern inline" function? If not, 3) is not a good suggestion :-)

by Bernd Gehrmann (not verified)

No, the linker can't do magic. It (well, as the name
implies ;-) "links" object code. Any inlining and
optimization is done in the compiler on the level
of an intermediate representation of the code.

'extern' in C99 is something completely different.
It specifies that an inline function can be inlined,
but *in addition*, a "real" instance of the code has
to be emitted by the compiler. In order to inline
a function, of course the compiler must have access
to its implementation.

by John Schultz (not verified)

Sorry, but linkers most certainly can (and should) inline fcn calls at link time. Read this: [Stale Link Removed]

by Richard Dale (not verified)

1) Um, I'm afraid I don't know. My C++ knowledge stops at the 1992 vintage ARM. I'm not a C++ fan (that's why I spend my time implementing bindings for languages I like better). I like to keep my C++ as simple as possible.

2) Yes, I agree. The starting point for these C bindings was Roberto Alsina's QtC bindings that he did in 1997 with a python based generator. I changed the source code generator to perl/kdoc, but kept the generated code exactly the same including the 'instPointer' name. It's never been important enough to change.

3) Code bloat is a problem with inline functions, and the shared libs are already too large. No point in tuning without measuring though, and I doubt if the function calling overhead matters much.

The best way to port legacy Motif apps is to re-write the front end in KDE, I wouldn't recommend using the C wrappers for programming in C.

-- Richard

by JoeyJoeJoe (not verified)

C Wrapper functions should not be inlined so as to seperate the interface from the implementation. Also, you want the user to be able to compile with a C compiler - not necessarily a C++ compiler. That THE point of having a C API, afterall. On your first point, about C++ style casts - they won't work for older C++ compilers that are still in widespread use - I, for one, still use a 5 year old C++ compiler at work. Nevermind the fact that reinterpret_cast<> generates a lot of runtime code that a normal C-style cast (or a static_cast for that matter) would not. When the cast is KNOWN to be safe implicity you should never use reinterpret_cast.

by Bernd Gehrmann (not verified)

reinterpret_cast should not generate runtime code at all. After all,
it's just a type reinterpretation in the compiler frontend. What
you probably mean is dynamic_cast, which implies a test whether its
argument is an instance of a certain class.

by KDE User (not verified)

Where is the documentation and example C code to make any kind of use of this? Richard or Dre, please make more details available on the web!

by Richard Dale (not verified)

Yes, you're quite right! I haven't actually written any C programs with the bindings, as I only use them in conjunction with Objective-C. I wouldn't expect anyone to code directly in C, they are more intended to be a way of implementing bindings for languages which can't call C++ directly - eg PHP, Pascal, some Objective-C. I did have an email exchange once with a guy who had written a Qt C program, and we did get it working. I'll try and find it and post it here.

-- Richard

by Richard Dale (not verified)

Here is a QtC code sample from Dimi Shahbaz:

-- Richard

#include

#include
#include
#include
#include
#include
#include
#include
#include
#include
#include

qt_QApplication *app;
qt_QWidget *qw;
qt_QPushButton *qb;
qt_QLabel *ql;
qt_QObject *qo;

int eventd(void *send, char *signal, void *recv, char *slot){
  printf("qb %d qw %d app %d\n", (int)qb, (int)qw, (int)app);
  printf("sender %d signal %s receiver %d slot %s\n", (int)send,
signal, (int)recv, slot);
  return 0;
}

int main(int argc, char **argv){
  int ret;

  app = qt_new_QApplication(argc, argv);
  qt_QObject_registerEventDelegate(eventd);

  qw = qt_new_QWidget(0, "qw", 0);
  qt_QApplication_setMainWidget(app, qw);
  qt_QWidget_showNormal( qw);

  qb = qt_new_QPushButton1( qt_new_QString5("Testing"), qw, "qb");
  qt_QPushButton_setGeometry(qb, 10, 10, 60, 60);
  qt_QWidget_showNormal( (qt_QWidget *) qb);

  ql = qt_new_QLabel1( qt_new_QString5("Label"), qw, "ql", 0);
  qt_QWidget_setGeometry( (qt_QWidget *) ql, 70, 70, 60, 20);
  qt_QWidget_showNormal( (qt_QWidget *) ql);

  ret = qt_QApplication_exec(app);
  printf("ret %d\n", ret);

  return ret;

}

by Roberto Alsina (not verified)

Oh, THAT is why I never wrote a real signal/slot glue for QtC ;-)

by Richard Dale (not verified)

Hi Roberto

Thanks for helping to start all of this...

The C bindings, like your original QtC bindings, only have signals for the primitive C++ types - double, int, float, char *, etc. That is because I think the signal handling should done in the library at the level above, like the Objective-C bindings library.

-- Richard

by Roberto Alsina (not verified)

Yes, I know. It is just that when I read the example code, I remembered that it is pretty much impossible to write a useful implementation of signal/slots that is not also incredibly ugly to write code for :-)

Yes, I agree, it is better if signals/slots are handled in a language that can express it nicely, such as Obj-C and such.

Every time someone writes about Qt/KDE there is this
whining "you have no bindings ,but GTK has.....".
Now we have Java/Objective C/C, Python (soon KDE2)
and Ruby(Only Qt? or KDE too). And I heard something
of PerlQt a while back. More??

Can someone make a page dedicated to the bindings,
like: http://erik.bagfors.nu/gnome/languages.html
But nicer looking of course :-)

I think this is an exelent idea.

by Bernd Gehrmann (not verified)

Well, there isn't a myriad of separately maintained KDE libraries,
so there is no point in making matrices about what is supported and
what not.

Of course, there is a page dedicated to language bindings on
developer.kde.org. If you have any improvements to make, patches
are certainly welcome :-)

by R. A. Rivas Diaz (not verified)

If there any plans to generate java bindings using the new CNI interface to GCJ?
IMHO CNI is by far a supperior design compared to JNI, and has more in common with QT/KDE dessign (C++ API) than JNI, which is a C API.

Rivas.

by Richard Dale (not verified)

Yes, Thomas Kuhn is doing some great work on this. He has converted the bindings to use CNI calls for the event handling and slot callbacks, but left the Java native methods still using JNI. CNI is more efficient that JNI, but I don't think anyone using the bindings would notice the difference, even if you converted all the calls to CNI.

One main advantage of using gcj, is that you can use gdb to debug instead of the toy jdb. gcj/CNI is Great Stuff, and I hope the combination of gcj/gdb/gnu tools/KDE Java bindings might be good enough to start to pull people off C++...

-- Richard

by J. J. Ramsey (not verified)

Would the C bindings to Qt do anything for or to binary compatibility across compilers?

by Roberto Alsina (not verified)

Actually, yes. A QtC/KDEc program would use a stable ABI accross compilers.
Of course your QtC/KDEc needs to be compiled with the same compiler as your Qt/kdelibs, but that should be no problem, since now they should come with the package in future versions.

by Jimmy Wennlund (not verified)

I Think the realy important thing is to port KIO-engine to C so programs like xmms can open smb:/ , http:/ and audiocd:/ like a normal kde-program does. Can't it be implanted in the C-library so every program uses it? It feels unnessesary that every desktop-system needs a complete IO-engine.

Sorry foks, for my realy bad english!

//Jimmy

by Carbon (not verified)

That is a very good idea, actually. KIO is one of the coolest examples of KDE integration : just by using the standard KDE file dialogs and using the provided classes for i/o, you suddenly have tranpsarent access from every app to every supported resource. I.e., it must have taken about 10 minutes to make kwrite the default html source viewer, since it just has kio open up an http connection to whatever file it wants. I think that Charles or Neil even looked at making it a kernel module at some point, though IIRC that didn't pan out very well :-)

Question : would it be possible/advantageous to make KIO accessible as a daemon, so that you could fairly easily code an app to ither use KIO if it's there or use standard i/o if it's not, without a lot of messy compiler checking?

by Jimmy Wennlund (not verified)

I Think the realy important thing is to port KIO-engine to C so programs like xmms can open smb:/ , http:/ and audiocd:/ like a normal kde-program does. Can't it be implanted in the C-library so every program uses it? It feels unnessesary that every desktop-system needs a complete IO-engine.

Sorry foks, for my realy bad english!

//Jimmy

by Roberto Alsina (not verified)

That is already in this very thingie!
I am guessing, but I bet all the kio love is already into KDEc (Richard, how do you capitalize the name of the KDE binding?)

by Richard Dale (not verified)

Several of the kio classes are wrapped for C. But they tend to use quite fancy signals, and those aren't currently implemented (the signal handling is Roberto's original code). So we must try harder! On the other hand, I don't think we are that far off - it depends if people want to use the C bindings directly or not. I'd only thought of calling them via other language bindings, so the C runtime is pretty minimal as per the original QtC.

-- Richard

by Roberto Alsina (not verified)

Well, making the signal stuff handle more types is just a matter of doing it.
I suggest the previous poster (not you, Richard ;-) should take a look. It is pretty much mechanical work! Any C programmer can write it!

Note: C programmer. Which Richard and I ain't ;-)

by Stof (not verified)

Does this mean I don't have to wait 2 minutes to compile a C++ file that #include ? ;-)
(no I'm not kidding about the 2 minutes: Pentium 233)
And will this enable better coorporation with GNOME?
A Bonobo/XParts bridge would be cool.

by Carbon (not verified)

Uh, no, that really doesn't have anything to do with what you're talking about, afaics.
It won't make C++ files compile faster, because it doesn't have much to do with C++ compilation. It just allows some other languages to use Qt and KDE classes and services.

I think you mean KParts, not XParts. And, integration between the two would require a component library wrapper, or a universal component framework, not just a language binding. If GNOME used this, it would make KDE libraries a dependancy for compiling GNOME, which would be just insane.

Hmmm, for KParts integration though, there is a link farther down that mentions a universal component framework. You might want to take a look at that.

by Evandro (not verified)

FYI, Bonobo 2 is not GNOME-dependent. The ui stuff that requires GNOME is in a seperate package now.