I just added features regarding the C# bindings to the 3.4 feature list. As 95% of the major work towards the new super spiffy Qt# bindings is done, I figured it was time to set some goals for getting all of this in shape for a KDE release. For those curious about the current state of my bindings (as opposed to the other C# bindings efforts) this kind of stuff is working now. For those confused by all the myriad twists and turns of the various C# bindings efforts here is a short history:
- The original C# bindings for Qt were initially created with the Kalyptus tool. Richard Dale helped me greatly when I first started out with this approach. After awhile the obfuscated perl code wore on me and I decided to create a C# generator.
- The first (and only) functional Qt# binding was created with this first generation C# generator that has no name. It generated the C# source by parsing a xml based metadata file that was created with... get ready... kalyptus. The code really, really bites. I'm embarrassed by it really. And to add insult to injury, the kalyptus extension that I wrote to output the xml has been lost entirely.
That is the current production state of things and has been for quite sometime. If you go to the Qt# webpage you'll find the fruits of this generator.
Now, shortly after getting Qt# in a usable state, I decided to move development out of KDE's cvs because of numerous complaints by users/developers who didn't want to deal with the kde cvs build system. I've tried to keep the two in sync with updates at various times, but that hasn't worked out to well. Now, in KDE's cvs you'll find a completely busted C# binding because the QtC library we were using has been removed. I've learned my lesson and will be moving development back to KDE's cvs as soon as practicable.
Ok, on with our story. It was apparent very soon that the first generation C# generator was horrible and would need a complete rewrite. That is when development on BINGE began. BINGE is the original second generation BINding GEnerator for Qt# that we began working on way back when. Unfortunately, right around the time when BINGE was becoming quite powerful and full featured, I was pulled away from development as a result of frustrations with: the various free CLI enviroments, the state of bindings in general, and the world going to &*&*# around me ie, the hell that is the Iraq war. So, I stopped working on the Qt# bindings completely.
With this, three things happened:
- Development on Binge stopped dead in the water just as it was becoming usable as I was the only one with good knowledge of the tool.
- Qt# bindings were maintained by Marcus who also began working on a second generation C# binding generator called Bugtussle.
- Eventually, Richard Dale took a new look at C# bindings with a new kalyptus generator that would employ SMOKE and realproxies. aka kimono.
Since that time, and until I took up working on BINGE again, development on Bugtussle has moved ahead while Richard's smoke based effort seems to have stopped, at least momentarily.
Which leaves us to the current status in this long winded and boring story. I believe BINGE is the most advanced second generation C# binding generator at this time. By quite a bit. Work on Bugtussle continues by Andreas Hausladen. He has a replacement for QtC in place, but no working C# bindings. Richard is using smoke for the intermediate library, but his C# sources are not in a usable form. BINGE is generating a replacement for QtC and generating an almost complete replacement for the original Qt# right now and I'm working on bindings for the recently released Qt4 beta as well as KDE bindings.
Sorry, if you read all that. The point is that the C# bindings are quite confused right now, but work continues and hopefully the combined best of all these efforts will emerge. Oh, and I plan on having initial C# language plugin for kdevelop by 3.4. Cheers.
PS For those who wish to play with the BINGE bindings to see where they are at... realize that it isn't for the feint of heart right now, and then go here. Although, cvs is moving quickly so that might be outdated too ;P
Syndicate Blogs
virtual methods sometime?
If I recall right from my keepit (# version) code, ... the real limitation I found with Qt# bindings by markus is that no methods were defined virtual. Therefore, there was no way to reimplement them. Is that still true? Any progress on this? Or am I wrong?
Limitation lifted
Have a look at the bingestyle.png linked in the main blog post. You'll see that we can now override c++ virtual methods to our heart's content
nice!
Thanks for the info. I had not seen the shot. At last Qt# will be useable then! Now somebody should find a replacement for (const) attributes in C#, and we can switch over to c# for kdelibs4
Architecture question regarding signals/slots
I understand the need for signals & slots in C++, but couldn't these be most naturally mapped to Events & Delegates in C# instead of continuing down the signal/slot (string only, no metadata) path? Or was this considered and it was just too much work?
I've written some QT# (not CVS, version 7) code just to familiarize myself with it and everything feels pretty natural in managed code with the exception of the signals/slots implementation.
I'll try and write up a summary
but, yes, it would be difficult to map c++ signals/slots to the c# delegate/event model transparently. Also, you should note that the signal/slots in the CVS version of Qt# are very much different. Essentially, they give you everything that delegates/events do (metadata, strongly typed) except they still use strings (although the syntax is greatly improved) and they don't give errors at compile time. Check this out for an example:
namespace QtSamples { using Qt; using System; public class EmitSample: QVBox { public EmitSample (): base () { QPushButton pb = new QPushButton ("Emit Sample", this); pb.SIGNAL["Clicked()"] += this.SIGNAL["EmitStuff()"]; this.SIGNAL["EmitStuff()"] += this.SLOT["PrintStuff()"]; } [SIGNAL] public void EmitStuff () { Emit("EmitStuff()"); } [SLOT] public void PrintStuff () { Console.WriteLine ("Emitted 'EmitStuff()'"); } public static void Main (string[] args) { QApplication app = new QApplication (args); EmitSample es = new EmitSample (); app.SetMainWidget (es); es.Show (); app.Exec (); } } }** Replace the \ chars with [ and ] and you get an idea. The pre and code tags are having problems with this syntax.
Re: I'll try and write up a summary
That looks nice, using += as an alias for QObject.Connect() - I assume you could still use Connect() if you prefer.
Are the SLOT and SIGNAL things above the methods, attributes, but he square brackets have got lost in the formatting?
The only thing I don't quite understand is that you've got an Emit() call inside the definition of the signal EmitStuff(). Is it possible to call Emit("EmitStuff()") anywhere?
One way to get round having slots/signals as strings is to declare the signal type signatures in an interface called 'EmitSampleSignals' for instance, and use proxies.
interface EmitSampleSignals { void EmitStuff(); } ... ((EmitSampleSignals) Emit()).EmitStuff();Emit() returns a proxy which handles the EmitSampleSignals interface, so you then cast to that interface.
Re: Update on the C# bindings
Sorry, if you read all that.
Hi Adam - no, no apology, it was a very good read - ie an excellent summary of the current state of affairs wrt to KDE C# bindings. I'd never even heard of Bugtussle. I've done enough work (ie about 2 months) on the Qt.NET/Kimono bindings to want to finish it off for the KDE 3.4 release, rather than abandon it.
So it's looks like the KDE project will be in the unfortunate position of having at least three viable C# bindings projects for the 3.4 release. What will we do? How will we cope
Awesome
That is great. I can't wait to see the smoke based bindings. The last time I looked (which was quite a bit ago admittedly) you were still hooking up the initial bits for a hello world. Hopefully, through all this attention we'll have some nice binding solutions for C# for the upcoming releases. And some kdevelop goodies for c# developers