Qyoto C#/Mono Bindings for Qt4, New QtRuby release and PHP Bindings Coming Soon

After the recent final release of QtJambi, Trolltech's Java bindings, I'm pleased to announce another new member of the Qt bindings family, the Qyoto C#/Mono bindings for Qt 4.3, which are available for download on the Qyoto/Kimono site, where there is also a help forum for your Qyoto programming questions. Big thanks to David Canar for setting up the site, and organizing the release. Read on for more details.

Additionally, I've just released QtRuby 1.4.9 on the Korundum Rubyforge site with many improvements. Meanwhile Thomas Moenicke is working on another binding using the Smoke library - PHP-Qt - see last week's Commit-Digest for details. What with these bindings, and all the action with Kross scripting of KDE apps and Plasma (and PyQt/PyKDE of course), these are exciting times for fans of non-C++ languages in KDE!

Arno Rehn and myself have given a presentation and demo of Qyoto at aKademy 2007. We will show how you can quickly build user interfaces with Qt Designer/uics, easily communicate with other applications via the QtDBus framework, and how other CLR languages, such as IronPython, work with Qyoto.

Qyoto includes very complete coverage of the Qt classes, and optionally the QScintilla text editing framework, along with the 'uics' tool for compiling Qt Designer .ui files to C#, and 'csrcc' a resource compiler based on Qt's rcc. The code is based on QtRuby, which in turn was derived from PerlQt, and it uses the same language independent Smoke library as those bindings. That should mean that Qyoto will be quite solid and mature for a first release.

Now for a brief summary of how the Qt language features look in Qyoto. You define slots by marking methods in your class like this:

