Since the C# bindings are apparently not really used/wanted by anyone (except for some Windows people – but that’s really not my main development platform) I thought that maybe some more people are interested in Java bindings.
There was a poll on kdedevelopers.org two years ago that showed Java ahead of Ruby and C# – but it doesn’t seem to be really representative: there are at least some Ruby plasmoids on kde-look.org, but none in C# (which was still ahead of Ruby). Given that Trolltech/Nokia abandoned QtJambi I’m not too sure about Java bindings either.
So I’m asking the community directly before I start putting too much work into a project that noone really wants: So far we have (active) bindings projects for Python, Ruby and Perl – is there any demand for Qt/KDE Java bindings in the community? Or if not for Java, for any other language/platform?
Looking forward to your comments 🙂
I would really love to have a binding for the D programming language. I’ve been looking into how to create one myself using smoke, but I haven’t really gotten anywhere yet.
There are already Qt D bindings… http://www.dsource.org/projects/qtd you might want to take a look. Doesn’t seem to be based on SMOKE though.
Yeah they are Jambi based, Qt only. I would really like to create KDE applications with D. *sniff*
“Since the C# bindings are apparently not really used/wanted by anyone (except for some Windows people – but that’s really not my main development platform)”
Are you absolutely sure of this? On the GNOME side of things, at least, C# seems to be vastly more popular than Java – and they obviously tend to focus on Linux apps.
At least in KDE no-one seems to be using the bindings. Reasons for this are probably a mix of Qt + C++ being very easy and intuitive to use (contrary to Gtk+) and skepticism with regard to Microsoft.
And from what I’ve read so far, not that many people in GNOME are happy with F-Spot, Banshee and Tomboy being installed by default by distributions. F-Spot and Tomboy have C/C++ ports (Shotwell and Gnote) just because they were written in C#.
I think Novell is pushing Mono and Gtk# pretty much, so it might seem as if GNOME would happily accept C#. But from what I’ve read so far, that’s not quite the case.
Shotwell is not an F-Spot port. It’s an alternative application to F-Spot. And it doesn’t exist because F-Spot is written in C#.
Also Shotwell is written in vala:from wiki pedia
“Vala is a programming language created with the goal of bringing modern language features to C, with no added runtime requirements and with little overhead, by targeting the GObject object system. It is being developed by Jürg Billeter and Raffaele Sandrini. The syntax borrows heavily from C#. Rather than being compiled directly to assembler or to another intermediate language, Vala is compiled to C which is then compiled with a platform’s standard C compiler.”
I’d like to get Go bindings for Qt.
Why not bindings for vala? Vala is a young programming language but powerful. I think that Vala is comparable to c++ and far superior to C# or java or python…
I think that vala is a language with future and could be a bridge between Gnome and KDE. There is a project (Dova) that is a experimental framework written in Vala. Vala use the gobject system from gtk+ but… Why not qt too?
Vala ‘compiles’ to plain C, so we’d have to build QtC bindings again before we could wrap them in Vala – which would be silly, really. Moreover Vala inherits some of C’s deficiencies – like not being able to overload methods.
I don’t think approaches like Vala are the way to go, not for a framework like Qt.
In a sense, Qt is already like Vala, in that it works around some of C++ deficiencies, like not having reflection (being ‘fixed’ by the moc). Qt is already powerful enough, we don’t need to build half-baked solutions on top of Qt and C++.
“Vala inherits some of C’s deficiencies – like not being able to overload methods.”
That’s not a deficiency. C++’s function overload resolution rules are complex and error prone as hell.
Java bindings are a good option. There are out there many many java developers (language nº by developers number), so probably a significant amount of them will use the bindings
Bindings are a lot more than some autogenerated code. Unless you have ported documentation and a wealth of examples it’s no better than not having the bindings at all.
KDE bindings have generally been quite good, but I’ve seen so many Python bindings where the fun part has been done, but no-one can be bothered to do the rest of the important stuff.
Not a rant, just saying to think about it before committing to supporting a language.
I suggest there’s no point unless you get an overwhelming response from people who /really/ dislike the currently available options, not just those who would maybe use if it was there.
Of course, if you’re doing this purely for your own fun – go ahead.
Yes, that’s very true, documentation and examples are very important, along with IDE support in KDevelop or similar if possible. Hariom Balhara is working on a Season of KDE project to autogenerate documentation for Smoke based language bindings, starting with Ruby. More examples and Techbase Wiki docs are always welcome and even a small of effort can make a large difference there.
Another important point is that the Java bindings that Arno is discussing would be based on KDE’s Smoke technology, which is shared by several languages. Any new Smoke bindings project is likely to end improving things for the other language bindings projects (Ruby, PHP, JavaScript, Common Lisp, C# and others). As an example, Arno has made major improvements to Smoke, although he originally only worked on the C# Qyoto/Kimono bindings.
As a user, I’d take a mono plasmoid over a sun-jvm plasmoid any day. The latter is simply too heavy for this kind of thing. The JVM definitely generates faster code, but it also takes a lot time and a lot of memory to do that and it’s not worth it for small apps.
As a developer I wouldn’t mind either, as long as the binding has a low overhead. If I remember correctly the previous smoke C# bindings did things like use a lookup table on every method call (to find the method), I never got to know why. (Come to think of it, maybe it generated method wrappers on the fly and cached them to save memory on unused methods.)
Regardless, for minimum overhead KDE scripting Lua/LuaJIT come to mind, Lua normally doesn’t have a complete standard library, but since you can find everything in Qt anyway, that shouldn’t be a problem.
The Qyoto bindings cache the method after the first lookup. The QtJambi bindings were significantly faster when I last did a comparative measurement (5x faster), but in practice memory use is probably at least as important. It depends what you want to use the bindings for. For something graphics intensive like Krita, you could never match C++, but for things like plasmoids the speed of the binding really doesn’t matter as it is the speed of the methods in the underlying C++ libs, which govern how fast you app or plasmoid will run.
Hmm, looking at the code I’m astounded by the amount of overhead. A hash table lookup is actually the fast path for calling methods, the slow one being some search over all Qt modules… What exactly was gained by this? I’m sure it’s hard to bind two languages with such an impedance mismatch, but come on… C# is a statically typed language with overloading, there’s no need to resolve overloads dynamically.
The Smoke approach was originally designed for dynamic languages like Perl, and so it is ‘cheating’ in some ways using it for statically typed languages like C#. The overloaded method resolution doesn’t ‘search over all Qt modules’, it uses the Smoke lookup mechanism. That consists of two stages, it first uses a ‘munged method signature’ to do the loopup. For instance, a foobar(QWidget *, int) method has a munged method signature of ‘foobar#$ ‘ and that is generated at compile time, not runtime. Often there will only be one match for the particular munged method, and we can go straight to caching the method in a hash table. It is only in the case of there being more than one possible method matching the munged method signature that we have to resolve the overload at runtime.
If we didn’t do a dynamic lookup this way, it would mean having C function for every single method that we want to call. It would also mean that we would lose the possibilities that putting every single method call through an Aspect Oriented style ‘interceptor’ method like we do in Qyoto, although we haven’t made much use of that feature yet.
How would you feel if all your C++ method calls went through that mechanism? 😛
I understand you can tolerate overhead in languages that are so slow normally you woudn’t really notice, but C# is not one of them. I don’t buy the buzzword explanation for the interceptor.
Anyway, I’m arguing about this in good faith, I’m pretty sure more people are turned down by this, some would find it a very unpleasant surprise.
Hmm, I was going to say that you can cache stuff in static class fields instead of a hash table, but come to think of it, a C wrapper that is shared between different bindings (and thus loaded only once) would be a good thing.
Yes yes ! Please continue the dev of Qt jambi !
JAVA really need a very good framework like Qt.
Jambi is just not officially supported, but it still lives on:
http://qtjambi.sourceforge.net/
+1 for a Java bindings.
But further thoughts on this… I really, really don’t find Java “fun” to write programs in. While it’s a reasonably FOSS-friendly, GPLv2-licensed VM, I personally couldn’t say I’d write anything in Java outside of employment. Not that I’m representative of the community, but I feel others would feel the same.
It’s better a corporate project (perhaps Nokia/Qt should take it up again, especially with all the new Java developers writing for Android) than a community one.
I think bindings for JVM languages in general are more important than bindings for the Java programming language in special. Java binding will be a fantastic thing if they can be used seamless from Groovy and Scala (with operator overloading for containers and properties for getters and setters).
+1 for a Java bindings
Yes, Java is horrible, but Scala is quite nice, although it inherits some limitations from Java and the implementation of the language-features is limited by the weak Java-object-model. D is quite nice, too. Becuse it does not rely on Java, it is much better for some kind of stuff. But there may be problems with compiler-support: DMD is proprietary, GDC is not continued by its original-developers (although I think that there is a fork) and LDC does not even try to implement D 2.0 features which would make binding-creation much easier (extern “C++”, in D 2.0 it supports C++-style name-manglingand the usage of C++-classes as D-interfaces).
Guile/Scheme is a nice scripting-language, I have already tried to wrap KDE-libs…
Actually, what I would really love is a way to write and be able to use KRunner plugins in Ruby. I saw a post from Richard Dale that said that this doesn’t work right now, which my very hasty test last night seemed to prove. I’m totally fine with restricting it to Ruby 1.9.x too. Note that I haven’t tried this with KDE 4.5 yet
KRunner make extensive use of threads which meant that it would be possible to base them on Ruby 1.8 .x. It should be possible with Ruby 1.9.x as it has support for native threads. But there is still the speed critical aspect of KRunners which Ruby 1.9 may or may not solve being faster. Personally, I’m not sure that a Plasma script engine for KRunners is even a good idea, and may they would all be better off written in C++.
Except that I haven’t gotten around to finishing a nice persistence API for Qt/C++ like Ruby has with Datamapper. 🙁
freepascal, but it’s not a scripting language. It’s the only general purpose language I’m comfortable with for very long. Besides that I might write a thing or two in javascript, since my current project requires it much more in depth than anything I’ve done before. Most of the code I’ve written outside of those two were in much more purpose oriented languages or years and years ago in school.
+1 for Java bindings.
Somehow related: http://www.compeople.eu/blog/?p=307
With SWT/Qt SWT applications should stop looking like shit on KDE 🙂
Java bindings would be cool, but IMO it’s not worth the resources currently, when there are other places where the available bindings can be improved (like docs/examples) to make people actually use them (more).
What would be more important to me, is the broader adoption of writing scripts/plugins for all kinds of applications, kio-slaves, akonadi-resources, etc. in scripting languages (excluding Plasma, which is very good documented already).
It also looks like some trend for apps to support JavaScript instead of Kross, which is a pity (I know the discussions). For those apps using Kross, there’s usually a lack of documentation (on techbase) and possibilities for publication/distribution (I only know of Amarok scripts on kde-apps (which is – again – JavaScript only).
i’d also appreciate java bindings
I dont like C# for different reasons but its still besser than Java. In Performance and Memory.
Java isn´t the language that anyone ever wanted (except developers who like when the programming languages is cleaning there ass)
oh damm i write to much in to many different languages
C# is still “better” not “besser” xD
// Skipping all the FUD about Java and C# //
Although I truly appreciate Java (especially when comparing it to C++ with std libs) I’m not sure how many devs would really use the bindings. From my point of view, C++/Qt is as comfortable to develop with, if not more.
But, as Ludger said, if Java bindings meant availability of Qt/KDElibs for all JVM languages, it could prove to be rather useful. Having the option to write (parts of) KDE apps in a functional language like Scala would be really neat 🙂
IIRC, the old Java bindings (KDE<4) were as used as today's C# bindings – almost not at all. Maybe things have changed…
Cheerio,
Ivan
„I truly appreciate Java (especially when comparing it to C++ with std libs)”
What?
The Java-std-libs are just shit compared to STL. I am speaking about containers and algorithms. Missing value-semantics, missing genericity (in C++ it is really easy to replace one type by another, in Java it is not because of missing value semantics for complex types, inconsistent method-naming in the library, huge differences between built-in arrays and library-containers etc.), uncomparable iterators, missing compile-timetuff (namely templates) etc.
Unless some JVM implementation can lower the start-up time and memory footprint, I don’t see any
JVM solution (Java, Groovy, JRuby, Scala) would fit great as a plasmoid, for instance… Users expect
KDE to be very responsive. They will not understand why some plasmoid don’t show-up immediately
on their powerful notebooks or desktops… They will immediately blame KDE, associating any delay
with KDE’s fault. That is my concern of supporting the JVM for plasmoids…
A lot of Plasmoids take long time for loading some kind of stuff at initialization. And I think the slowness of Ruby is really worse than a single JVM initialization…
Please, try to send a comment here from Akregator. The comment was successfuly sent, but I got an error message. Also, auto-wrap doesn’t seem to be working…
Best regards,
Rodrigo
We should create a new programming-language that is better than all this Java, C#, Scala, D stuff and even better than C++. It is somehow unbelievable: After 30 years of really slow C++-development nobody could create a language being obviously better in all points (low-level-stuff, STL, consistence, meta-programming, genericity…).
I guess it is boring to write bindings for all those some kind normal languages.
What would be about a Haskell-Binding?
There is already one for Qt: http://qthaskell.berlios.de
Unfortunately the routines for generating this stuff are not published…
uh, I’ll try to ignore the “langage xxx > langage yyy because it’s faster and etc”…. I’ll just state that’s the true power of java is : tons of excellent foss libraries (for persistence, xml, rest, web services and you name it)
So to answer your question Arno :
I’m a good java developer (that’s my job…), if you can make bindings that could be used with eclipse WITH complete javadoc for all api THEN that’s an excellent idea ! If it’s not the case, I think it’s not more useful than c# bindings…
whatever you decide, good luck ! 🙂
+1 for Java bindings
Java bindings would be very nice, however they should IMHO use JNI for speed reasons.
Yes it should not use Smoke, we know, that would be cheating.
But maybe we should also have a look at gcj…
No, the bindings will use SMOKE (well, for native interop we’ll have to use JNI anyway..). Using JNI for every method call would be re-inventing the wheel really. We’d have to generate C wrappers for each and every method call which would result in just another large library being loaded at runtime. SMOKE already provides a nice interface that is used in all nearly all KDE bindings and is reasonably fast for every purpose that you’d use bindings for.
If you want to write high-performance code, you’re better off with C/C++ anyway.
People who consider developing with Qt/KDE in their language of choice expect that a reasonable amount of engineering was put in the bindings to minimize overhead. The number of JVM and CLR developers in the world is larger than C/C++ developers. Telling them to switch to C++, because that’s the only way to get some performance out of Qt, is rather absurd.
Anyway, I understand that binding to Qt and C++ in general is hard and awkward. Maybe it’s the Qt developers themselves, with their access to internals, who should make a nice, low-overhead C binding first, that is geared towards interoperability with other languages.
Let me make this clear: The bindings _won’t_ be ‘slow’. Yes, they will be slower than plain C/JNI based bindings. But even this kind of binding would be much slower than native C/C++ (simply because you have the marshalling overhead).
Just doing a quick measurement (probably not very precise, but to give you an idea):
My fairly old laptop with a pretty slow CPU can do 10,000 _complete_ method lookups (that includes looking up the class, which will normally be done only once, and looking up the method name and method map, which will be cached after the first call) in 10 to 20 milliseconds. I’d say that’s sufficiently fast for most use cases.
Unless you want to write a 3D gaming engine with Qt, you won’t have to switch to C++ ‘to get some performance out of Qt’.
I’ll probably repeat myself here, but: most of the performance loss will probably be in marshalling, specifically marshalling complex container types like QList, QVector, QHash and the like.
“I’ll probably repeat myself here, but: most of the performance loss will probably be in marshalling, specifically marshalling complex container types like QList, QVector, QHash and the like.”
That’s a very good reason to offer the option of having wrappers for those types, which can be constructed once and don’t need to be marshalled all the time.
I was thinking about that – you won’t have the overhead on returning the list, but on accessing it. At some point of time you just have to do the C++ -> Java conversion of the contained objects. Either you do it all in one go when you return a QList/QHash/whatever, or you do it when you actually access it. But either way, the marshalling has to happen.
This blog is probably not the best place to discuss this. But you’re invited to join kde-bindings@kde.org and work out new ways of language interop with us 🙂
Would love java KDE bindings. I had a look at Jambi when QT released it but it didn’t really seem to play all that well with KDE it’s self. I couldn’t work out how to access a lot of the kde technologies so just let the project slide. I think the important thing with bindings is that they need to be well documented in terms of the work flow. Otherwise the majority of it goes un-used and untested.
+1 Java. It still has important role in corporate apps and a generation of people that devoted to it since its birth. Maybe with the binding, and promo :P, some devs would convert some their apps to KDE. Hey, we might have a Qt-based Swing.
I’d like the Java bindings, as it would allow to easily connect work from my current research with the KDE Desktop very easily. 🙂
I use KDE myself, but have to stay platform-independent, therefore cannot develop/implement for KDE itself. Java bindings, however, would be a step towards my tools being in KDE.
+1 for Java bindings. But you should also look in Go programming language.
I am not so sure whether Java bindings will find that much users. Jambi never really took off (in terms of license sales). Although a lot of people I know (including me) thought there would be a market for a decent UI toolkit (i.e. not Swing or SWT), maybe there isn’t… Java isn’t that big on the desktop after all.
> So I’m asking the community directly before I start putting too much work into a project that noone really wants
If I had asked people what they wanted, they would have said faster horses. – Henry Ford
I think Java bindings open KDE to new communities like Groovy, Scala and Jython too, which can all interop with Java classes as their “assembly language”. Worth considering I think.
Stay away from c#, please. I don’t want KDE applications to be so sluggish like gnome applications. F-spot, tomboy, banshee make desktop to crawl! Compare tomboy (a simple note taking program; yeah, right) to Firefox and tomboy consumes about the same amount of memory (it’s enough to open three or four notes). There’s enough ms and novell people trolling at planet gnome to realize there’s something bad with mono. Apps written in mono are sluggish and the situation with patents is not clear. I don’t like java, but it’s not product made by our rival and afaik java is free to use the way you like.
I think the problem with C# uptake is as much to do with never seeming to get to a 1.0 release that’s good and stable and has some documentation — and some marketing.
There are lots of Windows devs writing C# – its not really a question of whether existing KDE devs would use it (they are C++ devs, after all) but whether some of the resources currently spent on winforms on Windows could be diverted at Qt and thus the code could port away from Windows to other Qt platforms. It would take time – but while I’ve been almost working full time on UNIX for two decades I can honestly say that the amount of UNIX-based GUI development has gone down in the businesses I’ve been working for, most of which were Motif and/or SunView shops at some point.
Qt is a nice library: if you want to look at things solely from a KDE point of view then fine, but its a niche and will stay a niche while that’s a view that is widely shared. I think that can be changed if you view things from the point of view of a corporate developer who must target Windows and might like to have portability to UNIX (and might like Qt goodness over Microsoft’s own offerings). But you’ll have to move on from a KDE mindset to be successful as that – and it will not happen overnight. I would have thought that Meego would be able to sponsor some effort and Intel cetainly have money, but you might need to free SMOKE from KDE and make it standalone in the swig space.
+1 for java bindings. i’m not saying i’ll use them but if you are interested in putting effort into any binding i’d recommend java since it’s widely used. maybe we could more easily provide scala, groovy and other jvm languages bindings then as well?
As a C# developer targetting the big three platforms I am desperate to use Qyoto, simply because Qt actually maintains native look & feel (well, more or less) across all of them.
Qyoto is currently easy to build on Linux, difficult to build for Mac (although thanks to a KDE-experienced friend we managed to get it working), and impossible to build for Windows.
As it stands, it seems Qyoto is just meant for people writing KDE apps. Is this true? Gtk might be crappy but at least Gtk# works everywhere… If I didn’t care about portability, I’d be writing System.Windows.Forms c# applications…
This is exactly my point. My main target platform is KDE/Linux – if that would have a reasonable user base, I wouldn’t mind putting some more effort into making it work on Windows, OS X, Solaris or whatever.
However I don’t like coding only for some corporations who are then happy to have a cross-platform toolkit for free, without having any support from the community that I really care about.
Sorry if this sounds a bit harsh, but that’s just how it is.
Is there anything you would be prepared to do that might make it easier for those of us who care about Qt primarily and KDE only tangentially to help maintain it and widen its audience? (Not that I’m making an offer really; I can achieve my near-term objectives in Python)
I guess the issue is: do you want control, KDE focus, and no users? Or less control, less KDE focus, and more users?
We’ll split the Qt-only part of the bindings off kdebindings after the git transition of KDE has completed, so then everyone who wants to contribute can create a personal clone on gitorious (or whereever it’ll be hosted) and file merge requests, or even gain access to the main repository.
So it’s not that much for control. Everyone is invited to help developing the bindings. But *my* focus (which is not necessarily the focus of the project, if/when other developers join) is KDE – and if there are no users of the bindings in KDE, I don’t see a reason why *I* should develop the bindings any further.