JUL
19
2006

Gnome bindings discussions

I thought the discussion on the Gnome developer list about C vs C# vs Python etc for writing desktop apps was very interesting. A lot of it could equally well apply to the KDE project.

One comment caught my eye:

In a way, yes - if we didn't have the original GNOME desktop and libraries
written in C we could have had so many language bindings in the first place? How
many language bindings exist for KDE that didn't first have to present a C API
to enable the binding...

See here

The answer is that there are no KDE bindings that have to present a C api, and the ease of writing C vs C++ bindings for OO languages is something of a myth. Instead we a have a single autogenerated library 'Smoke' which can be used for Perl, Ruby, C#, PHP and others. In turn the Kimono C# binding will enable CLR languages such as Iron Python, Nermerle etc with no extra work.

Comments

i like the fact that KDE is rather lean in its dependencies. i remember what it took me to get some php-gtk and perl-gtk apps working in the past.

yet things are changing. and the most interesting changes i think are trolltech maintained Java bindings for Qt (anr probably our own KDE extension to them) and GCJ. i think this might even be a good option for some (parts of) KDE core apps.

personally i like ruby a lot, but i somehow presume that ruby KDE apps would bring a lot more overhead than GCJ compiled Java KDE executables. is this true?

Cies Breijs.


By cies at Wed, 07/19/2006 - 21:39

You can not compare apples with pears, as we say here in austria. You can compare Ruby with Python, C# with Java, C++ with Objective C. These languages have different use cases. You use Ruby and Python when there is no need for high performance. When there is a bigger need for performance you use Java/C# and if its even bigger C++/Obj.C. You use Python/Ruby when it is important to deliver a product very fast -> RAD. Python/Ruby are excelent as extensions/plugins (OOo, Amarok, KOffice, Blender, ...).

Ergo, there is need for ruby/python and java/c# bindings. Every language has its use case. You could argue what language is better only between python <-> ruby, java <-> c# etc. But I think KDE should not choose only one in that pairings, it should let the developer decide what to use. ;)


By Mathias Panzenböck at Wed, 07/19/2006 - 23:03

i totally agree with you post panzi...

but i was targetting a specific area, name core kde.

the same hold true for the GNOME discussion, its not about making some bindings so some ppl can use them for some purpose. no, its about letting (some of) your core depend on it, and therefore it becomes a core dependency and all apps the already depend on the core then can depend on it.

important is then that its very stable/ well maintained. if trolltech delivers the bindings we can be quite shure they're well maintained (on all platforms) without costing us a lot of efford.

concerning your point on comparing different types of fruits:
i think it important that we compare them any way, and im especially interested how much slower (startup time, running speed, mem usage) a qt app in java compiled to native code with gcj will be compared to a qt app in c++.

speaking of which: didn't trolltech promis qt-java bindings for Q1 of this year?


By cies at Wed, 07/19/2006 - 23:52

Yes, I thought panzi's post was spot on too. There's no such thing as the 'perfect programming language' and only people who haven't been programming for very long and haven't used many languages tend to think that way. They used to be COBOL programmers, and these days Java programmers with a year or two of experience, tend to fall into that category.

Important apps such as Amarok now have a dependency on Ruby, although not the Korundum bindings yet. As interfacing to web services becomes more important, it will become more and more important to be able to make use of dynamic languages like Ruby in KDE. C++ is good for some things, but for using dynamic web services or for an interface to a database like Rails ActiveRecord it is terrible.

At present I don't see any advantage in the current core KDE apps being written in non-C++ languages. I that will change with KDE 4 because the concept of a 'desktop' is rapidly becoming out of date. People will expect to throw together plasmoids in JavaScript, or use web services, or interface easily with VOIP or Jabber based services. The single user desktop from the early 80's makes no sense anymore, and imitating Microsoft's boring stuff makes no sense either. I think we can do something new, and great non-C++ development environments and bindings are an important part of that.


By Richard Dale at Thu, 07/20/2006 - 08:23