[Q_SLOT]
public void MySlot(int arg) {
...

Signals are defined in an interface associated with the class, with the signatures being marked with a 'Q_SIGNAL' attribute:

public interface IMyButtonSignals : IQPushButtonSignals {
[Q_SIGNAL]
void Clicked(bool arg);

To emit a signal you, use a special property called 'Emit' like this:

Emit.Clicked(true);

Note that Qyoto signals are typesafe and can be checked by the compiler because they must conform to the type signatures defined in your signals interface. Qt properties are mapped directly on C# properties, and so instead of setting the text of a button with a setText() method call:

mybutton.setText("Hello World!");

You set a 'Text' property like this:

mybutton.Text = "Hello World!";

If you wish properties to appear in the QMetaObject data for your class, so that you can export them over DBus perhaps, you can mark them like this:

[Q_PROPERTY]
public string Text {
...

Connecting a signal to a slot is very similar to C++:

Connect(quit, SIGNAL("clicked()"), app, SLOT("quit()"));

But note the quotes round the signal/slot signatures.

Well that pretty much sums up the differences - the api is so similar to the C++ api that very little explanation should be needed. Although Qyoto has its own distinctive personality with method names beginning with capital letters and much use of getting/setting properties, the code examples should be very easy to follow, and getting up to speed straightforward for those familiar with Qt. The MonoDevelop IDE works well with Qyoto, and there is a MonoDevelop project file 'Qyoto.mpb' provided, which is a very useful way to browse the classes in the api.

Happy C#/Mono hacking with Qyoto!

Dot Categories: 

Comments

by T. J. Brumfield (not verified)

Thanks for the response. I appreciate that you read what I wrote and didn't immediately jump to conclusions.

I believe I poorly worded my post in an effort to seem diplomatic. Honestly, a "merging" of the two worlds if it did occur would likely mean really just largely an open adoption of QT. Given that benchmarks showed the same apps running of the supposed "bloat" of KDE 3 ran faster and used less memory than on Gnome/GTK 2, and considering the improvements in QT (I'm particularly interested to see real world performance with the multi-threading improvements), is there any good reason not to push for open adoption of QT 4?

Again, the three hurdles you'd likely run into are:

1). Some people like the way GTK looks, but this is a misconception. QT can look like GTK if you wanted it to, and GTK doesn't really have a look of it's own per se, given that it can be themed to look different ways really.

2). I prefer C over C++, but again with the varied language bindings, and the new scripting platforms, language shouldn't be a barrier anymore. You should be able to develop around QT with the various bindings in your language of choice as I understand it.

3). It is too much work. Well, this is subjective, and I'm not the one coding, but I would volunteer to test, log bugs, write documents, do web pages, whatever I would be capable of. Again, I know some C and C++, but really I'd just get in the way of myself. I'm a horrid coder. However, I do personally believe the benefits are significant, and not just in performance increase, or letting the other guys utilize the new KDE-niftyness, but being able to develop for one toolkit and know that everyone can use your app.

I think I'm going to try this again as a different, smaller suggestion.

When KDE 4 launches (or a pretty usable RC launches) I'd like to see someone throw together a LiveCD or a decent proof-of-concept that you could take Clearlooks, and get KDE to look and operate at a basic level like a Gnome desktop. Then utilize that proof-of-concept to demonstrate comparable performance with the existing Gnome desktop, and also demonstrate the advantages of the new technology.

A tangible proof-of-concept should be enough to initiate a discussion of whether or not there is any worth in discussing such a project.

by anonymous (not verified)

Look. Seems all you are suggesting is that GNOME adopt Qt if the Trolls make a slightly reworked version that gives standard GTK dialogs for like the file dialog... then:

1. You've written a lot of hot air for such a simple proposal. GNOME adopts Qt... that is what you are suggesting??

2. Please go very quickly over to #gnome or on the GNOME mailinglist and give your brilliant proposal. I'm sure they will be amazed they'd never thought of this before and will quickly see the wisdom of your gentle counsel.

me <-- ROTFLMAO

by T. J. Brumfield (not verified)

You seemed to suggest that if an existing implementation exists that you like, you use it. This makes sense.

However, it seems like some of the new stuff in KDE 4 is so universally useful, that perhaps it should have been pushed into a more neutral domain such as directly into Xorg, or into a shared FreeDesktop.org project.

For instance, people do mix and match GTK and QT apps in both desktops.

When looking at things like Strigi, metadata, NEPOMUK, etc. that it increases in usefulness if every app is on the same page? How aware will these be of data models from GTK apps?

by AC (not verified)

you fail to see the real problem. gtk and qt are different because they WANT to be different. they are build by developers who think different. they simply can not agree on something as big as a main library like a gtk/qt merge would be, because they value things differently.

you want this library to be the jack of all trades, but thats just not possible. you have to make tradeoffs, and there are always people who value things differently.

so to summarize this thread: its simply not possible. that may be hard to understand if you are no developer your self, buts thats just how it is. try reading the kde core dev list a few months, and you will see how hard it can be to get a consensus even with mostly like-minded people.
the deveoper world is just like any other world, its impossible to get everybody to agree on something on a large scale - just look at world politics ;).

by fast penguin (not verified)

«Couldn't there be a universal library that is capable of operating in appearance and usability like both GTK and QT when it comes to widgets and visuals?»

Yep, instead of QStyle and GtkStyle, it would be great to have a common high-level drawing interface that would be then implemented by KDE/Qt and GTK+. It would also be great for other software (like OpenOffice) which resorts to some hacks to provide the same appearance of the desktop.

by Phil Thompson (not verified)

May I suggest a concise, but polite, criticism of the proposal...

http://www.bobcongdon.net/blog/2004/06/boil-ocean.html

Phil

by Jonathan Morgan (not verified)

I don't think that this has been mentioned, but licensing is potentially an issue here. From memory, Gtk+/GNOME use the LGPL, whereas Qt Free Edition uses the (viral) GPL. I would agree with the other posters that the technical difficulties of this approach are unlikely to be overcome. However, even if they were, those developers currently using the LGPL Gnome code may not wish to switch to using a Gnome like product built on the (GPL) Qt.

by Pau Garcia i Quiles (not verified)

Thank you for another great release of QtRuby! I hope we will see a lot of C# developers joining KDE development very soon.

by Plopp (not verified)

Stupid question, perhaps, but will any of the bindings be included by default with KDE 4.0? It would make writing in non-c++-languages more attractive, IMHO.

by Richard Dale (not verified)

The QtRuby/Korundum and Qyoto/Kimono bindings (and hopefully PyQt/PyKDE too), along with Kross runtimes for various languages, will be in the kdebindings module for KDE4. It is up to a Linux distributor to decide what they want to package from kdebindings though.