Working on a set of presentations for a corporate project, Sebastian and I put together some content covering KDE and Plasma topics over the weekend. We thought it would be cool to share some of the results with you. Note that the slides are not designed for use at a conference (too much text and rather brief) but rather as an aide to introducing technical management type people to some of the key concepts.
I should probably upload the screencast to Youtube.com so that people can find it there as well. There is also no cheesy outro music or many highly technical details as my screencasts often have because it was meant for a management meeting. I did manage to throw one or two "inside jokes" in, such as the clock reference, but it's all pretty staid and maybe even a bit boring. Hopefully, however, it's useful.
You can at least get a glance (though at a low framerate due to the screencapture software) at the new applet handles. =)
Monday, September 29, 2008
Friday, September 26, 2008
strawmen and learning from history
A strawman argument is when you create a set of claims that nobody is actually endorsing and then prove them wrong, thereby "proving" your own position. It's not sound reasoning and pretty lame when it happens.
The ability to learn from history prevents one from repeating the same mistakes in the same way. Ignore history and run the probability of making the same mistakes those before you did. After all, those mistakes were made by people probably as intelligent as you and likely with similar amounts of information. But history gives you an advantage in that it gives you, should you choose to take advantage of it, more information than those who made poor, though well intentioned or even seemingly wise at the time, decisions in the past.
Christian Schaller has blogged again about Phonon and GStreamer and sadly commits both of these sins.
First, he says:
He does say that English is not his first language and admits that maybe he misunderstood. Let me clear that up: he certainly did. Reading in any language requires reading full thoughts, not fragments of sentences.
Christan quotes me as saying, "Phonon is also more than just an option for Qt apps." but that is not what I wrote. Here's the original quote, unedited:
See how the period doesn't follow the words "apps"? No, it's a colon (:) and the sentence continues on for another whole phrase. My point was that if you are using Qt, then using Phonon is the best choice, not simply an option as Lennart had implied.
This makes Christian's original blog post on the matter, which was written in all sorts of poor form, a strawman. Nobody was making the claims he apparently based his statement on. But that mistake, once revealed, was not enough for Christian to gracefully back off. Instead, he says:
This too is a strawman argument. You see, Phonon uses what is available on the system. That's the whole point. So trying to make it out like Phonon actually extends your dependency graph when in reality it does the opposite is pure doublespeak. Or, as Stephen Colbert would put it, it's full of truthiness.
Christian goes on to say:
Evidently Christian is ignorant of the history of things here: aRts (not Arts, by-the-by) was, like GStreamer, a really good option in its day but once written to aRts you were stuck using aRts. aRts, also like GStreamer, did much of the heavy lifting such as tying into codecs for decoding. Phonon is a thin layer above the realm that GStreamer (and once upon a time, aRts) lives in preventing KDE apps from running into the same problems we did in the past: our media playback only worked where aRts was installed, and when we looked beyond aRts we had to rewrite code. Phonon solves both those future oriented issues, and today many users of Phonon apps actually use GStreamer.
Of course, if you think that GStreamer is installed or even works everywhere, you are vastly deluded. I know many Linux users for whom GStreamer simply doesn't work. Thankfully for most it does. And lets not even get into the absurdity of it all by wondering out loud just how many Mac users have GStreamer raring to go.
Phonon works in those situations as well. Today. Without us writing any new code.
Christian continued:
This is another strawman. I'm not making Phonon out to be a universal wonder solution: it's the right solution for apps written with Qt or KDE, so much so that some people may even elect to write their app using Qt because of Phonon. This still doesn't make it a "universal wonder solution", and I'd highly appreciate it if Christian would stop putting such words into my mouth. It's poor form that even having English as a second language can't make an excuse for.
As for 'hating Arts (sic) or hating KDE' this again is a strawman. It's simply about representing Phonon accurately, or if you don't have the knowledge to do so then to be quiet about it altogether. It has nothing to do with hating anything, let alone KDE. In fact, I think it has a lot more to do with a blind love of GStreamer than hating anything.
Christian just can't stop erecting the strawmen though:
As I said in my original blog post on this matter, Phonon is not the right solution in all situations. I even gave an example: pro audio tools probably want to write to a lower layer directly. Once again, he's addressing a phantom argument that nobody is making.
So first some daming with faint praise and then an actually interesting point: is Phonon flawed in the same ways Christian feels wxWidgets is? Well, I think wxWidgets is not overly great due to its API not the "wrap native widgets" concept. Of course, those who use wxWidgets think its API is probably quite grand. Likewise, I find Phonon's API quite grand.
What is the user's experience with Phonon? It just works. For them it's a complete win.
What is the Qt developer's experience with Phonon? It feels natural, it integrates beautifully with the rest of the code and it future proofs their application development efforts.
What is the non-Qt developer's experience with Phonon? Irrelevant as they won't be using it.
And that, simply, is what matters. I don't care what Christian chooses to use hiself, but I do care when he makes unsubstantiated claims, false arguments and, for a reason only he can know, decides to dog the choices I and the community I belong to make. Remember, this did not start with me saying anything about GStreamer, but rather some pretty pointless statements being made by people involved with GStreamer about Phonon. You bet I'm going to correct those statements in as public a forum as they were originally made, and it's time they stepped back from trying to defend the indefensible with strawmen and other useless debatery.
The great irony here is that prior to KDE4, very very few KDE apps could use GStreamer at all and those that could did not default to it; while in the KDE4 era, all KDE apps can (and in many cases do) use GStreamer because we invested both serious amounts of money and time into making a Phonon GStreamer backend. You'd think they'd be happy, perhaps even congratulatory.
The ability to learn from history prevents one from repeating the same mistakes in the same way. Ignore history and run the probability of making the same mistakes those before you did. After all, those mistakes were made by people probably as intelligent as you and likely with similar amounts of information. But history gives you an advantage in that it gives you, should you choose to take advantage of it, more information than those who made poor, though well intentioned or even seemingly wise at the time, decisions in the past.
Christian Schaller has blogged again about Phonon and GStreamer and sadly commits both of these sins.
First, he says:
"First of all my original blog post was in direct response to a claim by Aaron that Phonon was a good choice also for non-Qt developers doing cross platform applications." - Christian
He does say that English is not his first language and admits that maybe he misunderstood. Let me clear that up: he certainly did. Reading in any language requires reading full thoughts, not fragments of sentences.
Christan quotes me as saying, "Phonon is also more than just an option for Qt apps." but that is not what I wrote. Here's the original quote, unedited:
"Phonon is also more than just an option for Qt apps: you'd be making a huge mistake not to use it." - me
See how the period doesn't follow the words "apps"? No, it's a colon (:) and the sentence continues on for another whole phrase. My point was that if you are using Qt, then using Phonon is the best choice, not simply an option as Lennart had implied.
This makes Christian's original blog post on the matter, which was written in all sorts of poor form, a strawman. Nobody was making the claims he apparently based his statement on. But that mistake, once revealed, was not enough for Christian to gracefully back off. Instead, he says:
"Sure you ‘don’t get a hard dependency on any one multimedia system’ with Phonon, but you do get a dependency on Phonon and its dependencies instead."
This too is a strawman argument. You see, Phonon uses what is available on the system. That's the whole point. So trying to make it out like Phonon actually extends your dependency graph when in reality it does the opposite is pure doublespeak. Or, as Stephen Colbert would put it, it's full of truthiness.
Christian goes on to say:
"Aaron also repeated the oft heard argument that Phonon is for KDE about not repeating the mistakes of Arts. And I guess this is one of the big differences in perception. Because for Aaron for KDE to have used GStreamer would have been repeating Arts, but for me Phonon is repeating the Arts story."
Evidently Christian is ignorant of the history of things here: aRts (not Arts, by-the-by) was, like GStreamer, a really good option in its day but once written to aRts you were stuck using aRts. aRts, also like GStreamer, did much of the heavy lifting such as tying into codecs for decoding. Phonon is a thin layer above the realm that GStreamer (and once upon a time, aRts) lives in preventing KDE apps from running into the same problems we did in the past: our media playback only worked where aRts was installed, and when we looked beyond aRts we had to rewrite code. Phonon solves both those future oriented issues, and today many users of Phonon apps actually use GStreamer.
Of course, if you think that GStreamer is installed or even works everywhere, you are vastly deluded. I know many Linux users for whom GStreamer simply doesn't work. Thankfully for most it does. And lets not even get into the absurdity of it all by wondering out loud just how many Mac users have GStreamer raring to go.
Phonon works in those situations as well. Today. Without us writing any new code.
Christian continued:
"Back in the day if one dared to take issue about any of the wonderous claims made about Arts one got tons of comments about just being partisan and ‘hating Arts or hating KDE’. Kinda like how it is today when one tries to point out that Phonon is not the universal wonder solution that Aaron likes to paint it as."
This is another strawman. I'm not making Phonon out to be a universal wonder solution: it's the right solution for apps written with Qt or KDE, so much so that some people may even elect to write their app using Qt because of Phonon. This still doesn't make it a "universal wonder solution", and I'd highly appreciate it if Christian would stop putting such words into my mouth. It's poor form that even having English as a second language can't make an excuse for.
As for 'hating Arts (sic) or hating KDE' this again is a strawman. It's simply about representing Phonon accurately, or if you don't have the knowledge to do so then to be quiet about it altogether. It has nothing to do with hating anything, let alone KDE. In fact, I think it has a lot more to do with a blind love of GStreamer than hating anything.
Christian just can't stop erecting the strawmen though:
"I am taking issue with the promotion of Phonon as a better solution than just using GStreamer for a lot of specific use cases including cross-platform development. "
As I said in my original blog post on this matter, Phonon is not the right solution in all situations. I even gave an example: pro audio tools probably want to write to a lower layer directly. Once again, he's addressing a phantom argument that nobody is making.
"The strength of Phonon lies in providing a familiar API to existing Qt developers, giving them access to some limited multimedia functionality, but in terms of promoting itself as a generic cross platform multimedia development API it falls down, Phonon is attempting to do what wxWidgets tries to do for GUI components, and I never thought it worked very well for wxWidgets either."
So first some daming with faint praise and then an actually interesting point: is Phonon flawed in the same ways Christian feels wxWidgets is? Well, I think wxWidgets is not overly great due to its API not the "wrap native widgets" concept. Of course, those who use wxWidgets think its API is probably quite grand. Likewise, I find Phonon's API quite grand.
What is the user's experience with Phonon? It just works. For them it's a complete win.
What is the Qt developer's experience with Phonon? It feels natural, it integrates beautifully with the rest of the code and it future proofs their application development efforts.
What is the non-Qt developer's experience with Phonon? Irrelevant as they won't be using it.
And that, simply, is what matters. I don't care what Christian chooses to use hiself, but I do care when he makes unsubstantiated claims, false arguments and, for a reason only he can know, decides to dog the choices I and the community I belong to make. Remember, this did not start with me saying anything about GStreamer, but rather some pretty pointless statements being made by people involved with GStreamer about Phonon. You bet I'm going to correct those statements in as public a forum as they were originally made, and it's time they stepped back from trying to defend the indefensible with strawmen and other useless debatery.
The great irony here is that prior to KDE4, very very few KDE apps could use GStreamer at all and those that could did not default to it; while in the KDE4 era, all KDE apps can (and in many cases do) use GStreamer because we invested both serious amounts of money and time into making a Phonon GStreamer backend. You'd think they'd be happy, perhaps even congratulatory.
Thursday, September 25, 2008
Linux audio layers
Lennart Poettering did a pretty good job of going through the various sound APIs on Linux, he even made a diagram. It shows just how varied and complex the soundscape on Linux is.
Unfortunately for his readers, Lennart started riffing in places when he probably should have stuck to the topics he's familiar with. Given that it's me talking here, you can probably guess what the topics included ... yep, Phonon and KNotify.
For Phonon, Lennart said, "Use GStreamer! (Unless your focus is only KDE in which cases Phonon might be an alternative.)" Lennart works with GStreamer, so he will naturally lean towards it, but this statement is incorrect on many levels.
Phonon has only a Qt dependency, so if you are using Qt it's an option; KDE doesn't come into play in that decision. Many of our KDE4 libraries are like that these days actually. Phonon is also more than just an option for Qt apps: you'd be making a huge mistake not to use it. You see, Phonon gets you equal and native support on Windows and Mac as well without the user having to install, say, GStreamer.
But what if you only care about Linux? Phonon integrates well with the rest of your Qt code, makes it far simpler to use the underlying engine, and will happily backend onto GStreamer where it exists. But it also allows the user, system administrator or system integrator decide to use something else besides GStreamer. Or, should GStreamer fall out of favour in the future on Linux, you won't have to rewrite your code.
For event notifications, Lennart said, "Use libcanberra, install your sound files according to the XDG Sound Theming/Naming Specifications! (Unless your focus is only KDE in which case KNotify might be an alternative although it has a different focus.)"
This is the classic "event notifications are about sound" mistake. KNotify is a generic notifications framework that lets you create notifications, in the abstract sense, and then let the framework sort out whether they should be played as sounds, logged to files, etc. Sound is just one aspect of notifications, and providing a centralized mechanism to manage notifications is a (excuse the pun) sound design.
Note also how Lennart used the phrase "Unless your focus is only KDE" twice. What does that actually mean? Honestly: nothing meaningful, though bordering on FUD. That phrase might literally mean (and I'm being gracious here) "If you are use KDE libraries to develop your application." (Yes, it's for Qt-only apps too, as we already know) But what many will probably read it as is this: "If you intend your application to be run only in a KDE desktop ..." That's just wrong ... those frameworks are for use with applications that use Qt and/or KDE libraries. No more, no less and nothing about what one's focus is.
This does bring us back to that blog entry from a few days back about clarifying the KDE brand: in this case it would've made Lennart's characterization of Phonon and Knotify less ambiguous (even if still inaccurate).
Lennart does point out a couple of shortcomings of KNotify: "However it does not support the XDG Sound Theming/Naming Specifications at this point, and also doesn't support caching or passing of event meta-data to an underlying sound system." The sound theme spec thing is a bit lame because it's a brand new spec (GNOME only recently picked it up in their release that was made today) and in typical xdg spec fashion is essentially documentation of one implementation. Others will likely follow, so give it time. The caching bit really has more to do with the sound subsystem, and passing of meta data down into the media layer isn't done either. So I do give him some points there; places we can improve KNotify.
Lennart later says, "Phonon and KNotify should only be used in KDE/Qt applications and only for high-level media playback, resp. simple audio notifications." This makes them sound like toys, and while I won't say that Phonon is what you'd want for a high end pro-audio engineering tool, if you look at apps like Amarok2 its pretty obvious that these libraries are rather above the "toy" status.
So when do you want to use Phonon? When you aren't doing high end pro-audio stuff and need to play audio or video (capture will be there soon as well, I see code in the experimental/ folder already) and you want it to work today and tomorrow on Linux, BSD, Solaris, Windows and Mac using the native facilities. Phonon alone may be reason enough to use Qt in your application, in fact, if only just for multimedia features in your application.
When do you want to use KNotify? When you are writing code that uses the KDE libraries and you want to notify the user of something.
To Lennart: you know a lot about audio on Linux. Thanks for your contributions to FOSS and those explanations on your blog of the various audio bits and knobbles in Linuxland. But do everyone a favor and stick to the parts you actually know: you'll look smarter when someone like me doesn't come along and correct you (so you win) and others won't be misled in a blind-leading-the-blind scenario (so your community wins). If you do want to write about Phonon or other Qt/KDE technologies on your blog, I'd be happy to field questions for you as part of your due diligence research.
Unfortunately for his readers, Lennart started riffing in places when he probably should have stuck to the topics he's familiar with. Given that it's me talking here, you can probably guess what the topics included ... yep, Phonon and KNotify.
For Phonon, Lennart said, "Use GStreamer! (Unless your focus is only KDE in which cases Phonon might be an alternative.)" Lennart works with GStreamer, so he will naturally lean towards it, but this statement is incorrect on many levels.
Phonon has only a Qt dependency, so if you are using Qt it's an option; KDE doesn't come into play in that decision. Many of our KDE4 libraries are like that these days actually. Phonon is also more than just an option for Qt apps: you'd be making a huge mistake not to use it. You see, Phonon gets you equal and native support on Windows and Mac as well without the user having to install, say, GStreamer.
But what if you only care about Linux? Phonon integrates well with the rest of your Qt code, makes it far simpler to use the underlying engine, and will happily backend onto GStreamer where it exists. But it also allows the user, system administrator or system integrator decide to use something else besides GStreamer. Or, should GStreamer fall out of favour in the future on Linux, you won't have to rewrite your code.
For event notifications, Lennart said, "Use libcanberra, install your sound files according to the XDG Sound Theming/Naming Specifications! (Unless your focus is only KDE in which case KNotify might be an alternative although it has a different focus.)"
This is the classic "event notifications are about sound" mistake. KNotify is a generic notifications framework that lets you create notifications, in the abstract sense, and then let the framework sort out whether they should be played as sounds, logged to files, etc. Sound is just one aspect of notifications, and providing a centralized mechanism to manage notifications is a (excuse the pun) sound design.
Note also how Lennart used the phrase "Unless your focus is only KDE" twice. What does that actually mean? Honestly: nothing meaningful, though bordering on FUD. That phrase might literally mean (and I'm being gracious here) "If you are use KDE libraries to develop your application." (Yes, it's for Qt-only apps too, as we already know) But what many will probably read it as is this: "If you intend your application to be run only in a KDE desktop ..." That's just wrong ... those frameworks are for use with applications that use Qt and/or KDE libraries. No more, no less and nothing about what one's focus is.
This does bring us back to that blog entry from a few days back about clarifying the KDE brand: in this case it would've made Lennart's characterization of Phonon and Knotify less ambiguous (even if still inaccurate).
Lennart does point out a couple of shortcomings of KNotify: "However it does not support the XDG Sound Theming/Naming Specifications at this point, and also doesn't support caching or passing of event meta-data to an underlying sound system." The sound theme spec thing is a bit lame because it's a brand new spec (GNOME only recently picked it up in their release that was made today) and in typical xdg spec fashion is essentially documentation of one implementation. Others will likely follow, so give it time. The caching bit really has more to do with the sound subsystem, and passing of meta data down into the media layer isn't done either. So I do give him some points there; places we can improve KNotify.
Lennart later says, "Phonon and KNotify should only be used in KDE/Qt applications and only for high-level media playback, resp. simple audio notifications." This makes them sound like toys, and while I won't say that Phonon is what you'd want for a high end pro-audio engineering tool, if you look at apps like Amarok2 its pretty obvious that these libraries are rather above the "toy" status.
So when do you want to use Phonon? When you aren't doing high end pro-audio stuff and need to play audio or video (capture will be there soon as well, I see code in the experimental/ folder already) and you want it to work today and tomorrow on Linux, BSD, Solaris, Windows and Mac using the native facilities. Phonon alone may be reason enough to use Qt in your application, in fact, if only just for multimedia features in your application.
When do you want to use KNotify? When you are writing code that uses the KDE libraries and you want to notify the user of something.
To Lennart: you know a lot about audio on Linux. Thanks for your contributions to FOSS and those explanations on your blog of the various audio bits and knobbles in Linuxland. But do everyone a favor and stick to the parts you actually know: you'll look smarter when someone like me doesn't come along and correct you (so you win) and others won't be misled in a blind-leading-the-blind scenario (so your community wins). If you do want to write about Phonon or other Qt/KDE technologies on your blog, I'd be happy to field questions for you as part of your due diligence research.
Wednesday, September 24, 2008
how personal freedom works
Warning!!! This post has nothing to do with KDE or technology. It's full of thoughts on personal freedom and other soft, gooey, social type stuff. Feel free to skip this entry if that's not your cup of tea. =)
The more people you know, the greater the odds are that you are going to know someone who is a complete jerk about things. It's a numbers game, really. So when you meet thousands of people a year and even more track you down on-line, it's pretty much guaranteed that such people will find you without you having to do much work at all. ;)
Every so often someone with a real crank on will start following me around the intarwebs posting their hallowed viewpoint on me. It seems to happen to everyone with an even moderately public profile. Usually they get stuck on one message and then post it consistently everywhere they can as some sort of therapeutic outpouring of their inner angst. Most people don't last more than a couple weeks at this, though I've had a couple of people with real commitment dog me for a year or more. It's annoying, but part of life. I have worked hard on being able to accept it, and then move on. I'm still working on it, but getting better at it over time.
I do make a somewhat easy target: besides being somewhat visible, I wear my heart on my sleeve and my mind on my .. uhm .. lapel (I guess that's where it would be if the heart is on the sleeve? ;). I don't often pull punches when it comes to what my thoughts are, and sometimes I'm actually *gasp* wrong. I spend a lot of time formulating my thoughts, so it's not a completely unearned allowance and I do try to keep my non-wrongness ratio high enough to remain respectable. Still .. I give the Angry People ample ammunition. Again, it's part of my life. I strive to accept it, and move on.
I do have one small personal policy, though: if you want to be irrational and stupid, do it somewhere other than my personal space. You can shout whatever you want from the hilltops if you wish, but you don't get to do it in my living room, my office, my blog or my inbox. I love debating and feeling out ideas and arguments that I don't agree with, but I don't have time for pointlessness.
(I have some books on my bookshelf that I utterly hate. Some of them are liberally sprinkled with notes in their margins expressing my counter-points to the author's positions. I think challenging one's self by assessing other viewpoints is important.)
So here's the $64,000 question of the day: is it censorship to delete comments from my blog that fall into the "pointless flame" category? Here's my answer:
No it's not. Censorship is when you go around removing things that are objectionable. I certainly don't hold with that concept, and so there's a lot of comments in my blog that I find quite objectionable, but objectionable material is often just another way of saying, "Ideas that run counter to my own thoughts that are expressed in a rather aggressive or even just uncomfortably open way."
When it comes to my personal space, and this blog is such a space, I'm not obliged to give people a soapbox for worthless and poorly intentioned shouting. That is part of my personal liberty, and is mirrored by your liberty as well: I do not expect you to grant me extraordinary privileges in your personal space, either.
As US Supreme Court Justice Oliver Wendell Holmes, Jr. once described the harm principle, which places a natural limit on our liberty, "The right to swing my fist ends where the other man’s nose begins." If you wish to disagree with my right to not let you swing your fist into my face, you can swing your fist at me from a distance in your own personal space in a show of great protest. See how it works?
Shared private spaces, such as planetkde.org or dot.kde.org, have the right to similar controls. Censorship must be avoided but filtering out vandalism is completely within the rights of the group whose private space it is.
The danger in putting limits of expression in shared private spaces is that the tyranny of the majority, something John Stuart Mill wrote about in "On Liberty" some 150 years ago, can all too easily set in. It is therefore vital for a community to come to a shared understanding, before crisis arrives, as to what the difference between vandalism of the shared space and merely objectionable expression is, and to ensure that that definition is conservative enough and respectful enough of future minority positions to avoid ever being twisted into simple censorship, especially censorship of convenience. (As in: "it's inconvenient to address that issue openly.")
In public spaces, which are by definition also shared, there is no room for managing content or expression outside of some very extreme situations (e.g. incitement to violence, or the "clear and present danger" principle might be one such situation; though even that needs to be treated extremely carefully). This is a fundamental difference between public and private (or personal) spaces, and is vital to preserving freedom in a society. Tyranny must not be allowed to find its way into either government or society's various majorities, and well protected public spaces are part of the solution.
Unfortunately, there are a lot of people who apparently don't quite understand how personal freedom and liberty works in a society with more than one person in it, or lack the ability to accurately discern the difference between a private and a public space. Some will try and raise the specter of censorship just because you won't let them verbally punch you in the face in your own home. There are public spaces for such behavior, though be aware that I'm not required to show up to participate. (An amazing natural answer to curtailing abuse!) In that public space the merit of your position can be weighed by one and all.
Alternatively one can raise the value of their input from worthless to objectionable (which has value, though retaining the dissident nature of the original content) and find private spaces opening up to your expression.
Why all this blathering about liberty and what not? This morning I deleted the same comment three times from my blog and ended up turning on moderation controls (temporarily, I hope) to manage the goofball who apparently feels it's their natural right to say anything they want in my space. I decided to spend my lunch time writing this entry as a (very small and not nearly as well thought out as it should be) bit of documentation as to how I feel these concepts work in a rational world. Freedom is very important to me, and I want to make it clear just where those weighty, and often difficult, lines exist for me.
Feel free to post your objectionable comments below; apologies for the moderation delay in advance. =/ However, I do understand that there is no moderation delay at all when you post on your own blog. ;)
The more people you know, the greater the odds are that you are going to know someone who is a complete jerk about things. It's a numbers game, really. So when you meet thousands of people a year and even more track you down on-line, it's pretty much guaranteed that such people will find you without you having to do much work at all. ;)
Every so often someone with a real crank on will start following me around the intarwebs posting their hallowed viewpoint on me. It seems to happen to everyone with an even moderately public profile. Usually they get stuck on one message and then post it consistently everywhere they can as some sort of therapeutic outpouring of their inner angst. Most people don't last more than a couple weeks at this, though I've had a couple of people with real commitment dog me for a year or more. It's annoying, but part of life. I have worked hard on being able to accept it, and then move on. I'm still working on it, but getting better at it over time.
I do make a somewhat easy target: besides being somewhat visible, I wear my heart on my sleeve and my mind on my .. uhm .. lapel (I guess that's where it would be if the heart is on the sleeve? ;). I don't often pull punches when it comes to what my thoughts are, and sometimes I'm actually *gasp* wrong. I spend a lot of time formulating my thoughts, so it's not a completely unearned allowance and I do try to keep my non-wrongness ratio high enough to remain respectable. Still .. I give the Angry People ample ammunition. Again, it's part of my life. I strive to accept it, and move on.
I do have one small personal policy, though: if you want to be irrational and stupid, do it somewhere other than my personal space. You can shout whatever you want from the hilltops if you wish, but you don't get to do it in my living room, my office, my blog or my inbox. I love debating and feeling out ideas and arguments that I don't agree with, but I don't have time for pointlessness.
(I have some books on my bookshelf that I utterly hate. Some of them are liberally sprinkled with notes in their margins expressing my counter-points to the author's positions. I think challenging one's self by assessing other viewpoints is important.)
So here's the $64,000 question of the day: is it censorship to delete comments from my blog that fall into the "pointless flame" category? Here's my answer:
No it's not. Censorship is when you go around removing things that are objectionable. I certainly don't hold with that concept, and so there's a lot of comments in my blog that I find quite objectionable, but objectionable material is often just another way of saying, "Ideas that run counter to my own thoughts that are expressed in a rather aggressive or even just uncomfortably open way."
When it comes to my personal space, and this blog is such a space, I'm not obliged to give people a soapbox for worthless and poorly intentioned shouting. That is part of my personal liberty, and is mirrored by your liberty as well: I do not expect you to grant me extraordinary privileges in your personal space, either.
As US Supreme Court Justice Oliver Wendell Holmes, Jr. once described the harm principle, which places a natural limit on our liberty, "The right to swing my fist ends where the other man’s nose begins." If you wish to disagree with my right to not let you swing your fist into my face, you can swing your fist at me from a distance in your own personal space in a show of great protest. See how it works?
Shared private spaces, such as planetkde.org or dot.kde.org, have the right to similar controls. Censorship must be avoided but filtering out vandalism is completely within the rights of the group whose private space it is.
The danger in putting limits of expression in shared private spaces is that the tyranny of the majority, something John Stuart Mill wrote about in "On Liberty" some 150 years ago, can all too easily set in. It is therefore vital for a community to come to a shared understanding, before crisis arrives, as to what the difference between vandalism of the shared space and merely objectionable expression is, and to ensure that that definition is conservative enough and respectful enough of future minority positions to avoid ever being twisted into simple censorship, especially censorship of convenience. (As in: "it's inconvenient to address that issue openly.")
In public spaces, which are by definition also shared, there is no room for managing content or expression outside of some very extreme situations (e.g. incitement to violence, or the "clear and present danger" principle might be one such situation; though even that needs to be treated extremely carefully). This is a fundamental difference between public and private (or personal) spaces, and is vital to preserving freedom in a society. Tyranny must not be allowed to find its way into either government or society's various majorities, and well protected public spaces are part of the solution.
Unfortunately, there are a lot of people who apparently don't quite understand how personal freedom and liberty works in a society with more than one person in it, or lack the ability to accurately discern the difference between a private and a public space. Some will try and raise the specter of censorship just because you won't let them verbally punch you in the face in your own home. There are public spaces for such behavior, though be aware that I'm not required to show up to participate. (An amazing natural answer to curtailing abuse!) In that public space the merit of your position can be weighed by one and all.
Alternatively one can raise the value of their input from worthless to objectionable (which has value, though retaining the dissident nature of the original content) and find private spaces opening up to your expression.
Why all this blathering about liberty and what not? This morning I deleted the same comment three times from my blog and ended up turning on moderation controls (temporarily, I hope) to manage the goofball who apparently feels it's their natural right to say anything they want in my space. I decided to spend my lunch time writing this entry as a (very small and not nearly as well thought out as it should be) bit of documentation as to how I feel these concepts work in a rational world. Freedom is very important to me, and I want to make it clear just where those weighty, and often difficult, lines exist for me.
Feel free to post your objectionable comments below; apologies for the moderation delay in advance. =/ However, I do understand that there is no moderation delay at all when you post on your own blog. ;)
shortcuts design .. by blog! =)
When KDE people find a problem, they tend to latch onto it like a pitbull with a new chew toy and pound the thing into submission with pragmatic design. Michael's been blogging about global shortcuts, approaching it that oh-so-KDE-fashion. Gotta love it. Since he blogged about making global shortcuts work with apps like Plasma, I figured I'd reply in my blog.
Design-by-blog, the brave new future! Well, we've also talked at length about it on IRC and on mailing lists, too .. so we're not quite in danger of ending up designing KDE by SMS messages yet ;)
Anyways ... Michael suggests the idea of application contexts for shortcuts, and that would be absolutely perfect for Plasma. As software becomes more flexible, more user-maleable (which is different than configurable), I think more and more of our software will end up having to think of things in terms of "contexts".
Mike ran through how Plasma, in the simple case, works right now:
This isn't quite how it works right now, though. Here's what we do:
This isn't perfect, but contexts should resolve our remaining issues nicely and Plasma could then play even nicer with the rest of the desktop session. The remaining question will be when to call forgetGlobalShortcut, and I think the answer is that with contexts in place we'd be able to limit that to widget removal or widget layout exportation.
And yes, this has got to be one my least interesting blog entries in a while. =) Now all of you who read this know what kind of fun and crazy life I lead on the mailing lists. ;)
Design-by-blog, the brave new future! Well, we've also talked at length about it on IRC and on mailing lists, too .. so we're not quite in danger of ending up designing KDE by SMS messages yet ;)
Anyways ... Michael suggests the idea of application contexts for shortcuts, and that would be absolutely perfect for Plasma. As software becomes more flexible, more user-maleable (which is different than configurable), I think more and more of our software will end up having to think of things in terms of "contexts".
Mike ran through how Plasma, in the simple case, works right now:
"So let's see what is needed for plasma to work correctly. If an applet is added to an containment register the global shortcut. If you have no id to use create one. QUuid is very helpful in that regard as demonstrated by khotkeys. Associate the id with your applet. Optionally write the current set shortcut to disk after calling setGlobalShortcut() with the id. The shortcut you want is probably not the shortcut you get if the user configured it with the global shortcuts kcm. A choice you currently ignore and change back to whatever you have stored in your configuration."
This isn't quite how it works right now, though. Here's what we do:
- Each widget/applet has a unique ID
- If a shortcut is associated with a widget, we load it from the appletsrc file
- That shortcut gets registered, and right now we just force it (related to current shortcomings that contexts should fix for us)
- If the user changes the configuration, the shortcut action is told about this by the shortcuts kded module
- That shortcut gets written out to the appletsrc for usage in the future
- The shortcut is unregistered (via forgetGlobalShortcut()) when the widget goes away, which can happen when the user removes the widget, swaps layouts or just quits plasma (all three behaviours are quite different)
This isn't perfect, but contexts should resolve our remaining issues nicely and Plasma could then play even nicer with the rest of the desktop session. The remaining question will be when to call forgetGlobalShortcut, and I think the answer is that with contexts in place we'd be able to limit that to widget removal or widget layout exportation.
And yes, this has got to be one my least interesting blog entries in a while. =) Now all of you who read this know what kind of fun and crazy life I lead on the mailing lists. ;)
Tuesday, September 23, 2008
problems, solutions ... and things that are already good
It is useful to be able to see problems where they exist. It's probably even more useful to see solutions to them. But it's also important to be able to see what's good, what works .. the positives in life, so to speak.
Given that my last blog entry was more of the "problems and a possible solution" sort, I figure a quickie with the "what's good" is called for to maintain balance in life. =) So here we go, things that are working well:
Ah, ballance restored. ;)
Given that my last blog entry was more of the "problems and a possible solution" sort, I figure a quickie with the "what's good" is called for to maintain balance in life. =) So here we go, things that are working well:
- Planet KDE: the art team stepped up to create a beautiful new layout, the web team stepped up to implement it using Rawdog (ooh, ajaxy! ;) and the pragmatists came up with the obvious solution for the "we rely on only a couple guys to maintain the rss feed list": put the thing in svn so anyone with an svn account can maintain the blog roll! A truly class act on all fronts.
- KJots: I no longer use it as a stand-alone application, because now it works perfectly in Kontact! Multi-level notes, rich text formatting, links, exporting and printing and so much more .. all just an icon click away from my mail and calendar! Awesome!
- Folderview: Frederik's been at it again! Icon positions are saved (so you can move things around), align-to-grid is there, advanced filtering, speed-speed-speed and a handful of minor graphical improvements is going to make Plasma in KDE's 4.2 workspace all that much more impressive.
- Petri found a nice work around for a limitation in KConfigSkeleton that lets us use it properly with scripted widgets and has been making the Webkit plasmoids rock! (His work around is rather clean, actually, and obvious in retrospect, so it falls neatly into the "inspired" category. =)
- I slept well last night.
Ah, ballance restored. ;)
what does a "KDE app" mean?
Pet peeve #47: Assuming that "a KDE app" means "you have to be logged into KDE to use it".
We run into this misconception fairly regularly and it's understandable why from a historical perspective: KDE started out as a "desktop environment project". But come on ... we've only had a fairly clear distinction between desktop and applications for how many years now?
But wait .. it's not clear! Otherwise I wouldn't read stuff like this:
The article goes on to pimp Rhythmbox which is all well and good. Use what you want, I say. Make educated decisions and you'll come out further ahead, I also say: If you're suffering from "Amarok envy" and it's the use of KDE libraries that puts you off ... it's time for a re-think.
Let's take the author's complaints one point at a time:
So Amarok fits just fine, and does so on many platforms that are more exotically different from the KDE desktop than GNOME is. So why does this attitude persist?
It's tempting to just say, "Well, the person who wrote that article was obviously not qualified to write such an article." or "People who aren't down with the KDE project will grasp at any straw to make excuses for avoiding applications that run just fine elsewhere." There may even be shades of truth in there, but it's probably not the whole picture. Not only does it ascribe way too much actual intention to the probably honestly mistaken user, it avoids this bit of truth:
That is why marketing and communications exists as a discipline: to share with others in a convincing manner what your strengths are, what your unique points are, what your attributes are .. even what your weaknesses are.
So can we blame anyone but ourselves when people wander about saying and writing silly things like the above? No. Public perception starts with us. This does not mean it's a simple task, one we will always succeed at or one that can be accomplished in a day, a week or even a month. It's often a fairly arduous task that takes application over the long haul, but which in the end can be successful.
In this particular case, I believe we need to stop promoting the KDE desktop as "KDE". Now that we have a really solid application development platform, tons of applications (and application suites) that stand on their own as well as a desktop environment, it's no longer wise to keep the term "KDE" as a shorthand for "that thing you log into that the KDE team writes".
It's too confusing for the consumer, who gets tangled up in the distinction between desktop and applications. (In part, this happens because our integration is so terrific that it's obvious that these apps work well together, to the point that maybe they even require each other!) It gives people like the writer of the aforementioned article an excuse (and perhaps even a valid one) to further spread that confusion.
Quietly, I've been pushing for some changes here and there. At the beginning of this year, we changed the "What is KDE text", as can be seen in press releases and on kde.org: it used to say that KDE was a modern desktop environment, now it says that KDE is an international team that creates Free software. This change in language was not accidental.
Such subtleties are not enough, though. It's obvious and evident given the continued popular misconceptions about the relationship between the KDE workspace and KDE applications that it's not enough.
I've quietly floated a proposal to start using our public communication to make it much more clear where the lines are drawn. In particular, I want to see the KDE workspace marketed under it's own KDE sub-brand. Just as we have "Amarok" or "KOffice" as brands beneath the KDE umbrella (which is not the KDE workspace!), I want to see a brand for the KDE workspace applications so that we can refer to them as something distinct so as to clarify the waters around the meaning of "KDE". This can give us a base on which to build a clear and consistent set of lines around the dev platform (which probably also deserves a brand of its own), the workspace and the applications. They are all "KDE", they all work really well together, share so much technology with each other .. but are also separable and individually valuable pieces. The workspace itself really doesn't deserve to hog the name "KDE" to itself.
While these lines are all pretty obvious to most of us close to KDE, it's painfully obvious it isn't to the world just beyond our own village.
The Marketing Working Group have taken my proposal under consideration and have drafted a somewhat lengthy position proposition out of that proposal. I've been waiting for a bit to see it hit the light of day, though I must confess that every day that passes in which I read another article confusing "KDE" and "the KDE workspace" I grow a little more impatient.
We run into this misconception fairly regularly and it's understandable why from a historical perspective: KDE started out as a "desktop environment project". But come on ... we've only had a fairly clear distinction between desktop and applications for how many years now?
But wait .. it's not clear! Otherwise I wouldn't read stuff like this:
"Amarok sure inspires a lot of KDE-envy for Gnome users. Unfortunately, it doesn’t fit in well in Gnome: It’s written for a different desktop environment, uses a whole different toolkit, and requires a lot of extra libraries to run." - Free Software Magazine, article
The article goes on to pimp Rhythmbox which is all well and good. Use what you want, I say. Make educated decisions and you'll come out further ahead, I also say: If you're suffering from "Amarok envy" and it's the use of KDE libraries that puts you off ... it's time for a re-think.
Let's take the author's complaints one point at a time:
- "It’s written for a different desktop environment": no, it's not. It's written using libraries that come from the KDE project, Qt Software and a handful of other projects. It has nothing to do with a desktop environment, which is something you log into and not an application framework. If Firefox runs on Windows ... is it written for Windows? hmm....
- "uses a whole different toolkit": Sure does, and what's the problem with that? With Qt4, it blends rather seamlessly if you use the Qt4 Gtk theme style. Button order is even swapped on dialogs to fit in with GNOME's idea of proper button order. If you're worried about memory usage, unless you're suffering away on a machine with 256MB of RAM you're worried about all the wrongs things.
- "requires a lot of extra libraries to run": unlike Rhythmbox? *cough* Looking at Amarok's CMakeLists.txt it taps into taglib (very popuplar lib among various players), libgpod (which drags in glib and gdkpixbuf optionally), musicbrainz (Rhythmbox uses this, too), nepomuk, loudmouth, curl, libxml2, openssl ... in other words, stuff you probably already have on your system and of those you might not, are pretty tiny in and of themselves. The only exception to the tiny part would be the Qt and KDE libs, but having those around (and they aren't exactly huge in terms of disk space) opens up a lot of application options to you beyond even just Amarok.
So Amarok fits just fine, and does so on many platforms that are more exotically different from the KDE desktop than GNOME is. So why does this attitude persist?
It's tempting to just say, "Well, the person who wrote that article was obviously not qualified to write such an article." or "People who aren't down with the KDE project will grasp at any straw to make excuses for avoiding applications that run just fine elsewhere." There may even be shades of truth in there, but it's probably not the whole picture. Not only does it ascribe way too much actual intention to the probably honestly mistaken user, it avoids this bit of truth:
When it comes to public perception,
we hold our reputation in our own hand.
we hold our reputation in our own hand.
That is why marketing and communications exists as a discipline: to share with others in a convincing manner what your strengths are, what your unique points are, what your attributes are .. even what your weaknesses are.
So can we blame anyone but ourselves when people wander about saying and writing silly things like the above? No. Public perception starts with us. This does not mean it's a simple task, one we will always succeed at or one that can be accomplished in a day, a week or even a month. It's often a fairly arduous task that takes application over the long haul, but which in the end can be successful.
In this particular case, I believe we need to stop promoting the KDE desktop as "KDE". Now that we have a really solid application development platform, tons of applications (and application suites) that stand on their own as well as a desktop environment, it's no longer wise to keep the term "KDE" as a shorthand for "that thing you log into that the KDE team writes".
It's too confusing for the consumer, who gets tangled up in the distinction between desktop and applications. (In part, this happens because our integration is so terrific that it's obvious that these apps work well together, to the point that maybe they even require each other!) It gives people like the writer of the aforementioned article an excuse (and perhaps even a valid one) to further spread that confusion.
Quietly, I've been pushing for some changes here and there. At the beginning of this year, we changed the "What is KDE text", as can be seen in press releases and on kde.org: it used to say that KDE was a modern desktop environment, now it says that KDE is an international team that creates Free software. This change in language was not accidental.
Such subtleties are not enough, though. It's obvious and evident given the continued popular misconceptions about the relationship between the KDE workspace and KDE applications that it's not enough.
I've quietly floated a proposal to start using our public communication to make it much more clear where the lines are drawn. In particular, I want to see the KDE workspace marketed under it's own KDE sub-brand. Just as we have "Amarok" or "KOffice" as brands beneath the KDE umbrella (which is not the KDE workspace!), I want to see a brand for the KDE workspace applications so that we can refer to them as something distinct so as to clarify the waters around the meaning of "KDE". This can give us a base on which to build a clear and consistent set of lines around the dev platform (which probably also deserves a brand of its own), the workspace and the applications. They are all "KDE", they all work really well together, share so much technology with each other .. but are also separable and individually valuable pieces. The workspace itself really doesn't deserve to hog the name "KDE" to itself.
While these lines are all pretty obvious to most of us close to KDE, it's painfully obvious it isn't to the world just beyond our own village.
The Marketing Working Group have taken my proposal under consideration and have drafted a somewhat lengthy position proposition out of that proposal. I've been waiting for a bit to see it hit the light of day, though I must confess that every day that passes in which I read another article confusing "KDE" and "the KDE workspace" I grow a little more impatient.
non-usual events
I did the unusual thing of taking the weekend off. I even managed to get out all by myself for a more adult night on Saturday, something that becomes a cherished moment as a single parent. =) It was back to work today, though, feeling a bit more refreshed than when I went into the weekend. It was wonderfully easy to not touch a computer all weekend, so at least I'm addiction free still. ;)
In the same category of events (the non-usual), I'll be on an Internet show hosted by Marcel Gagne, a fellow I've known for a couple years now who has been a terrific F/OSS evangelist and supporter for much longer than that via his work efforts, his writing and his lobbying.
The show is hosted over at UStream.tv. Unfortunately it uses the nasty proprietary flash but it does provide video. Due to various limitations, I won't actually be appearing visually but will be audible. I'll be on the WTFL show live at 23:30 UTC tomorrow, Tuesday the 23rd. There's a live chat and what not which is fun, but if you can't make it live the shows are recorded and can be watched after the fact.
We will be talking mostly about F/OSS and it's socioeconomic impacts, though I'm sure a little KDE will slip in here and there. =)
In the same category of events (the non-usual), I'll be on an Internet show hosted by Marcel Gagne, a fellow I've known for a couple years now who has been a terrific F/OSS evangelist and supporter for much longer than that via his work efforts, his writing and his lobbying.
The show is hosted over at UStream.tv. Unfortunately it uses the nasty proprietary flash but it does provide video. Due to various limitations, I won't actually be appearing visually but will be audible. I'll be on the WTFL show live at 23:30 UTC tomorrow, Tuesday the 23rd. There's a live chat and what not which is fun, but if you can't make it live the shows are recorded and can be watched after the fact.
We will be talking mostly about F/OSS and it's socioeconomic impacts, though I'm sure a little KDE will slip in here and there. =)
playing with toys
Sometimes when working with oh so serious code, I get distracted by the oh so serious problems (which is all pretty humorous when I step back and consider just what makes it "oh so serious" ... it's rarely something like "feeding the starving children"). The result is that I'll happily work around the little limitations and outright problems in layers below the code I'm working on: my attention is too completely captured by the code at hand.
Which is why I find working with less important code that has obvious solutions to them, such as "toys", to be really useful. I can completely ignore what I'm doing (because it's neither hard nor exactly important) and get a real feel for the code beneath me.
Working on toys that other people have written on top of frameworks I'm at least in part to blame for is even more illuminating because I can see with painful clarity what isn't obvious to people writing stuff on top of my code. With other people's toys, there's little to obscure the design decisions and everything that isn't as simple as it could be is because I have failed in the framework.
So it was the other week when working on the Fifteen Pieces puzzle that I discovered just how non-obvious SVG usage is, how easy it is for people to get wrapped up in complexity that is completely ignorable in QGraphicsView (in this case a handful of methods were removed or consolidated into one small one which was triggered on resize events) and that we really need some simple tool to take a bitmap and turn it into an SVG with labeled IDs. QSvgGenerator is cloooose .. but not quite: it just turns QPainter calls into SVG objects, but doesn't seem to let one actually do things like set object IDs.
Moral of the story: play is an important learning mechanism for many species of animals, and humans are no different. =)
Which is why I find working with less important code that has obvious solutions to them, such as "toys", to be really useful. I can completely ignore what I'm doing (because it's neither hard nor exactly important) and get a real feel for the code beneath me.
Working on toys that other people have written on top of frameworks I'm at least in part to blame for is even more illuminating because I can see with painful clarity what isn't obvious to people writing stuff on top of my code. With other people's toys, there's little to obscure the design decisions and everything that isn't as simple as it could be is because I have failed in the framework.
So it was the other week when working on the Fifteen Pieces puzzle that I discovered just how non-obvious SVG usage is, how easy it is for people to get wrapped up in complexity that is completely ignorable in QGraphicsView (in this case a handful of methods were removed or consolidated into one small one which was triggered on resize events) and that we really need some simple tool to take a bitmap and turn it into an SVG with labeled IDs. QSvgGenerator is cloooose .. but not quite: it just turns QPainter calls into SVG objects, but doesn't seem to let one actually do things like set object IDs.
Moral of the story: play is an important learning mechanism for many species of animals, and humans are no different. =)
Thursday, September 18, 2008
digging in the dirt
"When a person puts their hands in the soil, they become connected to the world around them."
That was a word of wisdom I received from a mentor while working in his garden on a hot summer day. The underlying message was that being connected is something everyone needs, and so even if we can get by without getting our hands dirty we should do so anyways so that we don't lose our way and our place in this world.
This was a big lesson for someone like me: even as a child I often found myself living up in the clouds, thinking about big ideas in abstract terms. I found that the clouds were a beautiful place to be and should be visited as often as possible; but I also learned that you also need to till the soil to make the time spent up in the heavens worthwhile. Getting above the clouds releases your vision while putting your hands in the dirt below them keeps your values rooted and your foundational goals clear in mind.
While working on Plasma and "big thinking" stuff in and around the FOSS world (though to be honest, my "big thinking" stuff is a rather insignificant piece of the whole), I often find myself dancing up on the clouds: service oriented architectures that bridge local rich client software with "the cloud"; mixing in social/semantic systems with familiar user interface concepts; building a universal canvas that, like some demented Katamari ball, picks up support for everything in its path (Superkaramba, Webkit widgets, Dashboard widgets, Google Gadgets, Enlightenment 17 foundation libraries (Edje) ...), improving the workflow of collaborative design by simultaneously decoupling the disciplines and coordinating them (the whole DataEngine<->Visualizaiton<->Theming thing) ...
But not every day is like that. =)
Some days I get to look up to the sky and see the bottom of other people's feet. Today I got to watch Marco due some killer work on making the widget handles gorgeous (based on a mockup done by Nuno previously), the new PowerDevil stuff continue to mature (the battery widget can now control my screen's backlight! woo! ;) and Christian Mollekopf work on improving libtaskmanager with grouping and sorting ... while I worked on some rather unglamorous stuff.
Today was my turn to work the soil.
I merged Christian's libtaskmanager branch for a start. He's added a way to define sorting and grouping strategies for set of windows that allows one to create visualizations of windows, such as the taskbar, in fairly powerful arrangements. The strategies currently include sorting alphabetically or manually and grouping by program or manually. Other strategies can easily be added as well, and visualizations that use libtaskmanager can immediately take advantage of them without changing any of their code. The new work also more clearly separates the presentation of tasks from the management of them, in traditional Plasma form. Wonderful!
The tangible benefits of this are that we can provide a proper sorting and grouping taskbar without much additional effort. We will even be able to provide manual sorting and grouping, something people were asking for way back in KDE2 even. It's something I personally have no use for (I like the computer to do things for me, because I'm a lazy bastard with clouds to dance on), but I'm glad we finally have a good architecture upon which this is built on.
If things go as planned, Alain Boyer will be providing a Plasma::Service to interact with tasks so that widgets can take advantage of the controls provided by libtaskmanager without getting into the C++ world within.
Christian's libtaskmanager work builds on the work of Matthias Elter (holy KDE1 and KDE2 flashbacks! =) and Richard Moore (who is still very alive and involved in KDE to this day). It was Richard, if I recall correctly, who had originally the foresight to create libtaskmanager from code pulled out of Kicker's taskbar so we could share logic code between different visualizations.
After mergin Christian's branch, I spent much of my day cleaning headers, fixing licenses, straightening out APIs, organizing classes, removing old stuff. Lots of janitorial work, in other words.
One old thing I removed was the support for the non-composite-derived window thumbnails. This was something Richard added so we could have thumbnails in Kasbar (and eventually the kicker taskbar too, though). It was implemented as an embedded screen capture program: request a thumbnail for a window and a screen grab of the window would be taken and then resized. I remember playing with this in Kasbar years and years aog and thinking how cool that was! Slow and not perfect, but cool! How far we've come: now we have compositing window managers and KWin drops live previews directly into whatever window it is told to: fast, beautiful and cool.
Given our "no silly hacks" rule, Richard's feature felt the edge of the ax blade. It wasn't being used by any code in svn anymore anyways, and it keeps the API fresh and clean but still ... I could feel my nostalgia chord being tugged upon. =)
I then turned my attention to the Plasma tasks widget with an eye to performance issues. We were updating things far too often and the new Plasma::ToolTipManager which is responsible for those fancy floaty feedback windows when you mouse over things like the clock and taskbar buttons (written mostly by Alexis who just recently went to work for Qt Software) wasn't helping either. So I spent the rest of my day fixing ToolTipManager bugs of various sorts, adding code to TaskManager::Task to communicate precisely what has changed to the visualization and making the tasks widget take advantage of all that.
The result is that instead of updating every tooltip, including the ones that aren't even being shown, and every button every time the associated window changes in any way .. we only create and update the visible tooltip and only update the parts of the button that have actually changed. The tooltip improvement is the big win as that was a complex set of object allocations, assignments and deallocations, and if you had something like "only show tasks on this screen" turned on .. well .. it was happening for every few pixels you dragged the window. Holy moly! Thankfully it's pretty efficient code, but doing nothing is still more efficient than doing something efficiently.
There were other things I got busy with in between as well, little weeds in the garden that I stumbled upon while tending the plants, if you will. But that was pretty much my day .. and it felt great. Simple, accomplishable tasks with immediate benefit and practical use.
After a couple weeks working more in the stratosphere, I feel re-connected with the reality of what we're doing and a little less lost-in-the-clouds. Not to worry ,though, I'm heading back skywards tomorrow.
That was a word of wisdom I received from a mentor while working in his garden on a hot summer day. The underlying message was that being connected is something everyone needs, and so even if we can get by without getting our hands dirty we should do so anyways so that we don't lose our way and our place in this world.
This was a big lesson for someone like me: even as a child I often found myself living up in the clouds, thinking about big ideas in abstract terms. I found that the clouds were a beautiful place to be and should be visited as often as possible; but I also learned that you also need to till the soil to make the time spent up in the heavens worthwhile. Getting above the clouds releases your vision while putting your hands in the dirt below them keeps your values rooted and your foundational goals clear in mind.
While working on Plasma and "big thinking" stuff in and around the FOSS world (though to be honest, my "big thinking" stuff is a rather insignificant piece of the whole), I often find myself dancing up on the clouds: service oriented architectures that bridge local rich client software with "the cloud"; mixing in social/semantic systems with familiar user interface concepts; building a universal canvas that, like some demented Katamari ball, picks up support for everything in its path (Superkaramba, Webkit widgets, Dashboard widgets, Google Gadgets, Enlightenment 17 foundation libraries (Edje) ...), improving the workflow of collaborative design by simultaneously decoupling the disciplines and coordinating them (the whole DataEngine<->Visualizaiton<->Theming thing) ...
But not every day is like that. =)
Some days I get to look up to the sky and see the bottom of other people's feet. Today I got to watch Marco due some killer work on making the widget handles gorgeous (based on a mockup done by Nuno previously), the new PowerDevil stuff continue to mature (the battery widget can now control my screen's backlight! woo! ;) and Christian Mollekopf work on improving libtaskmanager with grouping and sorting ... while I worked on some rather unglamorous stuff.
Today was my turn to work the soil.
I merged Christian's libtaskmanager branch for a start. He's added a way to define sorting and grouping strategies for set of windows that allows one to create visualizations of windows, such as the taskbar, in fairly powerful arrangements. The strategies currently include sorting alphabetically or manually and grouping by program or manually. Other strategies can easily be added as well, and visualizations that use libtaskmanager can immediately take advantage of them without changing any of their code. The new work also more clearly separates the presentation of tasks from the management of them, in traditional Plasma form. Wonderful!
The tangible benefits of this are that we can provide a proper sorting and grouping taskbar without much additional effort. We will even be able to provide manual sorting and grouping, something people were asking for way back in KDE2 even. It's something I personally have no use for (I like the computer to do things for me, because I'm a lazy bastard with clouds to dance on), but I'm glad we finally have a good architecture upon which this is built on.
If things go as planned, Alain Boyer will be providing a Plasma::Service to interact with tasks so that widgets can take advantage of the controls provided by libtaskmanager without getting into the C++ world within.
Christian's libtaskmanager work builds on the work of Matthias Elter (holy KDE1 and KDE2 flashbacks! =) and Richard Moore (who is still very alive and involved in KDE to this day). It was Richard, if I recall correctly, who had originally the foresight to create libtaskmanager from code pulled out of Kicker's taskbar so we could share logic code between different visualizations.
After mergin Christian's branch, I spent much of my day cleaning headers, fixing licenses, straightening out APIs, organizing classes, removing old stuff. Lots of janitorial work, in other words.
One old thing I removed was the support for the non-composite-derived window thumbnails. This was something Richard added so we could have thumbnails in Kasbar (and eventually the kicker taskbar too, though). It was implemented as an embedded screen capture program: request a thumbnail for a window and a screen grab of the window would be taken and then resized. I remember playing with this in Kasbar years and years aog and thinking how cool that was! Slow and not perfect, but cool! How far we've come: now we have compositing window managers and KWin drops live previews directly into whatever window it is told to: fast, beautiful and cool.
Given our "no silly hacks" rule, Richard's feature felt the edge of the ax blade. It wasn't being used by any code in svn anymore anyways, and it keeps the API fresh and clean but still ... I could feel my nostalgia chord being tugged upon. =)
I then turned my attention to the Plasma tasks widget with an eye to performance issues. We were updating things far too often and the new Plasma::ToolTipManager which is responsible for those fancy floaty feedback windows when you mouse over things like the clock and taskbar buttons (written mostly by Alexis who just recently went to work for Qt Software) wasn't helping either. So I spent the rest of my day fixing ToolTipManager bugs of various sorts, adding code to TaskManager::Task to communicate precisely what has changed to the visualization and making the tasks widget take advantage of all that.
The result is that instead of updating every tooltip, including the ones that aren't even being shown, and every button every time the associated window changes in any way .. we only create and update the visible tooltip and only update the parts of the button that have actually changed. The tooltip improvement is the big win as that was a complex set of object allocations, assignments and deallocations, and if you had something like "only show tasks on this screen" turned on .. well .. it was happening for every few pixels you dragged the window. Holy moly! Thankfully it's pretty efficient code, but doing nothing is still more efficient than doing something efficiently.
There were other things I got busy with in between as well, little weeds in the garden that I stumbled upon while tending the plants, if you will. But that was pretty much my day .. and it felt great. Simple, accomplishable tasks with immediate benefit and practical use.
After a couple weeks working more in the stratosphere, I feel re-connected with the reality of what we're doing and a little less lost-in-the-clouds. Not to worry ,though, I'm heading back skywards tomorrow.
Monday, September 15, 2008
On KDE4 Performance
Andreas Pakulat recently blogged about performance issues with KDE 4.1 on his new desktop system. While I agree with some of the comments on that blog entry that his blog would've been better off on the kde-devel or even the kde-core-devel mailing list, since he's uncorked the genie I figured I may as well offer some commentary on the matter for the blogosphere. It's probably useful since it's an issue a lot of people are running into, and it's not fun when you do.
A Line in the Sand
First, I'd like to discuss what constitutes an acceptable experience with KDE 4. There will always be some things, like desktop effects used in KWin, Plasma and KRunner, that simply require a decent video card. However, all of these programs should be runnable without those effects and retain an acceptable user experience even on older (within reason; e.g. not 15 years old ;) hardware. Good news is that they do, given decently supported hardware.
It is not acceptable if KDE 4 feels slower than KDE 3, and it is not acceptable if KDE 4 requires brand new hardware. At the same time, if the drivers for older hardware are simply not up to the task and those drivers aren't updated ... there's not much we can do about it and that hardware, which would otherwise be capable of better things, shouldn't be part of our target. It's also absolutely acceptable if certain features only work if the hardware can support them; this is mostly applicable to features reliant on more advanced graphics techniques.
I've seen the KDE 4 Plasma workspace as well as KDE 4 apps run smoothly on devices as small as the N810, on netbooks like the EEE PC, on older desktops and on new bling-bling laptops. The code base does scale well, but unfortunately it doesn't scale well everywhere ... yet. What gives?
Troubleshooting 101: Note the Variances
Have you ever noticed in these discussions how some people say KDE 4.x is "totally unusably slow" for them while others say the performance is just grand? Others say "it sucks!" and then tweak their graphics system (x.org, driver versions, driver config, kernel modules ...) and say "wow, waaay better!"?
Even if we normalize for differing expectations (one woman's "fast enough" might be another's "unnaceptable), we're still left with variance here even with the same code base. This is a critical observation, because it means that we can search for these variances and then work backwards from them towards possible solutions.
So let's go through a handful of these variances ...
Build Time Optimizations
There are some code paths which are god awful slow in a full debug build of some parts of KDE 4. The code that causes the slowness is great for debugging and troubleshooting, but can suck for performance. It's really hard to do proper "seat of your pants" performance measurements unless we're dealing with debug builds. This has bitten me in the past, and I know it's bitten others as well.
It's one of those occasional and unfortunate trade-offs: a bit of the user experience is diminished by running a full debug build that's better for development.
Measuring Performance
This is also why "seat of your pants" performance measurements are not overly useful. What do I mean by "seat of your pants performance measurements"? Here are some examples: "I ran this program and it just feels slow"; "When I scroll in Konqueror using the arrows keys, scrolling seems really jerky." These observations can be useful as starting points: they let us know what might be actually useful to work on as far as improving the user's experience is.
But to really know what is going on we need to profile the application. Often it's not what you think, and profiling can also let you know when it's debug code that's causing the problem without having to keep a separate release build around. So don't jump to performance conclusions based on "seat of your pants" observations; use them only as clues for where to start.
Valgrind and KCachegrind make profiling stupidly simple and very powerful. Even I can do it. ;)
Areas of Performance
Ok, this is probably stupidly obvious for many people, but there are several parts of the computer that can impact performance negatively.
Main memory (RAM) usage can be one: if main memory fills up for whatever reason (applications using it legitimately, applications leaking, etc) then things tend to fall back to disk swap which is painfully slow; worse, file caching is lost and all file access hits disk, also painfully slow.
CPU over-utilization can also degrade performance (to state the obvoius ;). Unlike memory usage, this usually means one of three things: the application is simply trying to do things that CPU is not capable of (rare these days, outside of truly high end applications); the algorithms used in the application are either buggy or plain inappropriate for the task and should be fixed of changed completely (most likely); there is something happening in software that should be happening in hardware (this is a typical problem with graphics). Again, profile really helps here because it's often next to impossible tell which it is without peering into the runtime execution paths. Sometimes something you think is happening on the graphics hardware isn't because of unexpected behavior in the toolkit or other pieces of software being used, for instance.
GPU under-utilization can degrade painting performance. This is probably one of our biggest weak points right now. Unlike in immersive 3D games which we expect to pin our CPU and/or GPU to 100% to get us the best framerates possible, this is a taboo in productivity applications. But to get a smooth experience without hoggin the CPU, hardware acceleration is required. Doing graphics on the CPU can all too quickly eat up most of the cycles available leaving apps little room to do actual work.
The State of the Art Event Horizon Problem
One of the problems we are facing in KDE 4 right now is that we're trying to deliver a modern user experience. We aren't defining "modern" by "what $OTHER_COMPANY is doing today" but rather by "what matches with our vision of kick ass". There's certainly inspiration and lessons we draw here and there from various companies and other FOSS projects ... but we aren't limiting ourselves to that.
In the process of creating this modern user experience, we are doing things that just haven't been down on the FOSS desktop arena, or in some cases any production user interface arena. This pushes into areas we haven't gone before.
The Plasma performance issues are a great example of that. There have been a number of graphics drivers out there that simply have issues with applications that use translucency (sometimes referred to as "argb visuals"). They work fine with compositing window managers, but that's because they use translucency in a rather different way. x.org itself has/had numerous straight out bugs when it came to argb visuals. I demo'd these issues for various x.org developers and every single one of them I showed it to were surprised about the problems.
Why is this? Well, when Plasma came onto the scene there weren't any other production apps doing to the graphics stack in x.org what Plasma was. Untested code equals unfound bugs and unknown performance boundaries.
Plasma isn't the only area we're running into this kind of "event horizon" issue.
x.org and Graphics, or How I Hope It Won't Do Graphics In the Future
We also deal with things right now like XRender which is supposed to be a way to accelerate certain common rendering activities. Things like text rendering, which is used a lot in applications like web browsers, mail readers, word processors, etc. The probem with XRender is that it is designed in a way that doesn't map all that wonderfully to how graphics hardware tends to work. So while there is decent acceleration for some or most of XRender in some graphics drivers, it's abismal on others and never really reaches the full potential we should be seeing due to design issues.
This isn't the only issue in x.org, but it sort of highlights one of the big ones: x.org has some pretty big issues when it comes to doing graphics. That's why nVidia includes in their driver a rewrite of pretty much every bit of x.org that touches graphics. This in turn causes havoc of a new variety: does nVidia's twinview map nicely to xrandr/xinerama or does it get screwed up? (Answer: often the latter.) Issues that get addressed in x.org need to also be fixed in the nVidia driver if they exist there too, and vice versa. It's just not pretty.
This is one of the primary reasons why I'm very excited about Gallium3D: it's a modern graphic stack done by graphics gurus that is designed for the real world of hardware. I've seen it action, and it's impressive.
If the FOSS desktop world is smart, the future of x.org will be as an application windowing protocol (window management, for instance) and an event system. All hardware support will move into kernel drivers where they belong (this is already happening / happened), and graphics itself will be handled by Gallium3D or something like it.
In the meantime, we're a bit stuck working around and within the limitations of today's x.org reality.
Qt4: Room For Improvement
Qt4 itself has room for improvement. There are graphics paths that do things in software that should be done either smarter in software or in hardware. A proper OpenGL paint engine for Qt4 woudl also rock the house considerably. Note that Qt works very well with OpenGL-in-a-widget, but that's not the same thing. I'm talking about all QPainter operations happening in hardware where available, which is very nearly everywhere these days. Even today's mobile devices can manage this, something driven largely by power usage. We don't have that yet, but when we do things will be nicer.
Before that happens, though, there is still lots of room for improvement in Qt4. I've talked with many of the engineers at Qt Software about these things and they have been working a lot on performance in Qt 4.3 and 4.4 with even more to come in 4.5. Performance is not an easy (or fun) issue, and with all the new code and approaches taken in Qt4 it is taking time to really get it slick-as-snot fast.
This isn't to say that it's slow right now, mind you. It's rather impressive right now given all the features it supports, but it's just not as fast as it could be. Thankfully this is a knwon issue and one that Qt Software people care about enough to actually put substantial and continuous effort into. As these efforts come to fruition, KDE 4 will also "magically" improve in performance.
And Where is KDE's Responsibility In All This?
So I've picked on the whole stack underneath KDE 4 by this point in the blog entry. I don't want to give the false impression, however, that KDE has no culpability in the current situation.
There are few truths to keep in mind that impacts KDE 4's performance:
Just as with Qt4, and perhaps even more so in places, we have a good amount of optimization work ahead of us. We works for years on optimizing KDE 3 in various ways, and while we carry much of this work with us into KDE 4 we also have huge new sections of code to repeat this effort on.
Bringing the KDE 4 codebase to maturation will help improve performance, and that's something that can only be accomplished over time. Thankfully, we're doing just that. How fast are we doing that? That's something we can only measure in performance deltas between releases.
So ... what does all this mean?!
It means that there is work that needs to be done at every level in the stack. We've taken the FOSS desktop to a whole new level with KDE 4, and we're pushing it even further with each subsequent release. By setting that bar higher than it has been in the past, we've created new areas of work for ourselves.
But because that work is spread out across the stack, it means that there will be vast variance in user experience right now: something as small as a driver revision upgrade can make all the difference in some cases. It also means that we can't just look at the user experience and point a finger at any one thing, e.g. "KDE 4 is slow, so fix it KDE team!" Profiling is critical, so we can pinpoint whether the problem exists in KDE code, Qt code, x.org, drivers .. elsewhere? Then we need to figure out whether it's best to wait for the stack to catch up (and communicate these pain points to the owners of those parts of the stack) or if it is better to change something in KDE's code itself.
Also remember that there are any number of possible issues: text rendering speed, image manipulation performance, graphics in software vs hardware ...
If that sounds like it's not an easy problem, that's because it's not. It's a wicked problem, one with no single cause and no single solution. We need to track down these issues one by one, by profiling code and exercising the software on different hardware/software configurations, and improve them. It will be an incremental process, but it's doable.
It Works For Me
If you think that I'm displaying a lot or maybe even too much confidence, here's why I have that confidence:
Right now, KDE 4 flies on my laptop, and it's hardly a screamer by today's standards. So I know it's possible for KDE 4 to perform very well.
I also keep close tabs on work going on elsewhere in the stack and am very happy with the directionality of it. Work is being done in pretty well all the areas we need work to be done in to improve the event horizon issues.
I wish I could wave a magic wand and make KDE 4 work like a speed demon for everyone, but that's just not realistic right now. At least I know there is light at the end of this tunnel, and that things work well for a large number of people already as it is.
The alternative would be turn around now and go back to a 1990s era desktop as we had in KDE 3. It was solid and stable, but had an extremely limited future for the general user base. Going back to something that has acceptable performance today for everyone but which is a dead end tomorrow isn't really an option, especially when we can get what we have now working as well or better than what we had. We should also avoid rose coloured glasses and remember that performance in KDE 3.0 also sucked with noticeable improvements with each release; the same is happening with KDE 4.
So it's not a perfect world, but one that's getting incrementally better. I doubt that's news to anyone, and I hope that the above helps to at least add some substance to what is often a rather shallow discussion.
A Line in the Sand
First, I'd like to discuss what constitutes an acceptable experience with KDE 4. There will always be some things, like desktop effects used in KWin, Plasma and KRunner, that simply require a decent video card. However, all of these programs should be runnable without those effects and retain an acceptable user experience even on older (within reason; e.g. not 15 years old ;) hardware. Good news is that they do, given decently supported hardware.
It is not acceptable if KDE 4 feels slower than KDE 3, and it is not acceptable if KDE 4 requires brand new hardware. At the same time, if the drivers for older hardware are simply not up to the task and those drivers aren't updated ... there's not much we can do about it and that hardware, which would otherwise be capable of better things, shouldn't be part of our target. It's also absolutely acceptable if certain features only work if the hardware can support them; this is mostly applicable to features reliant on more advanced graphics techniques.
I've seen the KDE 4 Plasma workspace as well as KDE 4 apps run smoothly on devices as small as the N810, on netbooks like the EEE PC, on older desktops and on new bling-bling laptops. The code base does scale well, but unfortunately it doesn't scale well everywhere ... yet. What gives?
Troubleshooting 101: Note the Variances
Have you ever noticed in these discussions how some people say KDE 4.x is "totally unusably slow" for them while others say the performance is just grand? Others say "it sucks!" and then tweak their graphics system (x.org, driver versions, driver config, kernel modules ...) and say "wow, waaay better!"?
Even if we normalize for differing expectations (one woman's "fast enough" might be another's "unnaceptable), we're still left with variance here even with the same code base. This is a critical observation, because it means that we can search for these variances and then work backwards from them towards possible solutions.
So let's go through a handful of these variances ...
Build Time Optimizations
There are some code paths which are god awful slow in a full debug build of some parts of KDE 4. The code that causes the slowness is great for debugging and troubleshooting, but can suck for performance. It's really hard to do proper "seat of your pants" performance measurements unless we're dealing with debug builds. This has bitten me in the past, and I know it's bitten others as well.
It's one of those occasional and unfortunate trade-offs: a bit of the user experience is diminished by running a full debug build that's better for development.
Measuring Performance
This is also why "seat of your pants" performance measurements are not overly useful. What do I mean by "seat of your pants performance measurements"? Here are some examples: "I ran this program and it just feels slow"; "When I scroll in Konqueror using the arrows keys, scrolling seems really jerky." These observations can be useful as starting points: they let us know what might be actually useful to work on as far as improving the user's experience is.
But to really know what is going on we need to profile the application. Often it's not what you think, and profiling can also let you know when it's debug code that's causing the problem without having to keep a separate release build around. So don't jump to performance conclusions based on "seat of your pants" observations; use them only as clues for where to start.
Valgrind and KCachegrind make profiling stupidly simple and very powerful. Even I can do it. ;)
Areas of Performance
Ok, this is probably stupidly obvious for many people, but there are several parts of the computer that can impact performance negatively.
Main memory (RAM) usage can be one: if main memory fills up for whatever reason (applications using it legitimately, applications leaking, etc) then things tend to fall back to disk swap which is painfully slow; worse, file caching is lost and all file access hits disk, also painfully slow.
CPU over-utilization can also degrade performance (to state the obvoius ;). Unlike memory usage, this usually means one of three things: the application is simply trying to do things that CPU is not capable of (rare these days, outside of truly high end applications); the algorithms used in the application are either buggy or plain inappropriate for the task and should be fixed of changed completely (most likely); there is something happening in software that should be happening in hardware (this is a typical problem with graphics). Again, profile really helps here because it's often next to impossible tell which it is without peering into the runtime execution paths. Sometimes something you think is happening on the graphics hardware isn't because of unexpected behavior in the toolkit or other pieces of software being used, for instance.
GPU under-utilization can degrade painting performance. This is probably one of our biggest weak points right now. Unlike in immersive 3D games which we expect to pin our CPU and/or GPU to 100% to get us the best framerates possible, this is a taboo in productivity applications. But to get a smooth experience without hoggin the CPU, hardware acceleration is required. Doing graphics on the CPU can all too quickly eat up most of the cycles available leaving apps little room to do actual work.
The State of the Art Event Horizon Problem
One of the problems we are facing in KDE 4 right now is that we're trying to deliver a modern user experience. We aren't defining "modern" by "what $OTHER_COMPANY is doing today" but rather by "what matches with our vision of kick ass". There's certainly inspiration and lessons we draw here and there from various companies and other FOSS projects ... but we aren't limiting ourselves to that.
In the process of creating this modern user experience, we are doing things that just haven't been down on the FOSS desktop arena, or in some cases any production user interface arena. This pushes into areas we haven't gone before.
The Plasma performance issues are a great example of that. There have been a number of graphics drivers out there that simply have issues with applications that use translucency (sometimes referred to as "argb visuals"). They work fine with compositing window managers, but that's because they use translucency in a rather different way. x.org itself has/had numerous straight out bugs when it came to argb visuals. I demo'd these issues for various x.org developers and every single one of them I showed it to were surprised about the problems.
Why is this? Well, when Plasma came onto the scene there weren't any other production apps doing to the graphics stack in x.org what Plasma was. Untested code equals unfound bugs and unknown performance boundaries.
Plasma isn't the only area we're running into this kind of "event horizon" issue.
x.org and Graphics, or How I Hope It Won't Do Graphics In the Future
We also deal with things right now like XRender which is supposed to be a way to accelerate certain common rendering activities. Things like text rendering, which is used a lot in applications like web browsers, mail readers, word processors, etc. The probem with XRender is that it is designed in a way that doesn't map all that wonderfully to how graphics hardware tends to work. So while there is decent acceleration for some or most of XRender in some graphics drivers, it's abismal on others and never really reaches the full potential we should be seeing due to design issues.
This isn't the only issue in x.org, but it sort of highlights one of the big ones: x.org has some pretty big issues when it comes to doing graphics. That's why nVidia includes in their driver a rewrite of pretty much every bit of x.org that touches graphics. This in turn causes havoc of a new variety: does nVidia's twinview map nicely to xrandr/xinerama or does it get screwed up? (Answer: often the latter.) Issues that get addressed in x.org need to also be fixed in the nVidia driver if they exist there too, and vice versa. It's just not pretty.
This is one of the primary reasons why I'm very excited about Gallium3D: it's a modern graphic stack done by graphics gurus that is designed for the real world of hardware. I've seen it action, and it's impressive.
If the FOSS desktop world is smart, the future of x.org will be as an application windowing protocol (window management, for instance) and an event system. All hardware support will move into kernel drivers where they belong (this is already happening / happened), and graphics itself will be handled by Gallium3D or something like it.
In the meantime, we're a bit stuck working around and within the limitations of today's x.org reality.
Qt4: Room For Improvement
Qt4 itself has room for improvement. There are graphics paths that do things in software that should be done either smarter in software or in hardware. A proper OpenGL paint engine for Qt4 woudl also rock the house considerably. Note that Qt works very well with OpenGL-in-a-widget, but that's not the same thing. I'm talking about all QPainter operations happening in hardware where available, which is very nearly everywhere these days. Even today's mobile devices can manage this, something driven largely by power usage. We don't have that yet, but when we do things will be nicer.
Before that happens, though, there is still lots of room for improvement in Qt4. I've talked with many of the engineers at Qt Software about these things and they have been working a lot on performance in Qt 4.3 and 4.4 with even more to come in 4.5. Performance is not an easy (or fun) issue, and with all the new code and approaches taken in Qt4 it is taking time to really get it slick-as-snot fast.
This isn't to say that it's slow right now, mind you. It's rather impressive right now given all the features it supports, but it's just not as fast as it could be. Thankfully this is a knwon issue and one that Qt Software people care about enough to actually put substantial and continuous effort into. As these efforts come to fruition, KDE 4 will also "magically" improve in performance.
And Where is KDE's Responsibility In All This?
So I've picked on the whole stack underneath KDE 4 by this point in the blog entry. I don't want to give the false impression, however, that KDE has no culpability in the current situation.
There are few truths to keep in mind that impacts KDE 4's performance:
- For a lot of us, this is the first time we've used these new techniques and we have more to learn about how to use them best.
- There is a lot of very new code in KDE 4, and new code means both new bugs as well as new unoptimized paths.
- We can work around some limitations lower in the stack better than we do now, though sometimes we need to patient and let the stack catch up with us.
Just as with Qt4, and perhaps even more so in places, we have a good amount of optimization work ahead of us. We works for years on optimizing KDE 3 in various ways, and while we carry much of this work with us into KDE 4 we also have huge new sections of code to repeat this effort on.
Bringing the KDE 4 codebase to maturation will help improve performance, and that's something that can only be accomplished over time. Thankfully, we're doing just that. How fast are we doing that? That's something we can only measure in performance deltas between releases.
So ... what does all this mean?!
It means that there is work that needs to be done at every level in the stack. We've taken the FOSS desktop to a whole new level with KDE 4, and we're pushing it even further with each subsequent release. By setting that bar higher than it has been in the past, we've created new areas of work for ourselves.
But because that work is spread out across the stack, it means that there will be vast variance in user experience right now: something as small as a driver revision upgrade can make all the difference in some cases. It also means that we can't just look at the user experience and point a finger at any one thing, e.g. "KDE 4 is slow, so fix it KDE team!" Profiling is critical, so we can pinpoint whether the problem exists in KDE code, Qt code, x.org, drivers .. elsewhere? Then we need to figure out whether it's best to wait for the stack to catch up (and communicate these pain points to the owners of those parts of the stack) or if it is better to change something in KDE's code itself.
Also remember that there are any number of possible issues: text rendering speed, image manipulation performance, graphics in software vs hardware ...
If that sounds like it's not an easy problem, that's because it's not. It's a wicked problem, one with no single cause and no single solution. We need to track down these issues one by one, by profiling code and exercising the software on different hardware/software configurations, and improve them. It will be an incremental process, but it's doable.
It Works For Me
If you think that I'm displaying a lot or maybe even too much confidence, here's why I have that confidence:
Right now, KDE 4 flies on my laptop, and it's hardly a screamer by today's standards. So I know it's possible for KDE 4 to perform very well.
I also keep close tabs on work going on elsewhere in the stack and am very happy with the directionality of it. Work is being done in pretty well all the areas we need work to be done in to improve the event horizon issues.
I wish I could wave a magic wand and make KDE 4 work like a speed demon for everyone, but that's just not realistic right now. At least I know there is light at the end of this tunnel, and that things work well for a large number of people already as it is.
The alternative would be turn around now and go back to a 1990s era desktop as we had in KDE 3. It was solid and stable, but had an extremely limited future for the general user base. Going back to something that has acceptable performance today for everyone but which is a dead end tomorrow isn't really an option, especially when we can get what we have now working as well or better than what we had. We should also avoid rose coloured glasses and remember that performance in KDE 3.0 also sucked with noticeable improvements with each release; the same is happening with KDE 4.
So it's not a perfect world, but one that's getting incrementally better. I doubt that's news to anyone, and I hope that the above helps to at least add some substance to what is often a rather shallow discussion.
Sunday, September 14, 2008
HOWTO: decoupling the dashboard from the desktop
(I promised someone the other day who wrote to me by email that I'd blog this little tidbit. Hopefully it also ends up in the Plasma FAQ over on Userbase.)
When you press Control + F12 when Plasma is running, the Plasma Widget Dashboard pops up for you. By default, this "brings forward" your desktop and helps address the "but I never see my desktop!" problem.
It's not the only way of working, of course, but it seems like a sensible default balancing usability concerns and resource consumption. On the Mac, they only have a dashboard view and no widgets on the desktop. Some people prefer this; others just want a completely different set of widgets on their desktop and on the dashboard.
In KDE 4.1 I snuck in a little feature for those people that lets you define what Activity to show in the desktop. (It was requested on IRC by a random user and they made their case so compellingly that I just had to add it in there. =) There is no configuration UI for it and how it works is a little complex, so I've avoided talking about it too, too much.
So here's how to take advantage of this trick, as long as you are using KDE 4.1.0 or higher:
First, zoom out on the desktop and select Add A New Activity from the toolbox. We will use this Activity for the dashboard. Now open a konsole window and do "kquitapp plasma".
Plasma consists of an in-memory representation of the items, or the scene, and one or more views on this scene. The views are what actually paint to the screen (the items just exist abstractly in the scene). Examples of views are panels, the desktop itself or in Amarok2 the Context View. Configuration for the scene and the views are kept separate to make it easier to transport around scene layouts (e.g. Activities) and to keep the distinction more clear in the code base.
The scene configuraton for the Plasma workspace shell is kept in the plasma-appletsrc file. In the plasma-appletsrc file, there will be a new entry (found most easily by looking for plugin=desktop) for this new Activity. The configuration group will be called "[Containments][#]". The number (#) is important. Write this down somewhere. We will also want the number for the usual desktop containment, record all #s from groups with plugin=desktop.
Close the plasma-appletsrc file and open up plasmarc. This is where the views for this application are stored. In there you will find a group called "[ViewIds]". Look for an entry that starts with one of the numbers we got from plasma-appletsrc. This will be the mapping of the Activity to the View, with the Activity on the left and the View on the right.
So if the Activity id was "39" and we have:
[ViewIds]
3=1
39=2
then the view we're looking for has id 2. At this point we want to look for a group in plasmarc called '[PlasmaViews][#]' (in the example above, that # would be 2). This group probably does not exist in your plasmarc (the DesktopView doesn't store much in the way of configuration data), so just add it to the file. Now add aDashboardView=# DashboardContainment=# entry, where the # is the id of the new Activity we created just before exiting Plasma.
Start Plasma again and when you hit F12 you should get not your desktop Activity, but the other one. You can add widgets to it as you normally would right from the Widget Dashboard, and now you have a slightly more Mac-like experience.
Note that this setting is per-screen, so if you have more than one monitor connected to your computer you can even have a different Activity on each screen's Widget Dashboard.
As you have probably already figured out, the configuration files are not exactly optimized for humans. ;) One day I'll get around to putting a bit of config UI into the Widget Dashboard to let you set which Activity to show and then you won't have to resort to all this text editor stuff. Or maybe someone will appear with a patch magically in hand, who knows. =)
Anyways, enjoy. Especially if you are Robert L. =)
When you press Control + F12 when Plasma is running, the Plasma Widget Dashboard pops up for you. By default, this "brings forward" your desktop and helps address the "but I never see my desktop!" problem.
It's not the only way of working, of course, but it seems like a sensible default balancing usability concerns and resource consumption. On the Mac, they only have a dashboard view and no widgets on the desktop. Some people prefer this; others just want a completely different set of widgets on their desktop and on the dashboard.
In KDE 4.1 I snuck in a little feature for those people that lets you define what Activity to show in the desktop. (It was requested on IRC by a random user and they made their case so compellingly that I just had to add it in there. =) There is no configuration UI for it and how it works is a little complex, so I've avoided talking about it too, too much.
So here's how to take advantage of this trick, as long as you are using KDE 4.1.0 or higher:
First, zoom out on the desktop and select Add A New Activity from the toolbox. We will use this Activity for the dashboard. Now open a konsole window and do "kquitapp plasma".
Plasma consists of an in-memory representation of the items, or the scene, and one or more views on this scene. The views are what actually paint to the screen (the items just exist abstractly in the scene). Examples of views are panels, the desktop itself or in Amarok2 the Context View. Configuration for the scene and the views are kept separate to make it easier to transport around scene layouts (e.g. Activities) and to keep the distinction more clear in the code base.
The scene configuraton for the Plasma workspace shell is kept in the plasma-appletsrc file. In the plasma-appletsrc file, there will be a new entry (found most easily by looking for plugin=desktop) for this new Activity. The configuration group will be called "[Containments][#]". The number (#) is important. Write this down somewhere. We will also want the number for the usual desktop containment, record all #s from groups with plugin=desktop.
Close the plasma-appletsrc file and open up plasmarc. This is where the views for this application are stored. In there you will find a group called "[ViewIds]". Look for an entry that starts with one of the numbers we got from plasma-appletsrc. This will be the mapping of the Activity to the View, with the Activity on the left and the View on the right.
So if the Activity id was "39" and we have:
[ViewIds]
3=1
39=2
then the view we're looking for has id 2. At this point we want to look for a group in plasmarc called '[PlasmaViews][#]' (in the example above, that # would be 2). This group probably does not exist in your plasmarc (the DesktopView doesn't store much in the way of configuration data), so just add it to the file. Now add a
Start Plasma again and when you hit F12 you should get not your desktop Activity, but the other one. You can add widgets to it as you normally would right from the Widget Dashboard, and now you have a slightly more Mac-like experience.
Note that this setting is per-screen, so if you have more than one monitor connected to your computer you can even have a different Activity on each screen's Widget Dashboard.
As you have probably already figured out, the configuration files are not exactly optimized for humans. ;) One day I'll get around to putting a bit of config UI into the Widget Dashboard to let you set which Activity to show and then you won't have to resort to all this text editor stuff. Or maybe someone will appear with a patch magically in hand, who knows. =)
Anyways, enjoy. Especially if you are Robert L. =)
Sunday, September 07, 2008
all your userbase
Techbase has proven to be a great resource for the KDE community of developers, administrators and project coordinators. It didn't offer much of anything to users, however, and that was purposeful: Techbase was designed with a clear purpose in mind, and I believe that to be a significant reason why it has been as successful as it has been.
To fill the user gap, however, the Community Working Group (CWG) members have started work on a wiki driven site much like Techbase but designed specifically for user appropriate content. It is not meant to replace documentation, but rather to augment it and provide a working communications channel for the KDE community of users about KDE as it develops and progresses.
Anne Wilson and Juan Carlos Torres of the CWG have been working on getting content on the wiki, working towards a structure for the content, etc. It's a huge task, however, and now that they've started the work and have set a pace for their efforts it is time for other interested people to join up and help make this new resource the amazing place it needs to become. Two people can't do it on their own, but a few dozen surely can and I know for a fact we have way more than that number of interested, concerned users.
So without further ado, say hello to Userbase!
Remember it is in a very early state right now and not a finished product by any stretch of the imagination. You can help Userbase achieve greatness sooner by emailing the Community Working Group who is hosting the Userbase project efforts and start adding content to the wiki.
Update: I just found out that the log in system for Userbase is still under construction. Danimo and Pino informed me that they having implemented only OpenID based authentication for Userbase, but that it's not fully exposed yet. Assuming this goes well, Techbase will follow suit later. Good news on all fronts, really, but one more bit of "early days, not completely ready" to deal with on Userbase as authentication gets ironed out.
To fill the user gap, however, the Community Working Group (CWG) members have started work on a wiki driven site much like Techbase but designed specifically for user appropriate content. It is not meant to replace documentation, but rather to augment it and provide a working communications channel for the KDE community of users about KDE as it develops and progresses.
Anne Wilson and Juan Carlos Torres of the CWG have been working on getting content on the wiki, working towards a structure for the content, etc. It's a huge task, however, and now that they've started the work and have set a pace for their efforts it is time for other interested people to join up and help make this new resource the amazing place it needs to become. Two people can't do it on their own, but a few dozen surely can and I know for a fact we have way more than that number of interested, concerned users.
So without further ado, say hello to Userbase!
Remember it is in a very early state right now and not a finished product by any stretch of the imagination. You can help Userbase achieve greatness sooner by emailing the Community Working Group who is hosting the Userbase project efforts and start adding content to the wiki.
Update: I just found out that the log in system for Userbase is still under construction. Danimo and Pino informed me that they having implemented only OpenID based authentication for Userbase, but that it's not fully exposed yet. Assuming this goes well, Techbase will follow suit later. Good news on all fronts, really, but one more bit of "early days, not completely ready" to deal with on Userbase as authentication gets ironed out.
Friday, September 05, 2008
Plasma, Context and Nepomuk
Imagine if you will ... (ah, such a classic start! =) You are working on a work project involving Sarah and John and Marmaduke; you switch to working on your MySpace profile ... Let's call each state (the work project, MySpace fiddling) a "context" and changing between them a "context switch". What happens with the rest of the software running on your computer when you switch contexts? Answer: pretty much nothing. At least not automatically.
Compare with network connectivity. When you lose network connectivity, KMail stops fetching your mail, Kopete closes it's connections .. and when the network connectivity comes back, it all fires up again automatically. This is great because now the software is reacting to the environment it "lives" in.
Virtual desktops help somewhat as people can use them to aggregate related windows into contexts. But let's face it, there's only one Kopete window. Wouldn't it be great if you could tag Sarah, John and Marmaduke in your Jabber buddy's list with the "Workmates" tag? That way, when you switch back to the work project after you're done MySpacing, Kopete could re-arrange your buddy list to put those workmates at the top of your buddy list. The contacts widget in your panel or on your desktop could also switch the people they are showing.
To make software react to the user context in the environment they live in, we need a way to publish the user context and for the user to communicate "I am now doing $FOO" and "I am physically located in $BAR". This is similar to how Solid broadcasts changes in network status to KDE applications, but for user context.
In Plasma we have the idea of Activities. In 4.2 you can give your Activities names and Plasmoids can ask what the current Context is and do whatever they might want to do given that Context. Plasmoids are also notified via a Constraints update when the context changes.
For this to really fly, though, this contextual information needs to be accessible by software outside of Plasma itself. Nepomuk will be filling this role, and today a few of us huddled together on IRC for a quick meeting to wrap up a week's worth of discussion on the Nepomuk KDE mailing list about user context. Trüg, Hari and myself managed to align our schedules with one goal to achieve: come up with the initial ontology (fancy way of saying "organization definition", more or less) for context.
Over the next couple of days we'll be coding the start of a Nepomuk service for publishing and collecting information on the current context and I'll be hooking Plasma into it. This will allow other applications to see the various known Contexts and either automagically tag data with appropriate Contexts and/or let the user manually tag data. Going back to the Kopete and contacts widget example, once we can associated (or "tag") contacts in Akonadi with Contexts then Kopete and the contacts Plasmoid will be able to adapt in concert with Plasma.
We aren't going for auto-context switching yet, though we will be automating location changes and eventually hopefully be putting in some intelligence for detecting the user's current activity.
Fortunately for us, there's a lot of really good science that's already been done in this field for us to reflect upon and base our efforts on. We're also starting simple, though we intend to build as far as it makes sense to, as defined by real world user benefit. Which is to say that our odds of success are extremely high.
Once 4.2 is out, I'll be poking and prodding application developers to start making their applications context aware. (Application developers: you've been warned! ;) This won't make applications dependent on either Plasma or Nepomuk, they'll just work better when they are around. All that will be required is D-Bus, which is already a requirement for KDE 4 applications. But if Nepomuk is around then applications will be able to rifle through and get information on Contexts. Likewise, if Plasma is around then the user will be able to interact rather directly with the Context using their desktop shell.
As we develop the application API further, I'll blog more about it. Plasmoid developers can start having fun right now, though! =)
Compare with network connectivity. When you lose network connectivity, KMail stops fetching your mail, Kopete closes it's connections .. and when the network connectivity comes back, it all fires up again automatically. This is great because now the software is reacting to the environment it "lives" in.
Virtual desktops help somewhat as people can use them to aggregate related windows into contexts. But let's face it, there's only one Kopete window. Wouldn't it be great if you could tag Sarah, John and Marmaduke in your Jabber buddy's list with the "Workmates" tag? That way, when you switch back to the work project after you're done MySpacing, Kopete could re-arrange your buddy list to put those workmates at the top of your buddy list. The contacts widget in your panel or on your desktop could also switch the people they are showing.
To make software react to the user context in the environment they live in, we need a way to publish the user context and for the user to communicate "I am now doing $FOO" and "I am physically located in $BAR". This is similar to how Solid broadcasts changes in network status to KDE applications, but for user context.
In Plasma we have the idea of Activities. In 4.2 you can give your Activities names and Plasmoids can ask what the current Context is and do whatever they might want to do given that Context. Plasmoids are also notified via a Constraints update when the context changes.
For this to really fly, though, this contextual information needs to be accessible by software outside of Plasma itself. Nepomuk will be filling this role, and today a few of us huddled together on IRC for a quick meeting to wrap up a week's worth of discussion on the Nepomuk KDE mailing list about user context. Trüg, Hari and myself managed to align our schedules with one goal to achieve: come up with the initial ontology (fancy way of saying "organization definition", more or less) for context.
Over the next couple of days we'll be coding the start of a Nepomuk service for publishing and collecting information on the current context and I'll be hooking Plasma into it. This will allow other applications to see the various known Contexts and either automagically tag data with appropriate Contexts and/or let the user manually tag data. Going back to the Kopete and contacts widget example, once we can associated (or "tag") contacts in Akonadi with Contexts then Kopete and the contacts Plasmoid will be able to adapt in concert with Plasma.
We aren't going for auto-context switching yet, though we will be automating location changes and eventually hopefully be putting in some intelligence for detecting the user's current activity.
Fortunately for us, there's a lot of really good science that's already been done in this field for us to reflect upon and base our efforts on. We're also starting simple, though we intend to build as far as it makes sense to, as defined by real world user benefit. Which is to say that our odds of success are extremely high.
Once 4.2 is out, I'll be poking and prodding application developers to start making their applications context aware. (Application developers: you've been warned! ;) This won't make applications dependent on either Plasma or Nepomuk, they'll just work better when they are around. All that will be required is D-Bus, which is already a requirement for KDE 4 applications. But if Nepomuk is around then applications will be able to rifle through and get information on Contexts. Likewise, if Plasma is around then the user will be able to interact rather directly with the Context using their desktop shell.
As we develop the application API further, I'll blog more about it. Plasmoid developers can start having fun right now, though! =)
DataEngine+Service
I'm a big fan of making it easy for artists to do art, interface designers to work on interfaces and coders to work on all the plumbing underneath. This means that each needs to be able to work somewhat independently, such that a coder isnt' forced to do interface work just to see their stuff in action or so that an interface designer isn't forced to request code changes beneath the UI just to change things around a bit. With an open source project that is distributed around the world, it's even trickier as you can't even guarantee that all three skills will be available simultaneously in the same geographic location. So the process must allow for different pieces to happen at different times.
Another thing I noticed when looking through other attempts at solutions in the "widgets" space was that pretty much everyone provided an API for things like "what's the speed and heat of the CPU" and "am I on the network?" and "fetch me this RSS feed". Unfortunately, these API sets were generally monolithic lumps of interfaces that weren't easily extended. Which means that as soon as you wanted to do something not in that API, you had to resort to cobbling it together yourself ... for each and every widget. At that point one is right back to the traditional development model, pre-widgets era, and life begins to suck again.
In designing Plasma, I decided that one of the (many) goal(s) would be to find a way to fix all of the above. Thus came DataEngine, and eventually Service, as vital pieces to that puzzle. One way to view DataEngine is that it allows ones to extend the widget API at runtime even through third party modules without runtime bloat: only what's needed is loaded, and what isn't there can be added as an after-market piece.
I blogged about KTorrent's plasmoid the other day, and something I don't think I mentioned is that they provide a DataEngine as well. That means that once you have KTorrent installed, any widget can start displaying torrent data. What if KTorrent isn't installed? If a widget asks for the KTorrent engine but it isn't installed, a dummy engine that just spits out null data is given in its place. This allows widget developers to be a little more lazy and lot more safe (you can always assume you'll get some engine back when you ask for it).
DataEngines are designed to be accessed by multiple separate data visualizations at once, support polling updates as well as push-on-demand updates and other fun stuff. All this comes for free to DataEngine implementations, but there is one catch to this all-shared magic dancing bear approach: writing to a DataEngine isn't supported, as that could have unexpected (and unexpectable) consequences to other visualizations.
That's where Service comes in. Services can be loaded as plugins and used independently, but there's another very useful pattern of usage: a DataEngine consumer asks for the Service associated with a given bit of data published by a DataEngine. Code wise, it looks like this:
For instance, if you are using the Twitter engine you can request a Service for a feed that provides both an authentication and a new tweet posting operation. That Service already knows the account it should use because it knows what data it was associated with:
Each Service exposes a KConfig based API that lets you see what operations are supported and the details for that operation. Writing a Service is pretty easy too, especially if you provide a KConfigXT XML file named after the Service as that populates and registers the Service details automagically.
Services, unlike DataEngines, are not shared. They belong to whomever asks for it. Services spawn jobs, so a Service can be re-used over and over by the same owner.
Ok, enough about Services and DataEngines. This design allows coders to write these nice little bits of glue to all sorts of technical things that interface designers and artists can then very easily bind their work to using straight-forward and standardized API hooks. Everyone can work together, but also stay out of each other's way.
There's one more catch here, though: how does the programmer test their DataEngine or Service? Remember, we don't want them running off to write a user interface, especially not during testing since that results in some of the more hideous results. (I'm just as guilty of that, btw. =)
I hear some of you say, "Unit tests!" Sure, that's a nice idea, but not everyone's into unit testing and some DataEngines just aren't very unit testable (at least not easily; this can be particularly true for things like integration with 3rd party online services).
Recognizing the laziness inherent in developers, I wrote a small utility called plasmaengineexplorer, or Plasma Engine Explorer for the spaces-and-capital-letters crowd out there ;), to encourage programmers to test without creating "testing UIs" which is a synonym for "a looks-like-roadkill-on-a-hot-day interface".
Here's a shot of the engine explorer in action:
In that shot you can see it looking at the Twitter engine, the context menu on a data source and the service associated with that source in another window.
With this tool you can interact just like a plasmoid (or other user of DataEngines) can. You can request new sources, poll for updates, see what sources are available, request services, start operations in those services with custom parameter values ... It makes testing a DataEngine really rather easy. It also makes it really simple for someone writing a component that will use a DataEngine to see what is available and how it all fits at runtime.
There are still some TODOs, like providing per-DataEngine/per-Service runtime documentation and drag-and-drop from the sources view, but it's already a useful tool. You can find it in kdebase-workspace along with the rest of Plasma.
The Plasma team has a few other tools available as well, such as plasmapkg (for managing Plasma packages) and plasmoidviewer (a stand-alone Plasma widget viewer), and we have a few more planned. The goal is to continue to encourage people working on the Three Disciplines (code, art and interface) to work together while maintaining their independence.
Another thing I noticed when looking through other attempts at solutions in the "widgets" space was that pretty much everyone provided an API for things like "what's the speed and heat of the CPU" and "am I on the network?" and "fetch me this RSS feed". Unfortunately, these API sets were generally monolithic lumps of interfaces that weren't easily extended. Which means that as soon as you wanted to do something not in that API, you had to resort to cobbling it together yourself ... for each and every widget. At that point one is right back to the traditional development model, pre-widgets era, and life begins to suck again.
In designing Plasma, I decided that one of the (many) goal(s) would be to find a way to fix all of the above. Thus came DataEngine, and eventually Service, as vital pieces to that puzzle. One way to view DataEngine is that it allows ones to extend the widget API at runtime even through third party modules without runtime bloat: only what's needed is loaded, and what isn't there can be added as an after-market piece.
I blogged about KTorrent's plasmoid the other day, and something I don't think I mentioned is that they provide a DataEngine as well. That means that once you have KTorrent installed, any widget can start displaying torrent data. What if KTorrent isn't installed? If a widget asks for the KTorrent engine but it isn't installed, a dummy engine that just spits out null data is given in its place. This allows widget developers to be a little more lazy and lot more safe (you can always assume you'll get some engine back when you ask for it).
DataEngines are designed to be accessed by multiple separate data visualizations at once, support polling updates as well as push-on-demand updates and other fun stuff. All this comes for free to DataEngine implementations, but there is one catch to this all-shared magic dancing bear approach: writing to a DataEngine isn't supported, as that could have unexpected (and unexpectable) consequences to other visualizations.
That's where Service comes in. Services can be loaded as plugins and used independently, but there's another very useful pattern of usage: a DataEngine consumer asks for the Service associated with a given bit of data published by a DataEngine. Code wise, it looks like this:
Plasma::Service *service = engine->serviceForSource("nameOfSource");. As usual, you are guaranteed to get a Service, even if it's a Null (aka "doesn't do anything") Service. This Service will arrive pre-configured to the data it is associated with.For instance, if you are using the Twitter engine you can request a Service for a feed that provides both an authentication and a new tweet posting operation. That Service already knows the account it should use because it knows what data it was associated with:
twitterEngine->serviceForSource("Timeline:aseigo"). So now we can interact with whatever that bit of data represents, which might be a media player (the NowPlaying engine provides such a Service) or a torrent or a Twitter account or the powermanagement daemon running on your laptop or ...Each Service exposes a KConfig based API that lets you see what operations are supported and the details for that operation. Writing a Service is pretty easy too, especially if you provide a KConfigXT XML file named after the Service as that populates and registers the Service details automagically.
Services, unlike DataEngines, are not shared. They belong to whomever asks for it. Services spawn jobs, so a Service can be re-used over and over by the same owner.
Ok, enough about Services and DataEngines. This design allows coders to write these nice little bits of glue to all sorts of technical things that interface designers and artists can then very easily bind their work to using straight-forward and standardized API hooks. Everyone can work together, but also stay out of each other's way.
There's one more catch here, though: how does the programmer test their DataEngine or Service? Remember, we don't want them running off to write a user interface, especially not during testing since that results in some of the more hideous results. (I'm just as guilty of that, btw. =)
I hear some of you say, "Unit tests!" Sure, that's a nice idea, but not everyone's into unit testing and some DataEngines just aren't very unit testable (at least not easily; this can be particularly true for things like integration with 3rd party online services).
Recognizing the laziness inherent in developers, I wrote a small utility called plasmaengineexplorer, or Plasma Engine Explorer for the spaces-and-capital-letters crowd out there ;), to encourage programmers to test without creating "testing UIs" which is a synonym for "a looks-like-roadkill-on-a-hot-day interface".
Here's a shot of the engine explorer in action:
In that shot you can see it looking at the Twitter engine, the context menu on a data source and the service associated with that source in another window.
With this tool you can interact just like a plasmoid (or other user of DataEngines) can. You can request new sources, poll for updates, see what sources are available, request services, start operations in those services with custom parameter values ... It makes testing a DataEngine really rather easy. It also makes it really simple for someone writing a component that will use a DataEngine to see what is available and how it all fits at runtime.
There are still some TODOs, like providing per-DataEngine/per-Service runtime documentation and drag-and-drop from the sources view, but it's already a useful tool. You can find it in kdebase-workspace along with the rest of Plasma.
The Plasma team has a few other tools available as well, such as plasmapkg (for managing Plasma packages) and plasmoidviewer (a stand-alone Plasma widget viewer), and we have a few more planned. The goal is to continue to encourage people working on the Three Disciplines (code, art and interface) to work together while maintaining their independence.
Wednesday, September 03, 2008
rewriting a DataEngine
Besides taking the P-man to school (and picking him up after), doing sink full of dishes, re-arranging P's room, putting together a new computer chair, preparing three meals today and getting rid of a huge number of full-screen repaints for Containments ... I essentially rewrote the Twitter Plasma::DataEngine.
It was one of the older engines, and as such had a lot of less than pretty work arounds inside it. What really motivated me to finally look into was that it used QHttp, which means all sorts of bad things like not knowing about web proxies. Thiago is about to commit a change to KDE's CMake support that will deny QHttp usage in KDE apps because it is just that broken.
So I slapped on my hip waders and started tearing the engine apart. First I created a pair of DataContainer classes (one for the status timelines and one for getting user images) that encapsulate the individual HTTP requests; now the TwitterEngine doesn't have to multiplex all those jobs and the code to massage the results into order is neatly tucked into each class.
Finally, I created a Plasma::Service so setting the password for an account or updating the status (aka "tweeting") is not hackish at all anymore. Even nicer, the password is no longer visible outside of the DataEngine itself.
Update: In my rush to write this entry, I completely forgot to include the conclusion: that the DataEngine pattern used along with KDE's libraries and Qt makes it easy enough to write something like this in just a portion of a day. The new engine is also only about 20-30 lines more code than the old one but a hell of a lot more readable and debuggable, which shows how nicely the DataEngine classes have matured over the last year or so.
Thankfully the Twitter plasmoid was the only user of this engine, so I was free to change things about nearly at will like this. The downside is that right now the Twitter plasmoid is rather broken in svn. Tomorrow I'll be hacking on plasmaengineexplorer so that one can interact with Services associated with a DataEngine source and fixing the applet.
I'll also be finally adding a DataEngine design description tomorrow while I'm at it. It's kind of impressive how many details have been covered in the DataEngine classes to make it stupid simple and efficient to use, but things are fairly well in order now it seems after another round of improvements were made for 4.2, mostly induced by increased usage of Plasma::Service and Plasma::DataContainer subclasses.
On Thursday I have a Nepomuk meeting on IRC after which I will hopefully have enough in place to talk about the work on publishing Contexts to the desktop evironment. I've already put the hooks into libplasma, but the Nepomuk side is still being defined. Until then, I get to work on other things ... like the Twitter stuff. Unfortunately, I only got out half the emails I was supposed to today, so I'll have to finish those off tomorrow as well.
Then next week it's off to finish of Service/JOLIE integration and clear out the panel hiding TODOs.
No rest for the wicked ...
It's also apparently "reconnect with Aaron" time of year: not only has the P-man returned (though that was expected), two old friends that I haven't talked to in a while (one for nearly a year, the other for nearly eleven years) showed up randomly in the last 48 hours for some really interesting conversation. I wonder who will appear next ... ...
It was one of the older engines, and as such had a lot of less than pretty work arounds inside it. What really motivated me to finally look into was that it used QHttp, which means all sorts of bad things like not knowing about web proxies. Thiago is about to commit a change to KDE's CMake support that will deny QHttp usage in KDE apps because it is just that broken.
So I slapped on my hip waders and started tearing the engine apart. First I created a pair of DataContainer classes (one for the status timelines and one for getting user images) that encapsulate the individual HTTP requests; now the TwitterEngine doesn't have to multiplex all those jobs and the code to massage the results into order is neatly tucked into each class.
Finally, I created a Plasma::Service so setting the password for an account or updating the status (aka "tweeting") is not hackish at all anymore. Even nicer, the password is no longer visible outside of the DataEngine itself.
Update: In my rush to write this entry, I completely forgot to include the conclusion: that the DataEngine pattern used along with KDE's libraries and Qt makes it easy enough to write something like this in just a portion of a day. The new engine is also only about 20-30 lines more code than the old one but a hell of a lot more readable and debuggable, which shows how nicely the DataEngine classes have matured over the last year or so.
Thankfully the Twitter plasmoid was the only user of this engine, so I was free to change things about nearly at will like this. The downside is that right now the Twitter plasmoid is rather broken in svn. Tomorrow I'll be hacking on plasmaengineexplorer so that one can interact with Services associated with a DataEngine source and fixing the applet.
I'll also be finally adding a DataEngine design description tomorrow while I'm at it. It's kind of impressive how many details have been covered in the DataEngine classes to make it stupid simple and efficient to use, but things are fairly well in order now it seems after another round of improvements were made for 4.2, mostly induced by increased usage of Plasma::Service and Plasma::DataContainer subclasses.
On Thursday I have a Nepomuk meeting on IRC after which I will hopefully have enough in place to talk about the work on publishing Contexts to the desktop evironment. I've already put the hooks into libplasma, but the Nepomuk side is still being defined. Until then, I get to work on other things ... like the Twitter stuff. Unfortunately, I only got out half the emails I was supposed to today, so I'll have to finish those off tomorrow as well.
Then next week it's off to finish of Service/JOLIE integration and clear out the panel hiding TODOs.
No rest for the wicked ...
It's also apparently "reconnect with Aaron" time of year: not only has the P-man returned (though that was expected), two old friends that I haven't talked to in a while (one for nearly a year, the other for nearly eleven years) showed up randomly in the last 48 hours for some really interesting conversation. I wonder who will appear next ... ...
Tuesday, September 02, 2008
back to school
The P-man arrived home two days ago after a month away out on the west coast. He spent a week at a summer camp just outside the village I spent most of my first 12 years of life in, and the rest of it with his mom in Vancouver.
I was very seriously considering moving out to Vancouver so that we (P, his mom and I) could be closer together. However, she's still overly busy in film school and so I had to choose two out of: work, take care of P. or move. The P-man and KDE are not exactly optional in my life, so the move lost and it's another year at least in Calgary.
P's happy about it as he gets to do another year of school at a place that is really working for him along with 20-something friends he made last year.
So after a month of living on my own rhythms again (which happily coincided with Akademy, no less), it's back to getting up at 06:30, driving to the school twice a day, etc.
The upside is that I have my favourite person I know around again and we get to hang out and do stuff together. =)
We went through all P's clothes in prep for school, and I picked up a new desk for his room for him to work at along with a new inexpensive but rather capable laptop (amazing what you can get for CA$650 these days: 3GB RAM, 250GB drive, dual core 2.something GHz processor ... crazy) so he can continue to explore that little corner of the world as well. We already installed OpenSuse and put KDE 4.1 on the laptop, but the desk isn't quite assembled yet. I need to haul some things out of his room to make for it.
Today was also the first large grocery shopping I've done in a month. When on my own I usually just buy a couple days at a time for what I want to cook, and even then I usually only eat one or two actual "meals" a day (though I snack throug the rest as I feel like it). But with P. around there's a more steady regime to follow and it's harder to just drop by the store every day or two, so we tend to do a Big Trip to the grocery store every 10-14 days (more for certain produce items, though).
It's interesting how much having people around changes the schedule.
Anyways .. enough babbling. It's back to regular work and school tomorrow, and I promise my next blog entry will be about something slightly more technical. ;)
I was very seriously considering moving out to Vancouver so that we (P, his mom and I) could be closer together. However, she's still overly busy in film school and so I had to choose two out of: work, take care of P. or move. The P-man and KDE are not exactly optional in my life, so the move lost and it's another year at least in Calgary.
P's happy about it as he gets to do another year of school at a place that is really working for him along with 20-something friends he made last year.
So after a month of living on my own rhythms again (which happily coincided with Akademy, no less), it's back to getting up at 06:30, driving to the school twice a day, etc.
The upside is that I have my favourite person I know around again and we get to hang out and do stuff together. =)
We went through all P's clothes in prep for school, and I picked up a new desk for his room for him to work at along with a new inexpensive but rather capable laptop (amazing what you can get for CA$650 these days: 3GB RAM, 250GB drive, dual core 2.something GHz processor ... crazy) so he can continue to explore that little corner of the world as well. We already installed OpenSuse and put KDE 4.1 on the laptop, but the desk isn't quite assembled yet. I need to haul some things out of his room to make for it.
Today was also the first large grocery shopping I've done in a month. When on my own I usually just buy a couple days at a time for what I want to cook, and even then I usually only eat one or two actual "meals" a day (though I snack throug the rest as I feel like it). But with P. around there's a more steady regime to follow and it's harder to just drop by the store every day or two, so we tend to do a Big Trip to the grocery store every 10-14 days (more for certain produce items, though).
It's interesting how much having people around changes the schedule.
Anyways .. enough babbling. It's back to regular work and school tomorrow, and I promise my next blog entry will be about something slightly more technical. ;)
Subscribe to:
Posts (Atom)
