Comments on: Scripting languages and KDE

By: Richard Dale

Richard Dale — Tue, 04 Aug 2009 13:47:25 +0000

illissius said: I don’t see why the existence of Qt4 should mean that an application written in Qt3 cease working.

Software doesn’t suddenly stop working for no reason. I think the problem you are talking about is caused by a change to a Ruby C function between Ruby 1.8.6 and 1.8.7, where the type of an argument changed from ‘char *’ to ‘const char *’ that meant that Qt3 QtRuby no longer compiled.

I do have a backup of my Qt3 based development environment on an external USB disk drive, but when I went to fix the bug, for some reason I couldn’t get it to work in a chroot’d environment. So I’m afraid I haven’t been able to fix the bug, but it is only about an hours work for someone familiar with C/C++. I really can’t see that as much of an argument for not using QtRuby. If you had written your game in C++, I wouldn’t be surprised if the code needed some similar small changes over the past 5 years due to changes in the GNU C++ compiler.

illissius said: there is no assurance that the bindings will continue to be maintained well into the future (a small game I wrote with the Qt3 version of QtRuby several years ago is now basically unusable), and getting it to work on any OS besides Linux is a crapshoot.

I’ve been working on QtRuby for over six years, and I think it is highly unlikely that I will give up after all that time. And there are other people who know the code, should I fall under a bus.

As for porting GPL’d Qt3 applications to Windows and Mac OS X, of course you can’t because there was no GPL license available. Porting a Qt3 QtRuby app to Qt4 is no harder than doing it for other languages, and may even be easier than in C++.

By: Andy

Andy — Tue, 04 Aug 2009 13:10:34 +0000

From reading the comments, there appear to be two separate arguments here. Writers who want the bindings included with KDE by default emphasize the need to make development easier. Writers who are against the idea point out the fact that Python, etc. use more memory and have more limited performance. Both arguments are essentially correct. But nobody is suggesting a re-write of Kate, porting it to Python. I think we can all agree that it would be a terrible idea to do so.

I do however think a LIMITED set of quality bindings would be incredibly useful. The two languages that come to mind are python and javascript. These languages are popular in the community and well supported by upstream development. Rather than focus on every possible permutation (Perl, Java, C#, Haskell, D, etc.) the KDE project should select 1-2 bindings to include in the kdelibs. This would expand the programming options within the desktop without causing a cascade affect dependencies. Of course there will be those who will criticize the decisions made regarding which languages are chosen but it would be a relatively sane middle ground to shoot for.

The Gnome approach, where C#, Python, etc. are constantly running for basic core functionality is ridiculous but there for smaller applications, python or javascript would be appropriate and would only affect the users of these smaller, niche applications.

By: Einar

Einar — Tue, 04 Aug 2009 07:27:54 +0000

@Cyrille Berger – My point, as stated before, is that people who don’t know / can’t learn C++ should be welcomed as much as the ones using C++. I heard myself of a number of PyQt applications, but not as many use PyKDE, for example.
Increasing the “awareness” for bindings will open up more fields for KDE: being biased towards the life sciences again, I’d love it make inroads in a field which is basically all Java and web-based applications. But in those fields, almost no one knows C++.

By: Cyrille Berger

Cyrille Berger — Tue, 04 Aug 2009 07:22:07 +0000

An other reason is that despite all the bashing on the complexity of C++, the combination of Qt with a certain subset of C++ (which maybe we should call QtC++ :) ) make a very powerful and easy to use development framework, which reduce the need to go for an other language.

One also should note that they are very few new applications introduced in the main modules nowdays, because they are rather “complete” and already formed quite an advanced applications suite. So it would be worth to extend your search to extragear (and even to outside, especially with the move to DVCS people feel less interested in being in the official repository), there are also many PyQt4 applications, fewer RubyQt (despite being an avid C++ coder, I wrote two of them ;) but don’t really advertise them nor have taken the time to put them on a public repository…), and I have heard of a few Qt/C# ones.

By: Einar

Einar — Tue, 04 Aug 2009 05:28:33 +0000

@robertm – I don’t want to sound like there’s lack of support from KDE developers. I just wanted to resume the discussion on bindings, which IMO are first class citizens but due to a series of (solvable) problems aren’t as used as they could be. The first would be bringing more people in, especially to write docs.
@Andy – Python has the Global Interpreter Lock which causes some problems with regards to threading (not yet removed and unsure if it ever will since there are a number of modules inside the core that aren’t thread-safe). I think it can be worked around, though.

By: Andy

Andy — Mon, 03 Aug 2009 23:16:32 +0000

As a ruby developer who would love to write desktop apps in KDE, I’ve found that the biggest thing that prevents me from doing so are issues with interpreters support of threading. The ruby interpreter doesn’t support native OS threads (same applies to python I believe) which can cause issues with a framework like KDE which uses them a lot and also controls the main loop.

I’m more familiar with how these issues manifest themselves in GTK, where for example: segfaults can occur when trying to access GTK from the wrong thread, ruby code can be starved for cpu cycles, and long running ruby code can block screen redraws and button clicks. Last I checked KDE suffered the same sort of issues.

The next version of ruby (1.9) implements native threading I believe so maybe some of these issues will go away. I hope so because there’s been a lot of progress in automated testing using languages like ruby, and I would love to work on a desktop project with a full suite of automated unit and functional tests.

By: Andre

Andre — Mon, 03 Aug 2009 23:01:35 +0000

Having been forced to use Perl, Python and Java on projects during the last few years, I’m a bigger fan of C++ than ever. For me, it’s not a question of being interpreted, compiled or bytecode-compiled, it’s more a question of being typesafe, consistent, powerful, readable and _constant_. There is a new kid on the block every few months, be it Vala, Groovy, Ruby, C#, Lua, Python, Perl, ECMA, PHP, or even VB. Many evolve fast. Some don’t have solid enough IDEs, some don’t have solid enough libraries, some are not solid themselves. It’s a moving target. I don’t think it’s a problem of KDE, imho it’s more of a problem of the languages themselves.

By: Einar

Einar — Mon, 03 Aug 2009 21:19:12 +0000

@Harley – I would count Pardus Linux as a high profile example of what PyKDE can do, to name an example. But yes, single applications that show clearly how well bindings work (they do: the stuff I’m working on in my spare time works great thanks to KDE libraries, and it’s even lean, number of lines of code wise) would be definitely welcome.

By: Harley

Harley — Mon, 03 Aug 2009 21:13:53 +0000

Personally, (and this sounds like the general consensus) I think anything in non-C++ language bindings is fine outside of the KDE core. Basically I think there just needs to be some high profile projects written in the bindings to get people excited about writing KDE apps in that language. For instance look at what Banshee, F-Spot, and Tomboy have done for C# in the GNOME community.

By: Einar

Einar — Mon, 03 Aug 2009 20:55:32 +0000

@Simon Edwards – I used “scripting languages” as a – perhaps over- -simplification (I’ve been using Python for a number of years now and to me too it is a full fledged programming language).