Rather sad seeing them bickering about the situation they are in. The trouble is, this is not likely to be the last time they do it since neither of the choices they presented themselves are perfect:

Mono:
Among other things, Mono was touted as "lets be compatible with MS dev platform" platform. With Vista MS will be releasing .Net v3, which is largely and different product compared to .Net v2, which was largely incompatible with .Net v1. This leaves Mono barely compatible with something rapidly aging. Much like chasing the horizon, Mono might as well call it quits and stop pulling its "compatibility" card.
It seems making Mono "controllable, in-house dev platform" was the main idea behind Novell's move for Gnome. Since selling dev and support contracts for QT is a no go, they decided to brew almost their own toolkit and sell services around that. (See messages in the same thread about gnomies being "Whoaaa?" regarding Novell's licensing tricks.)

C++:
C++ is no good cause KDE is using it. Talking about digging your own hole.

What they have left is PyGTK... Choices, choices...


By suslikreal at Wed, 07/19/2006 - 22:58

The problem is, they keep missing the use cases of higher level languages and frameworks.

You can't just decide on a higher level language or environment for Gnome like Python, or Mono, because it would only be useful if you could write the whole desktop environment in it. You can't.

All that ends up happening is that you make more trouble for yourself. They would still have to write the core of the desktop in C, and then try and wrap a higher level framework around it. It's one of the reasons I find .Net rather pointless. It's just one great wrapper around Win32. On Windows, Microsoft can put the time and effort in and get away with this, but with Mono it's hugely complex. What do you do when a bit of wrapped C code throws an error? What do you retuirn through the CLR to let the programmer know?

KDE has this right. It has a reasonably low level language in C++ that fast native code can be written in, in addition to a toolkit that makes writing that relatively low level stuff fast and in a well organised way. I would imagine that something like Ruby would get used for desktop level VB equivalent types of applications, and also for writing applets that would plug into underlying infrastructure.

The only way a higher level language and toolkit would be useful for Gnome is if you could start writing core Gnome desktop infrastructure with it. Something like native Java using gcj would be an alternative, but what's the point in picking something higher level like C# with Mono when you have to write the core stuff in C anyway - and then wrap it - and then make sure it isn't error prone? It just creates even more work. The same goes for Python as well really.

Plus, I just don't like all this language neutrality rubbish in .Net. People have largely accepted this in the wider .Net world because VB developers have realised the differences between VB.Net and C# are pointless. Amusingly, the Mono people still cling to this belief because language neutrality was touted as a huge advantage of .Net and copying it. Because you end up compiling to the same core language and framework the concept of different languages and picking one for its advantages completely disappear. .Net languages differ only by syntax - but that's a whole other flame war ;-).


By segedunum at Thu, 07/20/2006 - 13:31

You can't just decide on a higher level language or environment for Gnome like Python, or Mono, because it would only be useful if you could write the whole desktop environment in it. You can't.

I don't follow your logic here. They would be perfectly useful if you could write apps in Mono/C# or python. And significant numbers of useful Gnome apps are written in those languages. The discussion was not about whether to rewrite the Gnome libraries/framework in a non-C language.

I would imagine that something like Ruby would get used for desktop level VB equivalent types of applications, and also for writing applets that would plug into underlying infrastructure.

Yes, and C# where you wanted a language that was easier to develop in and faster than Ruby although still not as fast as the language that the underlying libs were written in (C for Gnome and C++ for KDE).

but what's the point in picking something higher level like C# with Mono when you have to write the core stuff in C anyway - and then wrap it - and then make sure it isn't error prone

It's easier to write code in C# than it is in C, and some would argue that it's easier to write in C# than Qt/C++.

It just creates even more work? The same goes for Python as well really.

Well if people such as myself or the Gnome bindings developers can develop and support the stuff I wouldn't worry about whether or not they find it a lot of work.

Plus, I just don't like all this language neutrality rubbish in .Net. People have largely accepted this in the wider .Net world because VB developers have realised the differences between VB.Net and C# are pointless.

