“The People Behind KDE” series is back from a long vacation thanks to overwhelming popular demand. In this first interview, KDE’s ever so charming Tink gets back with Matthias Ettrich to see what has changed since the previous interview now more than three years ago.
People Behind KDE: Back With Matthias Ettrich
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 thought it was pretty interesting, always nice to get to know the developers.
I am also looking forward to Qt 4 which will bring huge performance improvements and hopefully better integration iwth KDE.
When will KDE finally get a good look like Gnome’s?
> When will KDE finally get a good look like Gnome’s?
Plastik is wonderfully nice
“Good look” really depends on your taste. I personally find GNOME to be a little bit bland. If you want a a flatter, darker look, try QtCurve 1.7.1 + the Gorilla icons. If you turn QtCurve rounded buttons on, but the gradients off, it actually has a cool, retro-Mac look to it. I like it with a slightly modified Coffee color scheme. You can find all these items on kdelook.
I am also looking forward to Qt 4 which will bring huge performance improvements and hopefully better integration iwth KDE.
If QT gets any faster, GTK+ apps are going to start looking like swing apps in comparison
Too bad that QT isn’t lgpl.
Without trying to support the troll, I think that “good looks” are much more than the theme. There are many parts of KDE which don’t look good to me, which have nothing to do with the theme. Like the narrow spacing of the menu items and other bad layouts. Use of font styles and lining or simply busy and crowded layouts can look bad. It’s in the little things.
Many GNOME GUIs look even more ugly, but especially the more modern ones following the HIG look pretty nice. This also applies to the general desktop appearance, for example how Nautilus renders icons and selections.
that was an interesting interview. My fave question was: “Novell acquired Ximian in August for about 20 million. Do you regret not starting your own KDE company? If so what’s stopping you?”
IMHO, those kind of questions make for good reading…too bad his answer was so short, LOL
The freedesktop X server is more important than I thought.
Not much about KOffice – office being the most important app on any desktop. Wonder why.
I saw somewhere that there is activity to integrate OpenOffice.
A wish for integrating Mozilla I don’t understand. Why? I’d spend the time on something else.
Wonder what those thousands of ISV apps are (that do not show up on http://kde-apps.org/). Technical apps?
I hadn’t heard about Julian Seward before (developer of valgrind).
I’d liked to see some business related questions too. Like where do you see Qt in 5 years? Who/where/what/how? Allthough not exactly his turf.
Can we got over childish nuances and unprovoked trolling? When does it sink in that the speed of an application is independent of tool kit and heavily dependent on the skill and knowledge of the programmer wielding their tools?
I use both KDE and GNOME and I hardly notice these latent and abrupt performance increase in speed that has of late become an appeal to popularity as opposed to reason. Certain applications like Konqueror render pages faster, but Galeon, Epiphany and Mozilla weren’t known to be sluggish with regards to that.?
“KDE is faster than GNOME” What the hell does that mean? Absolutely freaking nothing! Qt applications suffer as much resize.issues as do GTK+ applications. But that’s beside the point, as such issues again are application dependent.
So tell me, for the love of reason, how anyone can blatantly conclude that Qt is faster than hence KDE is faster than GNOME/XFCE4/{enter GTK+ applications}…blah…blah…blah?
I think such assertions are silly and unfounded, not to mention fallacious. If anything GTK+ have a much smaller foot print than their Qt counterpart. In all my life as coder, I’ve never seen applications, performing the similar functions, with a smaller memory footprint run slower than one with a larger one. In my experience, it’s always been the opposite.
Can we have valid discussions now?
Oh, ok. That’s what he meant. I tend to think of poor layouts as more of a usability issue rather than an asthetic one. Yeah, KDE does need to work on those things, though parts of KDE is better than others.
I have but one thing to say to this developer:
Truly we are not worthy.
KDE has completely outdone themselves with the 3.2.0 release. I have used KDE off and on since the KDE 1.4x days. When KDE hit 2.0, I would not touch it with a ten foot pole. It was just too slow for my hardware at the time. Even after I got new hardware I still wouldn’t use it because it felt too slow. It was not until the 3.1.x series that KDE was useably fast again, IMHO. But 3.2.0 has blown me completely out of the water.
It is not just the speed at which KDE runs now, but also the little extra added useability features they have thrown in this time. The Wallet, which remembers website passwords, chat passwords, and who knows what all else, gives Konqueror the same ease on password protected web sites that Mozilla has. Kontact is a complete work of art unto itself, having email, calendar, news, addressbook and user set rdf newsfeeds in one place is awfully nice. Kontact is so fast that you barely have time to view the splash screen before it opens.
Konqueror can now be set to stay loaded in memory at all times and appears instantly when clicked. Koffice is now using OpenOffice document filters, and can read and write to as many document formats as OpenOffice.
The KDE team has outdone themselves this time, and it is my opinion that KDE now spanks every other desktop up and down the street, Windows & Mac included. And I can still use DO_NOT_COMPILE to make sure the only apps I have installed are the ones I need. Those who would still like to say that KDE is bloated have simply not used 3.2.0. Please note I am not saying it is the best for everybody. What I am saying is it suits my needs perfectly.
I bow to the KDE developers. They have truly outdone themselves this time.
Hi
”
So tell me, for the love of reason, how anyone can blatantly conclude that Qt is faster than hence KDE is faster than GNOME/XFCE4/{enter GTK+ applications}…blah…blah…blah? ”
Yes. Gtk apps look and feel slow in comparision to qt apps because they have unnecessary double buffering which can be clearly seen on low memory systems with a large list view. even gtk developers agree on that like owen taylor.
kde 3.2 in comparision has actually got faster than the previous release. nautilus has taken a controversial path of switching to spatial mode thus having a speed gain in the potential expense of usability.
Jess
When does it sink in that the speed of an application is independent of tool kit and heavily dependent on the skill and knowledge of the programmer wielding their tools?
————
The speed of the *UI* is almost entirely dependent on the toolkit. Most apps are just widgets strung together. It doesn’t matter how fast the application is if the toolkit is the bottleneck. Take a look at Eric 3, the Python IDE. Eric 3. Its written in Python. On my machine, its UI performance (resize handling, expose handling, widget manipulation) is just as fast as any regular KDE app. Unless you use custom widgets (eg. KHTML), the application code is almost never the bottleneck.
PS> On my machine, KDE’s resize performance is actually better than XP’s. If you’ve got access to an XP box, try this. Open two IE windows to Slashdot. Maximize the lower window, and resize the top window continuously at a regular pace. The bottom window will be erased and not redrawn for several seconds at a time. On KDE 3.1.x, or KDE CVS, this does not happen with Konqueror.
Yes. Gtk apps look and feel slow in comparision to qt apps because they have unnecessary double buffering
GTK+ is slow because it uses double buffering? Do you know what you are talking about?
which can be clearly seen on low memory systems with a large list view. even gtk developers agree on that like owen taylor.
A link to your sources will be highly appreciated.
nautilus has taken a controversial path of switching to spatial mode thus having a speed gain in the potential expense of usability.
Spatial usage was a usability enhancement not an expense. Spacial mode wasn’t opted for speed reasons. Where did you get that from. Again, I’d appreciate you list your sources.
” On KDE 3.1.x, or KDE CVS, this does not happen with Konqueror. ”
Thank you so much. You said it far better, in fewer words, than I did.
The speed of the *UI* is almost entirely dependent on the toolkit.
Sure, but haven’t you seen badly coded UIs?
Most apps are just widgets strung together. It doesn’t matter how fast the application is if the toolkit is the bottleneck. Take a look at Eric 3, the Python IDE. Eric 3. Its written in Python. On my machine, its UI performance (resize handling, expose handling, widget manipulation) is just as fast as any regular KDE app. Unless you use custom widgets (eg. KHTML), the application code is almost never the bottleneck.
I disagree. If you have gnome-2.4.* installed. Install gpdf and try opening a pdf and then resizing the window. Redraws and lag are clearly visible both when resizing the window and when rendering pages. I haven’t bordered to check why that is happening both clearly the developers must be doing something awkward.
In fact on my box, 1.4GHz Athlon and 256MB RAM, gpdf is the only gtk+ application where I see redraws, rendering and resize issues. Even OpenOffice.org doesn’t have visible resize issues or lags. I’m written this comment from a GNOPPIX liveCD, the system has 256MB of RAM, and Mozilla does not display any lag or resize issues.
So I am positive UI performance, if that is what we are alluding to as fast/slow as opposed to application performance, is heavily depended on how attention much developers pay to it and not on tool kit. And you can’t because of that allude that Qt is automatically faster than GTK+ when you and I now that each application does it’s own weird thing.
On a per application level, I agree that some application UI are slower than others, but I’m confident it has nothing to do with tool kit speed, at least in this case GTK+ / Qt. I still find XFCE4 more responsive than KDE-3.2 and GNOME-2.4.*. Has that got anything to do with GTK+ or Qt? Afterall, XFCE4 uses GTK+.
“Redraws and lag are clearly visible both when resizing the window and when rendering pages. I haven’t bordered to check why that is happening both clearly the developers must be doing something awkward.”
No they are not. Gnome is still in 2.x. When Gnome hits 3.x, all of these things will change.
No they are not. Gnome is still in 2.x. When Gnome hits 3.x, all of these things will change.
No? What things are we talking about? And why are these things changing when GNOME hits 3.x?
I’d like some more info about this too
Sure, but haven’t you seen badly coded UIs?
———-
My point is that for most apps, you don’t code the UI. You strings together existing widgets. That’s why for most apps, it is the toolkit that is the bottleneck, not the application code. For example, one of my gripes is that when resizing columns in Rhythmbox, the operation lags behind the mouse pointer. No application code is involved in this operation, so how could it be the app’s fault?
I disagree.
——-
Just to be clear. You disagree that the toolkit is the bottleneck? Then how do you explain the fact that Eric 3 has a fast UI, despite being a *Python* app? There was some old research on MacOS that showed that apps spent 90% of their time inside the toolkit. I’d presume that GTK+/Qt apps spend similarly high amounts of time inside the toolkit.
Redraws and lag are clearly visible both when resizing the window and when rendering pages. I haven’t bordered to check why that is happening both clearly the developers must be doing something awkward.
————
The developers needn’t be doing anything awkward. Rendering PDF is fairly slow, so it makes sense that there would be lag during rendering. What doesn’t make sense is lag during resize — its simply the matter of blitting the already-existing pixmap. For reference, on my machine, the resize lag of gpdf is atrocious. kpdf doesn’t show any lag at all during resizing. This is interesting to note — both use the xpdf rendering engine, and as expected, both display similar speed for rendering. So the bottleneck during resize is either in the GPDF code, or GTK+. Considering that displaying a pixmap rendered by the engine is a relatively easy task, where do you really think it is more likely that the bottleneck lies?
In fact on my box, 1.4GHz Athlon and 256MB RAM, gpdf is the only gtk+ application where I see redraws, rendering and resize issues. Even OpenOffice.org doesn’t have visible resize issues or lags.
———–
What? I’m trying this on Firefox 0.8 right now, opened to Slashdot. Resizing causes there to be a giant gray border where the window contents lag behind the window frame. Moving another Firefox window over the first causes streaks of the old window to remain. And OpenOffice just plan doesn’t resize properly — basically it leaves a trail of window frame streaked behind until its done resizing. This is to be expected. Both Mozilla and OpenOffice use their own, slow, toolkits.
And you can’t because of that allude that Qt is automatically faster than GTK+ when you and I now that each application does it’s own weird thing.
———-
Well, the OpenOffice and Mozilla examples don’t prove anything — neither of them are GTK+ apps. It just proves that its possible to code slow toolkits, which I don’t doubt. The thing is, that pretty much every Qt/KDE app I’ve ever used is fast with respect to resize/redraw handling. And I’ve never seen a GTK+ app that is as fast, with respect to redraw/resize, as a good Qt app. It can hardly be the case that all the “g” app developers are doing something wrong, where all the “k” app developers are doing something right.
Has that got anything to do with GTK+ or Qt? Afterall, XFCE4 uses GTK+.
———
I find XFCE4 to be much less responsive (with respect to redraw/resize) than KDE. For example, compare resizing the XFCE “control panel” to KDE’s control panel. Nothing lags with KDE’s control panel, while XFCE’s is very laggy.
Is Rayiner Hashem always right or does he just write long, convincing but totally false answers?
Someone tell me111!
hehe
There’s no doubt that Gtk 2.x has redraw issues compared to QT. Hey, at least he’s not on one of his Lisp rants 😉
My point is that for most apps, you don’t code the UI. You strings together existing widgets. That’s why for most apps, it is the toolkit that is the bottleneck, not the application code. For example, one of my gripes is that when resizing columns in Rhythmbox, the operation lags behind the mouse pointer. No application code is involved in this operation, so how could it be the app’s fault?
Yes, the UI is strung together. But there are several ways to string the widgets together. If you don’t know what you are doing, and what function to use and which to avoid based on experience, it is easy to write Uis that are slow and sluggish. Again, this is absolutely dependent on the application, or if you insist UI, developer not on the tool kit, I gave gpdf as an example.
With regards to the tree widget resizing issue, this was a well known bug which has been fixed in GTK+2.3.* the last time I checked. In fact, developers familiar with GTK+ wrote hacks to prevent the issue in some application, but that broke a lot of stuff so it was reverted.
Then how do you explain the fact that Eric 3 has a fast UI, despite being a *Python* app?
Eric has a fast UI because it’s developers coded it well, period. If I’m not familiar with the whatever toolkit they used, I could chances are my Apps UI might not be as responsive. Java is usually acknowledged to be a horridly slow and sluggish language. Yet when I saw the Looking Glass demo, I hardly saw lags, expose issues or resize issues with windows. Now I don’t know what toolkit was used to develop Looking Glass but I’m betting it’s one of the ones our regular osnews audience regard as slow. Again, nothing to do with tool kit, everything to do with developers.
There was some old research on MacOS that showed that apps spent 90% of their time inside the toolkit. I’d presume that GTK+/Qt apps spend similarly high amounts of time inside the toolkit.
Yes, all the graphic toolkits I know are reside in an event driven loop.
The developers needn’t be doing anything awkward. Rendering PDF is fairly slow, so it makes sense that there would be lag during rendering.
Acroreader renders a lot faster than gpdf on my box. Something awkward is going on. And, from the changelogs, I think it has been fixed in development releases of GNOME, but I’m not sure.
What doesn’t make sense is lag during resize — its simply the matter of blitting the already-existing pixmap. For reference, on my machine, the resize lag of gpdf is atrocious. kpdf doesn’t show any lag at all during resizing. This is interesting to note — both use the xpdf rendering engine, and as expected, both display similar speed for rendering.
In my experience, acroreader renders the fastest followed by xpdf, then kghoshtview, then kpdf and finally gpdf– which is obviously has issues. Again nothing to do with tool kits. I don’t know why kghostview renders pdfs fast than kpdf for example, but apparently, it has nothing to do with Qt.
So the bottleneck during resize is either in the GPDF code, or GTK+.
No other gnome application suffers as much lag, rendering problem and resize issue as gpdf does on my box. I doubt the problem is GTK+. Otherwise every other GTK+ application I’ve used should have such atrocities, like you put it.
Considering that displaying a pixmap rendered by the engine is a relatively easy task, where do you really think it is more likely that the bottleneck lies?
It’s not an issue of a bottleneck. GTK+ is not the bottleneck. It’s just not optimized code. Or poorly written code. It is easy to use a function, inadvertently, with a high overhead. Especially when there are several ways to code a given UI.
What? I’m trying this on Firefox 0.8 right now, opened to Slashdot. Resizing causes there to be a giant gray border where the window contents lag behind the window frame. Moving another Firefox window over the first causes streaks of the old window to remain
Don’t experience any of those on my box. Ironically, I find Firefox to be a whole lot more responsive than Mozilla is despite the fact that they use the same toolkit. I even find Firefox more responsive than IE is on windows. What are you system specs?
And OpenOffice just plan doesn’t resize properly — basically it leaves a trail of window frame streaked behind until its done resizing. This is to be expected. Both Mozilla and OpenOffice use their own, slow, toolkits
That’s unfortunate. I, however, noticed Mozilla and OpenOffice are faster on Windows than on Linux. As to the resize issue may be I’m just lucky, but I’m just not seeing it on my box. Using Mozilla, OpenOffice and Firefox is no different from using any other application. But I hardly move windows around or resize them. And when I do, I don’t experience any noticeable lags, except in some applications.
Well, the OpenOffice and Mozilla examples don’t prove anything — neither of them are GTK+ apps. It just proves that its possible to code slow toolkits, which I don’t doubt. The thing is, that pretty much every Qt/KDE app I’ve ever used is fast with respect to resize/redraw handling. And I’ve never seen a GTK+ app that is as fast, with respect to redraw/resize, as a good Qt app. It can hardly be the case that all the “g” app developers are doing something wrong, where all the “k” app developers are doing something right.
Unfortunately, not in my experience. I’ve seen Konqueror, Kmail, Ksirc, Kvirc with redraw and resize issues. And I’m probably forgeting a few other applications. In general, I don’t notice any speed difference between QT and GTK+ applications, except that they are smaller and they launch faster compared to their KDE counterpart. Again there is one exception Evolution. Kmail launches faster than Evolution. But Evolution has more functionality. That should be an excuse however. And that has nothing to do with tool kit.
i.Ifind XFCE4 to be much less responsive (with respect to redraw/resize) than KDE. For example, compare resizing the XFCE “control panel” to KDE’s control panel. Nothing lags with KDE’s control panel, while XFCE’s is very laggy. [/i]
My experience is the opposite. First of, I find XFCE4’s window manager to be a lot faster than GNOME’s or KDE. I also in general find XFCE4 to be more responsive than either of them.
Lastly, resize issue is not a function of speed of UI or application. I barely see such issues on my iMac. But in general, OS X is slower than GNOME or KDE in my experience. Resize issues might not be attributed to solely to tool kit. There may be several other causes. The themes you use. Your hardware spec. The window manager being silly, among other factors. GTK+ is not slow. At least until anyone uses me scientific benchmarks, I’ll continue to consider it a myth and an appeal to hearsay.
Interesting thread, I think the issue here is how a given window handles a ConfigureNotify event during a resize.
The lag you see during a resize is constant for all apps like Mozilla, Konqueror or Nautilus. The variable or semi-variable is the code written to paint the contents of the window. Each app or toolkit has its own algorithm walking the event list and taking only the latest event necessary to produce the quickest response.
UI rendering is also dependent on toolkit/application developers. If they are aware of the issues surrounding event handling then they will code algorithms necessary to fix the delay.
Your comments are interesting, but could you please use italics or something else more clear when you quote other people? Using dashes as you do right now get quite confusing to know what’s quote and what’s response.
A lot of programs subclass the user interface.
This way, you “extend” the toolkit with your own code, and then you can make it slow.
On the other hand, the biggest problem with most applications is that they aren’t multithreaded.
A golden rule I always use is: GUI goes in its own thread, all the other code in other threads.
> I saw somewhere that there is activity to integrate OpenOffice.
You saw it at http://kde.openoffice.org/
> Wonder what those thousands of ISV apps are (that do not show up on http://kde-apps.org/).
http://kde-apps.org only lists OpenSource software. Most of these ISV apps, if they are available in the general marketplace, are not OpenSource.
I’ll have to agree with Rod concerning the dashes.
> http://kde-apps.org/
…
> are not OpenSource
Just curious how you could link from non-opensource code to KDE(GPL)?
> Just curious how you could link from non-opensource code
> to KDE(GPL)?
KDE librares are LGPL’d, making it absolutely OK and trivial to link to them from closed source apps. Qt is multiply licensed, under the GPL, QPLv2 (under UNIX) and a commercial license which is offered on a per-developer fee (not a royalty).
hope that helps answer your question =)
“root”, whatever your real name is ;-), you are talking about several things at once and confusing them all together. you are correct that the toolkit does not affect over-all performance of an application, and that there are several things the app’s developer(s) can do to make it better or worse. however, toolkits not only provide tools for app developers to use (and therefore make their apps better or worse) but also do handle a lot of the low level grunt work. i would hesitate to look at Qt as KDE’s toolkit, however; it is one PART of a much larger toolkit, albeit an important one. that much larger toolkit enables optimizations to be shared across all KDE apps and allows application developers to make fewer bad decisions.
i suppose what i’m saying is, you’re right and you’re not right, mostly because you’re discussing several things at once which i’m not sure you fully understand. but that’s what web boards are for, right? 😉
here’s my favourite nugget of yours, though:
“I’ve never seen applications, performing the similar functions, with a smaller memory footprint run slower than one with a larger one. In my experience, it’s always been the opposite.”
i couldn’t help but chuckle. ok. here’s the obvious example: in-memory database versus on disk database. traditionally the in-memory database will result in a larger memory footprint but will be wildly faster. and yes, this is commonly seen on the desktop.
example: ksycoca, which is an in-memory cache of the .desktop files available (mimetypes, kparts, plugins, menu structures, etc). this results in a memory footprint larger than if it KDE just hit the disk all the time whenever it needed to discover such things as “which application should i use to open up this spreadsheet?”. the memory footprint is ultimately extremeley trivial, but it is larger, and it is faster.
“No they are not. Gnome is still in 2.x. When Gnome hits 3.x, all of these things will change.”
“No? What things are we talking about? And why are these things changing when GNOME hits 3.x?”
I don’t have one shred of evidence to back up that statement and freely admit I mistated what I meant. I should have said, I predict, whatever glitches are in the toolkit now, will be cleared up by the time Gnome hits 3.x. I have no evidence, but I do have faith in the Gnome developers, just as much as I do in the KDE developers. These people aren’t dummies, so I believe these temporary glitches will be straightened out, even though I currently am completely sold on KDE and don’t have Gnome installed.