Continuing the series of articles previewing KDE’s World Summit, aKademy (running from August 21st to 29th), Tom Chance interviewed Matthias Ettrich, the founder of the KDE project, the creator of the LyX document-processor, and an employee of Trolltech. At aKademy he will be talking about how to design intelligent, Qt-style APIs. He discusses about his thoughts about the status of the KDE project, its achievements, and what he is looking forward to in aKademy.
Matthias Ettrich talks about KDE and aKademy
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I’m very happy to see him realize the importance of Mono and .NET in general. DotGNU already has DCOP bindings and KDE paired with DotGNU or Mono is a very powerful framework.
I liked that part too.
About porting all important gnome apps through mono, as there are at least not many apps using mono right now this will take much longer than one year, but the idea is certainly nice.
In the meantime things like gtk-gt-engine help a lot, imho.
Ehem, KDE has bindings for perl, python, ruby, java and C# too, so I don’t really see a difference there.
http://developer.kde.org/language-bindings/
well, i agree with alot of what you said, but its really not that simple.
first off, gnome was made to be a free desktop. now, before people start flaming, i know about the dual liscencing. but free for linux isnt free enough for some. i dont quite agree with that myself, but you know how some in the free software crowd can be about such things.
secondly, whole structure of gnome is different. gnome has more of a hierarchy, while kde is a meritocracy. both definately have their pluses, but the strength of gnome (usability) wouldnt be there without the usability guys having the power to say “things will be done this way from now on, if you dont like it then thats too bad” you end up with alot of pissed off people, but the result speaks for itself.
and @Anonymous (IP: —.pool8251.interbusiness.it)
stop trolling kde threads. this is a topic that has been beaten to death, and will cause nothing but unproductive bickering.
Matt, I agree with your point on usability. But if you look at Aaron Seigo’s comments on planetkde and those of every prominent KDE developer, there is a very clear and understood need to focus on usability and to have usability codified into the core kde libraries so that anyone that uses those libraries automatically adopts best practices.
I think you will find that the KDE folks are quite aware that they can put a bit more polish on the diamond in their hands. Having said all of the above, usability is a bit of red herring and it is very easy to use that word without enough specificity or a clear meaning of what it is. There isn’t just one single usability paradigm and that’s why more research and real test labs need to be set up and both are happening right now.
Stay tuned.
All of those projects are, outdated, incomplete or work in progress except the pyQT/pyKDE project. The java project for instance provides bindings for QT2, some of the other projects haven’t been worked on in years. While some are waiting for the smoke project to mature.
Please get your facts straight. See this post for the status of various KDE bindings:
http://www.kdedevelopers.org/node/view/427
To recap, the following bindings are stable: Python, Ruby, Java, JavaScript. The following bindings are still in development: C#. The following bindings only cover Qt, not all of KDE: Perl.
Gnome has a solid repertoire of bindings that KDE could only dream of. Do you prefer Python, Perl, Java, Ruby, C++, C#, C++ or even C? Sure, pick your choice. I have gnome applications written in all those languages on my system. I find that attractive as a software enthusiasts.
As a software developer I want an object-oriented natively compiled base – period. For the purposes of a desktop environment and applications, that means C++. Anything else can, and has been, bound onto it. Python, Ruby, C#…. I wouldn’t get hung up on bindings though, as few people really use them to develop with currently.
@Rayiner
I don’t think my facts are off. I have been following the kdebindings for some time now(well most of last year and early this year). They are a mess, forever changing, forever unstable, zero docs. I hope SMOKE changes all that. A few months ago I tried playing around with the JavaQT bindings then in CVS. It was broken, so was Perl’s. To make matters worse, I couldn’t find any tutorial, guides, documentation on how to get either of them to work. All the other bindings then used qt2.*, except python. I haven’t looked into SMOKE, and frankly I’m not motivated to. Links to tutorials are welcome though. Maybe I might be inspired. Undoubtedly, I stand by my point that GNOME has better bindings that are well documented, not broken, and usable. I’m talking production quality here. Not CVS.
@David
I’m observing a shift away from C++ to higher level langauges that are more productive. C and C++ can be used when performance is critical and in lower level programing for libs, drivers, graphic intensive apps. After all, 90% of the time, your GUI desktop apps just sit there doing nothing.
C# is going to be huge and doing desktop development in C++ is becoming outdated. C# will suceed where java has failed. I di d C++ professionaly for 6 years and its a clusterfsck of a language. The only saving grace for KDE is that they have a good API which abstracts aways a lot of C++’s nastiness.
Any estimates on how long it would take to write an entirely new desktop in C# with the best practices/ideas from KDE, Gnome, Ice, etc that integrates something like a lean mean hardware accelerated X Server. Maybe even including the OGRE 3d libraries to enable PLG type capabilities.
It’s not like .Net is completely proprietary, we may as well leverage the Billions of $ of money that was poured into the development of .Net. Standards are how Open Source taxes corporations.
It’d take a large team at last four or five years, and would kill any chance of Linux ever making it on the desktop. One thing that we can learn from the success of certain technologies like Windows and Java is that timing is everything. It’s better to have a “good enough” technology that fits the market situation at a given time than a great technology that is a couple of years late to the game.
Isn’t four or five years the blink of an eye in the grand scheme of things? I’m sure Linux will be around in 100 years in one form or another. I get the feeling that the new “hobby” operating systems may just give Linux a run for its money in a few(4-5) years because they’re not as influenced by politics and bound by legacy code. After all, Linux was just a hobby project in the beginning.
You’ve got a lot more experience than me in this arena but I like to think that patience has its virtues.
In the article, Matthias Ettrich talks about “how” but not “why” of C# and a VM. I take it that that is not the question.
But why? Maybe these are the reasons – ordered descendingly
– Keep KDE/Qt dev platform attractive – as also Lumbergh said.
– Easier programming – shorter time to market.
– Less or no maintenance work to run on different platforms (desktop on PowerPC?).
Besides, isn’t it ironic that the CPU manufacturers struggle to squeeze out the most GHz while software “just” spends it on VM’s?
A fourth reason – would MS apps be able to run on such Linux VM?
Converting/rewriting would be quite an effort – as also Rayiner Hashem said.
http://www.devx.com/SummitDays/Article/11975
points out some of the major differences
– no pointers
– no #include’s
– try’s instead of if’s
All as with Java.
At the end of the article is another one on how to wrap C++ from C#.
Will KDE still be an interesting platform say 10 years from now?
Isn’t four or five years the blink of an eye in the grand scheme of things? I’m sure Linux will be around in 100 years in one form or another.
No. Four or five years is the difference between a potentially successful technology and a perpetually marginalized technology. BSD might perhaps be the best example of this. Had free BSD development not been held up for several years in the early 90’s, Linux may never have gotten the foothold it did, and FreeBSD would most likely have been the primary free *NIX OS.
I don’t think my facts are off. I have been following the kdebindings for some time now(well most of last year and early this year). They are a mess, forever changing, forever unstable, zero docs. I hope SMOKE changes all that. A few months ago I tried playing around with the JavaQT bindings then in CVS. It was broken, so was Perl’s. To make matters worse, I couldn’t find any tutorial, guides, documentation on how to get either of them to work. All the other bindings then used qt2.*, except python. I haven’t looked into SMOKE, and frankly I’m not motivated to. Links to tutorials are welcome though. Maybe I might be inspired. Undoubtedly, I stand by my point that GNOME has better bindings that are well documented, not broken, and usable. I’m talking production quality here. Not CVS.
If you haven’t looked into Smoke, why are you appearing to speak authoratively about the state of kdebindings? The Korundum ruby bindings are based on the Smoke library and they’re technically far ahead of any Gnome bindings project, or any other bindings project for that matter. Trust me, I’ve studied them all looking for ideas. The language independent Smoke library is automatically generated as part of the kdebindings module configuration. There are nearly 1000 classes and 30000 methods in the Smoke runtime.
The PyKDE bindings too are at least as good as any other python binding, although they require more maintenance than a Smoke based approach because they are generated from 100000 lines of ‘SIP’ interface files, rather than directly from the headers.
The java bindings have been kept up to date for every KDE release since 2.1 or so, and are at least as good as the Gnome equivalent project IMO. And please can you at least manage to get the name right, they are called QtJava and Koala, not JavaQT. But they too are left for dead by the Smoke approach, and I hope to rewrite them for KDE 4.0 using Smoke . Please read the link refered to in Rayiner Hashem’s post for more detail.
Any docs/tutorials on how to write simple apps using SMOKE? Any apps written in SMOKE? Is SMOKE now part of kdebindings, the package? The link provided by Rayiner isn’t helpful, I read it.
Most of you think I speaking out of my arse. I’m not. Today, I can write full fledged applications in C, C++ Python, Java, Perl, C# and Ruby using GNOME/GTK+. I haven’t for the love of life figured out how to do that in KDE. Last time I tried, admittedly before 3.2.* era, the Java, Perl, bindings were broken, and I didn’t like the Python bindings. Whether or not QT/Java is or was called Koala is irrelevant. I could care less if it was called Kite or Longhorn.
It doesn’t matter whether SMOKE is technically superior(inferior) to all bindings around the world, I don’t care if it is. Just provide me with info to how I can install it and play with it. Not links to blogs, or links to outdated material.
” Any docs/tutorials on how to write simple apps using SMOKE? Any apps written in SMOKE? Is SMOKE now part of kdebindings, the package?”
You only need to know about Smoke if you are writing bindings, and I agree there could certainly be more docs on how to do that – sorry you didn’t find the link helpful, but I’ll keep trying..
PerlQt and QtRuby/Korundum both use the same Smoke library. There is a version of PerlKDE in the PerlQt cvs on SourceForge (it isn’t in the kdebindings module unfortunately).
Any PerlQt or QtRuby app uses Smoke, so yes of course there are apps.
“It doesn’t matter whether SMOKE is technically superior(inferior) to all bindings around the world, I don’t care if it is.”
That’s your problem, not mine. The advantages of having a common runtime with full introspection capabilities, are exactly the same advantages given for wrapping an api for the CLR with C#. You wrap your native api once, in either Gtk# for Gnome or via the Smoke library for KDE. Having done that, then all the other language bindings can use it, and you don’t keep reinventing the wheel for every new language that comes along.
Unlike Gtk#, the Smoke library is entirely auto-generated, which makes it both more complete and easier to maintain. It just isn’t possible to do this for the C based Gnome api because it doesn’t have enough type information compared with a C++ api. You need to manually annotate huge xml api descriptions for each new release.
Somebody said only PyKDE is actively maintained. This is not true, I cannot speak for the other bindings, but KDE-Java is very well still actively maintained.
Good response about SMOKE and what its technical advantages are. I really like the auto-generated bindings provided by introspection-this is really cool technology. In fact such a system makes maintaing uptodate bindings for mulitple languages infinitely simpler-much less effort, time and bugs…. Luckily there has been a lot of discussion about implementing something similiar to this in GNOME-I don’t know all of the details involved in this but people are actively looking for a way to implement this kind of introspection functionality. ( I am making the tacit assumption that introspection is a function of OO languages and that the c implementation of OO found in glib can be extendend to make such possible-don’t shoot me if I am mistaken however)
I also really hope that QT-4.0 will really take advantage of the offerings present in Mono and DotGNU as well as the ongoing work in cairo. Although I don’t use KDE as my primary desktop I have installed it and used on every Linux install I have ever used and maintain it as an option for the 300 users of the LTSP server which I administer and of course I really love certain KDE/Qt applications. What suprised me in the article was tha Mathias is the founder of Lyx. Does anyone know why on earth it took them so long to get Lyx using QT ?- I only ask this beause I love Lyx and the QT port is what first made it appealing to me to use….
The new version of KDE may actually make me switch to gcc-3.4- the compile times for KDE are drastically reduced in this version of gcc and I would like to install it without having to wait so damned long
(oh the miseries of compiling everything yourself 
-me being a gentoo user…)
http://xmelegance.org/kjsembed
What suprised me in the article was tha Mathias is the founder of Lyx.
Don’t be surprised. It’s wrong:
http://www.lyx.org/about/klyx.php3
I remember when klyx came out-I even used it a couple of times-but then the project just died leaving Lyx without a QT /KDE version. Lyx with QT support came out in February 2003-over two years had gone by with no movement on the klyx front. I am glad to here that stuff from the old kylx will be part of Lyx 1.4….
Perhaps I should have phrased it differently-but an active Lyx supporting QT has only been around for the last 18 months, whereas Lyx is under development for almost 7 years?
Hell Lyx is even older-it was copyrighted by Mathias back in 1995!-long before KDE was even thought of….
Lyx rocks. It produces the best output. It is what every decent writer should use. Try it, you’ll love it once you understand it and it takes all of 20 minutes to see how it works.
Sorry to sort of hijack this. Feel free to moderate my comment down but I can’t help but wonder why the comments by Eu and mystilleef were moderated down?
Eu’s comment was totally on topic, no flaming what so ever, so it is hard to see what could be wrong with it.
And while mystilleef’s comment wasn’t exactly on topic he merely disagreed with something someone else said and did so in a polite way. And after all, his disagreement led to an interesting discussion.
So what is happening here???????
Once again, every time an artilce about something that is related to C++ comes up, the ensuing discussion thread has comments about C++ being the boogeyman of languages – that it’s error prone, too difficult, to complex, etc etc etc ad nauseum. Then these comments are usually saddled with comments about the need for managed code (Java/C#) and how C/C++ are obsolete.
Well, certainly C++, with it’s direct memory allocation capability, OOP, and large libraries, can be difficult and error prone. But it can be quite easy and productive, if it’s used the correct way and with the STL and with good supporting libraries.
Personally, I’ve done plenty of C development, where direct memory allocation was a must, and yes it’s a pain. I’ve also done C++ development, with using the STL, as well as a good GUI API like QT, and it becomes much much easier than straight C development. And I’m not an advanced programmer either – I’m probably intermediate level. But I’ve had a lot of fun, and experiernced rapid development using QT, or the STL, or some other well made library, while using C++.
Frankly, the C++ STL, and QT, are a couple of the best frameworks I’ve ever used. I’ve done straight C development using the Win32 API – that’s a disorganized, complicated mess. I’ve used MS MFC, which is also a bit of a mess. I’ve used GTK+/Gnome libraries – which are better than Win32/MFC, but still overly complex (reinventing the OOP wheel). I’ve used Java/Swing/Awt – an awful, poor performing mess (well, Swing certainly is). Then I look at Mono/C#, and I see the obvious Microsoft Trojan Horse that it is (just look at their ever-expanding patent arsenal, and their patents on the CLI and C#, and their intention to use their patent arsenal to stymie open source). Compared to all of these, C++/QT are by far the easiest and most productive (and safe legally). Only Visual Basic was easier for me (which I’ve done extensive development for), but not by much.
Then I look at what a huge success KDE is, and how powerful and configurable it is, and how efficient it is, and how many (tons) of apps it has, and I see an end result that just proves beyond a shadow of a doubt what a powerful, easy, efficient framework C++/QT/KDE truly is. It’s also totally cross platform (just a recompile is all that’s needed).
So all of the complaints of “C++ is too hard”, or “we need managed code”, or “we need this binding or that binding”, are all kind of silly. A totally kick-ass framework is already right there for taking. It’s just a matter of people dropping their preconceived notions and just using C++/QT/KDE. No one will regret it.