I'm interested to find out whether that's a good idea or not by implementing the C# Qyoto/Kimono bindings for Qt/KDE - I would rather try a practical experiment than engage in flame wars. Certainly it's worth doing just for C#, and if people have fun with Iron Python/Nermerle etc and write useful apps, then that will be a bonus.


By Richard Dale at Thu, 07/20/2006 - 17:16

I don't follow your logic here. They would be perfectly useful if you could write apps in Mono/C# or python. And significant numbers of useful Gnome apps are written in those languages. The discussion was not about whether to rewrite the Gnome libraries/framework in a non-C language.

Hmmmm. The problem is that the core desktop environment infrastructure has to be written natively in something. The point was that Gnome's, and other desktop environments', problem is that they need an easier and more straightforward way of doing this - not just that they need a higher level desktop language. KDE has C++ and Qt. Gnome basically doesn't have anything, and it isn't going to be made any easier by wrapping that with Mono or Python. That's the problem that is being missed.

Yes, and C# where you wanted a language that was easier to develop in and faster than Ruby

In the KDE world I'd imagine you'd use C++ and Qt for this. There's not really much room for an intermediate, nor for a couple of different runtimes.

Well if people such as myself or the Gnome bindings developers can develop and support the stuff I wouldn't worry about whether or not they find it a lot of work.

If you can wrap the code nicely and create one to one, or as close as possible, bindings as possible and your underlying code is nicely organised then yes. However, if you've ever seen a Mono application silently fail because a piece of C code underneath has failed, or the CLR craps back a nice pointless error at you, you'll know what I mean. It happens quite a bit with .Net and Win32 as well. This is where the work kicks in, as it has for Microsoft.

I'm interested to find out whether that's a good idea or not by implementing the C# Qyoto/Kimono bindings for Qt/KDE - I would rather try a practical experiment than engage in flame wars.

This ain't a flame war. This has been debated endlessly in the .Net world, especially amongst VB developers who now see little point in their new found language VB.Net. Logically, this is the case as well. Whatever language you use, if it's a .Net language then it maps on to all the same concepts and it produces the same code in the end. You may get somewhat higher abstractions where you apparently write less code, as you do in something like Boo or Nemerle, bit in the end they are cosmetic because there's no reason in the world they can't be trivially added to C#.


By segedunum at Thu, 07/20/2006 - 21:38

The Core Framework of any platform has to be written in ONE language. It is really kind of mandatory. Think about it...

If GNOME decided to allow Mono code in it's CORE FRAMEWORK, then how would you create a Ruby application using the CORE FRAMEWORK...? Here I am, writing my little Ruby gnome app and using the gnome framework when I come across a widget/class/method that is implemented in Mono code... Oh no! Does there exist Ruby bindings for Mono code? Nope?

You can't have endless bindings. I know, I know, that is what Mono was supposed to solve by having every .Net language compile to the CLR, but here is the problem:

The set of .Net languages != The set of all languages that Open Source programmers would like to use.

************

Now, about the relative workability of wrapping C VS C++... Richard is right. People just assume that wrapping C is easier since C is an easier language, but they forget that the GNOME bindings to object-oriented languages need to completely change the API in order to work. Despite GObject, C does not have object-oriented design built in like C# and Java do and this requires all kinds of horseplay to get the GObject C code to fit in the peg hole of a true object-oriented language like Java or C#.

Cheers.


By Adam Treat at Fri, 07/21/2006 - 11:27

The set of .Net languages != The set of all languages that Open Source programmers would like to use.

That's about the size of it, yes. A .Net version of Python or PERL is never going to be Python or PERL.

Despite GObject, C does not have object-oriented design built in like C# and Java do and this requires all kinds of horseplay to get the GObject C code to fit in the peg hole of a true object-oriented language like Java or C#.

It gets even more interesting when you need to return meaningful errors.


By segedunum at Sun, 07/23/2006 - 10:46

Pages