There seems to be some concern amongst users about the massive surgery we did on libplasma this past month. The concern stems from the idea that these changes will work against the stabilization of libplasma and result in prolonging a "beta" quality to plasma itself.
It's important to first understand that these changes were planned, even before 4.0. We knew that "widgets on canvas" was coming and so we could eventually remove our own layouting and QWidget bridges at some point for something that was more robust and less of a hack. We also knew that being a first revision of a library API (application programmer's interface) that would see a lot of usage, it was highly likely that changes would come to be needed or wanted. It's nearly impossible to foretell exactly what will be used and required in such an API, and it's really unrealistic to hope that the first draft of the semantics in an API will be optimal any more than it is to expect the first draft of a novel to not need any editing and revising.
So before 4.0 came out I told everyone that libplasma would not be binary compatible between 4.0 and 4.1 so that we could reshape the API as needed to make it last longer. I told everyone that we'd be porting to widgets on canvas when we could begin using Qt 4.4. I told everyone that we'd be replacing the icons-on-desktop implementation with something more robust that offered access to the same features.
This was all known and planned for before 4.0 was released. None of them could be done in 4.0 for various reasons (such as Qt 4.4 not being available to us), and so we lived with various hacks and bodges.
Moving to the development of 4.1, we executed on these changes. Right now plasma is approximately as stable and in most areas a bit more featureful than what is in 4.0.4, even with all those backports we did to catch up the 4.0 branch. There are a few regressions that remain in the development tree right now, but they are disappearing with rapidity. But being able to finally see things happen that we always imagined, such as the device notifier expanding from an icon to the full view when dropped onto the desktop (aka "adjusting the visualization in response to the form factor"), is very rewarding to watch happen.
There has been one downside to the massive changes: it took time away from creating more new features. So some of the plasmoids I wanted to have working for 4.1 may not happen and get punted to 4.2 instead. Thankfully with all this work done, features that do get worked on from here out should be easier to accomplish than when working with the 4.0 API.
Thankfully we will not have to repeat this process again during the 4.x time frame. We will be able to move forward with keeping the API in place. We will add to it as needed, which isn't disruptive, while modifications such as these ones for 4.1 simply won't be on the table.
So if you are concerned about the recent changes made impacting stability, I thank you for your concern and empathize with how one could arrive at such a conclusion. Thankfully, these changes have been made specifically to answer your concerns, as well as mine, about stability and feature completeness both in 4.1 and beyond.
I hope that clears up a few things. If not, you may wish to track the betas and release candidates as they begin to appear near the end of May and see for yourself.
Wednesday, April 30, 2008
improving freedesktop.org processes
The other day, Vincent Untz requested a git repo to house all freedesktop.org specs. I liked the idea a lot.
Coincidentally, I was simultaneously involved in a conversation via private email with a few other freedesktop.org people about the processes around creating specifications (or lack thereof), so I took this as a cue to step back and really think about it a bit. freedesktop.org is one of the key points where the the free software world comes together to document the things we share so that integration and consistency (from the user's POV) can be achieved, so keeping it healthy is really important.
I also talked with Zack about some of the issues and he shared some really interesting insights he's taken from the OpenGL specification process.
This led to me writing a proposal for how we could improve the specification process in concrete terms.
It includes mechanisms for creating new specs as well as drafts of existing ones; it proscribes documenting in the specs themselves where they are implemented (e.g. which version of which software product); it proposes settling on some naming conventions that denote exactly the adoption state of implemented specs (draf, review, accepted; project specific, shared or broadly blessed and therefore "freedesktop.org"). The emphasis is on removing manual processes and creating a self-documenting, transparent system based on participation.
Inherent in the proposal is the idea that the repository should be shared by all editors and be considered canonical. The freedesktop.org website would be an easy access point to the documentation contained within the repository, but would no longer be considered the canonical source. While we could use a distributed version control system, such as git, this implies that we would sync work into the shared repository so everyone can follow progress: no more back rooms or unknown corners.
It also removes any need for a formal oversight committee (gah! bureaucracy!) while making the process fully self-documenting by the process of specification development itself.
It's not a revolutionary concept by any means, but it's something freedesktop.org really needs to keep the wheels moving. There seems to be general support for such a reform, and we're down to discussing details. Vincent has wisely given us a 10 day cap to discuss and come to consensus, so I suppose we can expect to see something good happen shortly. Color me happy.
Coincidentally, I was simultaneously involved in a conversation via private email with a few other freedesktop.org people about the processes around creating specifications (or lack thereof), so I took this as a cue to step back and really think about it a bit. freedesktop.org is one of the key points where the the free software world comes together to document the things we share so that integration and consistency (from the user's POV) can be achieved, so keeping it healthy is really important.
I also talked with Zack about some of the issues and he shared some really interesting insights he's taken from the OpenGL specification process.
This led to me writing a proposal for how we could improve the specification process in concrete terms.
It includes mechanisms for creating new specs as well as drafts of existing ones; it proscribes documenting in the specs themselves where they are implemented (e.g. which version of which software product); it proposes settling on some naming conventions that denote exactly the adoption state of implemented specs (draf, review, accepted; project specific, shared or broadly blessed and therefore "freedesktop.org"). The emphasis is on removing manual processes and creating a self-documenting, transparent system based on participation.
Inherent in the proposal is the idea that the repository should be shared by all editors and be considered canonical. The freedesktop.org website would be an easy access point to the documentation contained within the repository, but would no longer be considered the canonical source. While we could use a distributed version control system, such as git, this implies that we would sync work into the shared repository so everyone can follow progress: no more back rooms or unknown corners.
It also removes any need for a formal oversight committee (gah! bureaucracy!) while making the process fully self-documenting by the process of specification development itself.
It's not a revolutionary concept by any means, but it's something freedesktop.org really needs to keep the wheels moving. There seems to be general support for such a reform, and we're down to discussing details. Vincent has wisely given us a 10 day cap to discuss and come to consensus, so I suppose we can expect to see something good happen shortly. Color me happy.
Monday, April 28, 2008
... on scripting
Whenever one creates something, the question "who is my audience?" is pretty important. Even if you don't ask it explicitly, there is an answer implicit in your performance. It is one of those "no answer is an answer" scenarios; the answer can not be escaped even if the question is avoided.
So I like to ask myself that question explicitly... and a lot. The answer changes both from project to project as well as over time. I used to play music for other people to listen to, but these days I play it just for myself. (I'm pretty sure the world is a happier place for it, too. ;) Plasma, however, it meant as a public participation project and we have only bigger plans for it down the line. As such, it's always interesting to see other people's take on it, such as in this article by Brian Proffitt the other week. I can't tell anyone what Plasma is for them, really, and given that people have a variety of thoughts on that matter is pretty cool.
We talked about target audience a fair bit at Tokamak I. When it came to scripting, it was no exception. It turned out that I had a mildly different idea of the target audience for the scripting compared to others who are involved. This is probably in part due to the fact that I'm not an "interpreted languages guy". Don't get me wrong: I looove the ruby .. but I code mostly still in C++. So instead of coming at it from a "interpreted languages (IL) are awesome and a reason in and of themselves" I perhaps come at it from a slightly more cautious position that asks first and foremost: who is the audience?
With Plasma scripting, I see three audiences: libplasma, ninjas and myspacers. Ok, I'm sure none of that made any sense to most of you, so let me explain.
First off, I know that libplasma isn't a sentient being. Yet. ;) So when I say that libplasma is one of the audiences, I mean that libplasma itself needs to have a way to work with the scripting that isn't an afterthought or some transparent magical loading of scripts. The scripting interface needs to be purposeful, manageable, integrated with other parts of libplasma and possible to be made safe. I have been surprised at how the relationship to libplasma is often not even talked about when discussing scripting; perhaps the IL people are just too used to fending for themselves and not being considered seriously during the design phase.
The result of this awareness is a set of well defined interfaces between libplasma and the IL support. This allows for uniform and extremely flexible possibilities (in terms of language and exposed API) when it comes to IL support. It also means that we are designing whole areas of libplasma around the eventual use cases for interpreted languages in Plasma; in fact, the new widget API for 4.1 was designed 100% for the foundation of sane IL API exporting. In fact, it was designed by Richard Moore, the IL guy at Tokamak. This was not an accident: he was tasked with this specifically because he could design it from that perspective better than someone like poor old C++ me.
What about the other two audiences I mentioned: ninjas and myspacers? Well, now we're talking about real people again, at least in abstract terms.
Ninjas are people who are awesome at what they do. Unfortunately, most people aren't good at a given topic (though a lot of people, perhaps even most, are good at some topic). That means that if you pick a certain endeavor, there will be few ninjas of that sort. So it is that there are likely to be few widget making ninjas out there, relative to the size of the audience. Fortunately, they make awesome stuff that most of the user audience will want to pick up on.
By opening up Plasma to other widget systems such as SuperKaramba and MacOS Dashboard we widen our ninja audience. This is one reason having "libplasma" as an audience is so important.
However, we want Plasma Ninjas too. In fact, it would be great if there were evntually more Plasma Ninjas than other kinds of widget ninjas. (Yes, I know that will require market share to achieve. We're working on it ;) What do Plasma Ninjas need? More than anything else, they need a powerful API. I think they also will probably want a design studio, something we'll eventually get to working on. First comes the API, however. So we want to give these ninjas the ability to do much of what you could in C++, only faster, slicker and with fewer stupid details.
Now quickly move to the next audience: myspacers. That's my pet term for the kind of people who glom onto sites that let you easily modify an interface with a little bit of work. They looooove tinkering but their skill level is pretty low. They also tend not to create things very often that many other people would want to use. However, there are a lot of them.
What do the myspacers need? A stupidly simple API, and certainly a point and clicky designy thingy. Making a simple clicky designy thingy (a toy level design studio) requires a really simple API; Macromedia's flash studio tools are beyond this kind of person, generally. That gives you an idea of the simplicity required.
I don't think there's anything wrong with this either: there's nobody who stops you from buying paint and paintbrushes from the art supply store just because your painting skills are questionable. So there shouldn't be any reason to do similarly to people whose aesthetic or coding skills are similar (so long as we don't inflict their work on you, right? ;)
The value in the myspacer crowd is that they make products popular. More and more participation means winning when it comes to concepts such as these. I want to let the myspacers of the world make and share their probably pointless-in-the-big-picture but extremely personally satisfying (to them and their friends) things. Excuse the buzzwordy nature of this, but: democratizing creativity.
If you think that audience doesn't exist, I would ask you to go visit myspace for a moment. Or go hang out at a local hobby shop; check out how many hobbyist painters, fly tiers, sportsmen, etc there are out there. People are creative and put effort into things .. they just tend to be pretty mediocre at it. This audience is not only large but, from a human perspective, deserves the chance to play too.
Now we have a dilemma: we have two groups, both of whom it would be nice to service, but who have very different needs. Both are valuable, however, in terms of "audience" which is an aggregate of number of users of widgets and number of creators of widgets. Perhaps a picture sums it up best:
To optimize a widget system for one group will cut out the other one due to skill differences; either you'll get something too complex for the myspacers or too limiting and toy-like for the ninjas. Or worse, the API will cater to a group somewhere in the middle and instead of maximizing the audience the API will guarantee a minimizing.
Of course, API is just on part of the equation: support tools is another, but market share is probably the biggest. Myspacers are flockers and ninjas go for audience reach. But those are ingredients that must come after having the right scripting API.
The solution? Well, I don't know if there is just one solution per say, but here's mine: we're going to have two different kinds of APIs. One for ninjas. One for myspacers. Plasma's design allows for that, even using the same programming language for both since we differentiate based on target API not implementation language. As a neat side effect, it turns out that the myspacer style API is also a hell of a lot easier to secure.
So there you have it: my very long winded explanation for why there will be multiple scripting APIs in plasma. It all starts with the question of who our audience is and the moves on to how to stand a chance of capturing them.
Now I have to go to the airport to pick up Zack. *hugs*
So I like to ask myself that question explicitly... and a lot. The answer changes both from project to project as well as over time. I used to play music for other people to listen to, but these days I play it just for myself. (I'm pretty sure the world is a happier place for it, too. ;) Plasma, however, it meant as a public participation project and we have only bigger plans for it down the line. As such, it's always interesting to see other people's take on it, such as in this article by Brian Proffitt the other week. I can't tell anyone what Plasma is for them, really, and given that people have a variety of thoughts on that matter is pretty cool.
We talked about target audience a fair bit at Tokamak I. When it came to scripting, it was no exception. It turned out that I had a mildly different idea of the target audience for the scripting compared to others who are involved. This is probably in part due to the fact that I'm not an "interpreted languages guy". Don't get me wrong: I looove the ruby .. but I code mostly still in C++. So instead of coming at it from a "interpreted languages (IL) are awesome and a reason in and of themselves" I perhaps come at it from a slightly more cautious position that asks first and foremost: who is the audience?
With Plasma scripting, I see three audiences: libplasma, ninjas and myspacers. Ok, I'm sure none of that made any sense to most of you, so let me explain.
First off, I know that libplasma isn't a sentient being. Yet. ;) So when I say that libplasma is one of the audiences, I mean that libplasma itself needs to have a way to work with the scripting that isn't an afterthought or some transparent magical loading of scripts. The scripting interface needs to be purposeful, manageable, integrated with other parts of libplasma and possible to be made safe. I have been surprised at how the relationship to libplasma is often not even talked about when discussing scripting; perhaps the IL people are just too used to fending for themselves and not being considered seriously during the design phase.
The result of this awareness is a set of well defined interfaces between libplasma and the IL support. This allows for uniform and extremely flexible possibilities (in terms of language and exposed API) when it comes to IL support. It also means that we are designing whole areas of libplasma around the eventual use cases for interpreted languages in Plasma; in fact, the new widget API for 4.1 was designed 100% for the foundation of sane IL API exporting. In fact, it was designed by Richard Moore, the IL guy at Tokamak. This was not an accident: he was tasked with this specifically because he could design it from that perspective better than someone like poor old C++ me.
What about the other two audiences I mentioned: ninjas and myspacers? Well, now we're talking about real people again, at least in abstract terms.
Ninjas are people who are awesome at what they do. Unfortunately, most people aren't good at a given topic (though a lot of people, perhaps even most, are good at some topic). That means that if you pick a certain endeavor, there will be few ninjas of that sort. So it is that there are likely to be few widget making ninjas out there, relative to the size of the audience. Fortunately, they make awesome stuff that most of the user audience will want to pick up on.
By opening up Plasma to other widget systems such as SuperKaramba and MacOS Dashboard we widen our ninja audience. This is one reason having "libplasma" as an audience is so important.
However, we want Plasma Ninjas too. In fact, it would be great if there were evntually more Plasma Ninjas than other kinds of widget ninjas. (Yes, I know that will require market share to achieve. We're working on it ;) What do Plasma Ninjas need? More than anything else, they need a powerful API. I think they also will probably want a design studio, something we'll eventually get to working on. First comes the API, however. So we want to give these ninjas the ability to do much of what you could in C++, only faster, slicker and with fewer stupid details.
Now quickly move to the next audience: myspacers. That's my pet term for the kind of people who glom onto sites that let you easily modify an interface with a little bit of work. They looooove tinkering but their skill level is pretty low. They also tend not to create things very often that many other people would want to use. However, there are a lot of them.
What do the myspacers need? A stupidly simple API, and certainly a point and clicky designy thingy. Making a simple clicky designy thingy (a toy level design studio) requires a really simple API; Macromedia's flash studio tools are beyond this kind of person, generally. That gives you an idea of the simplicity required.
I don't think there's anything wrong with this either: there's nobody who stops you from buying paint and paintbrushes from the art supply store just because your painting skills are questionable. So there shouldn't be any reason to do similarly to people whose aesthetic or coding skills are similar (so long as we don't inflict their work on you, right? ;)
The value in the myspacer crowd is that they make products popular. More and more participation means winning when it comes to concepts such as these. I want to let the myspacers of the world make and share their probably pointless-in-the-big-picture but extremely personally satisfying (to them and their friends) things. Excuse the buzzwordy nature of this, but: democratizing creativity.
If you think that audience doesn't exist, I would ask you to go visit myspace for a moment. Or go hang out at a local hobby shop; check out how many hobbyist painters, fly tiers, sportsmen, etc there are out there. People are creative and put effort into things .. they just tend to be pretty mediocre at it. This audience is not only large but, from a human perspective, deserves the chance to play too.
Now we have a dilemma: we have two groups, both of whom it would be nice to service, but who have very different needs. Both are valuable, however, in terms of "audience" which is an aggregate of number of users of widgets and number of creators of widgets. Perhaps a picture sums it up best:
To optimize a widget system for one group will cut out the other one due to skill differences; either you'll get something too complex for the myspacers or too limiting and toy-like for the ninjas. Or worse, the API will cater to a group somewhere in the middle and instead of maximizing the audience the API will guarantee a minimizing.
Of course, API is just on part of the equation: support tools is another, but market share is probably the biggest. Myspacers are flockers and ninjas go for audience reach. But those are ingredients that must come after having the right scripting API.
The solution? Well, I don't know if there is just one solution per say, but here's mine: we're going to have two different kinds of APIs. One for ninjas. One for myspacers. Plasma's design allows for that, even using the same programming language for both since we differentiate based on target API not implementation language. As a neat side effect, it turns out that the myspacer style API is also a hell of a lot easier to secure.
So there you have it: my very long winded explanation for why there will be multiple scripting APIs in plasma. It all starts with the question of who our audience is and the moves on to how to stand a chance of capturing them.
Now I have to go to the airport to pick up Zack. *hugs*
.. and all the king's men
Unlike poor old Humpty Dumpty, Plasma was able to put itself back together again. Over the weekend the poor thing devolved into a pile of mush. Thanks to the amazing dedication and work of the Plasma developers, however, it's back to functional and we can start making forward progress again.
While this page is pretty fun to look at right now, I'm also struck at how much time and energy has gone into that. Having a good API that is consistent and sensible is important for longevity and for third party usage, so it was certainly worth it. That doesn't mean it wasn't a lot of hard running to just end up in the same place functionally, or that breaking other people's plugins is cool.
The goal is to transition libplasma to kdelibs in 4.2, and my personal goal is to prove we can keep both source and binary compatibility while increasing the number of add-ons by another great leap during 4.1. We just can't afford to break the work of others every release; we know that, and so while we bit the bullet this time (something I warned we'd be doing long before 4.0 itself was out even) I look forward to not doing it again for many, many years.
I know Kevin wants to do another round or two of polishing, but post-4.1 I really want to keep it to an absolute minimum of disruption. Such as zero. ;)
While this page is pretty fun to look at right now, I'm also struck at how much time and energy has gone into that. Having a good API that is consistent and sensible is important for longevity and for third party usage, so it was certainly worth it. That doesn't mean it wasn't a lot of hard running to just end up in the same place functionally, or that breaking other people's plugins is cool.
The goal is to transition libplasma to kdelibs in 4.2, and my personal goal is to prove we can keep both source and binary compatibility while increasing the number of add-ons by another great leap during 4.1. We just can't afford to break the work of others every release; we know that, and so while we bit the bullet this time (something I warned we'd be doing long before 4.0 itself was out even) I look forward to not doing it again for many, many years.
I know Kevin wants to do another round or two of polishing, but post-4.1 I really want to keep it to an absolute minimum of disruption. Such as zero. ;)
Wednesday, April 23, 2008
Deploying KDE to 52 million young people
Mauricio broke the news today in his blog about what can only be described as a massive deployment of free software. I'd heard about this project recently, but reading more of the details in Mauricio's blog really cemented in my mind how groundbreaking this is.
In summary: KDE on Linux has stepped up to become the software platform in the primary school education system in Brazil. That may sound like a bold claim, but the numbers are staggering and speak for themselves:
By the end of this year 29,000 labs serving some 32,000,000 students will be fully deployed and in active use.
By the end of next year (2009) those numbers will have swelled to 53,000 labs serving some 52,000,000 students.
The systems use KDE 3.5 and take full advantage of Debian as well as KDE's Edu and Games projects, use of KDE4 in future implementation is just starting to be explored. Perhaps one of the most interesting aspects of the deployment is how they maximize investment in hardware by putting several heads on each system.
What about the content used on these computers? Go see for yourself.
KDE 3.5 will be supported in the market for many years to come due to deployments such as this one. Looking towards the future, KDE4 will likely make some things even easier for them in the future, such as how to implement the navigation bar they added to the top of desktop as a result of usability research done involving this specific audience. With Plasma, a few lines of JavaScript is all that would be needed.
Brazil is rolling out an additional 150,000 portable machines in their "Um Computador por Aluno" project; those machines are Classmate PCs and though I haven't found out first hand yet what they will be running, my online spelunking seems to indicate they, too, are sporting KDE on Linux.
Brazil is not the only place in the world that things are heating up for Free software and KDE, but this has got to be one of the more exciting publicly announced projects going right now.
In a word, it is humongous.
You can learn more about this expansive project by reading Mauricio's blog entry. I encourage you to head over and take a peak if you haven't already done so.
In summary: KDE on Linux has stepped up to become the software platform in the primary school education system in Brazil. That may sound like a bold claim, but the numbers are staggering and speak for themselves:
By the end of this year 29,000 labs serving some 32,000,000 students will be fully deployed and in active use.
By the end of next year (2009) those numbers will have swelled to 53,000 labs serving some 52,000,000 students.
The systems use KDE 3.5 and take full advantage of Debian as well as KDE's Edu and Games projects, use of KDE4 in future implementation is just starting to be explored. Perhaps one of the most interesting aspects of the deployment is how they maximize investment in hardware by putting several heads on each system.
What about the content used on these computers? Go see for yourself.
KDE 3.5 will be supported in the market for many years to come due to deployments such as this one. Looking towards the future, KDE4 will likely make some things even easier for them in the future, such as how to implement the navigation bar they added to the top of desktop as a result of usability research done involving this specific audience. With Plasma, a few lines of JavaScript is all that would be needed.
Brazil is rolling out an additional 150,000 portable machines in their "Um Computador por Aluno" project; those machines are Classmate PCs and though I haven't found out first hand yet what they will be running, my online spelunking seems to indicate they, too, are sporting KDE on Linux.
Brazil is not the only place in the world that things are heating up for Free software and KDE, but this has got to be one of the more exciting publicly announced projects going right now.
In a word, it is humongous.
You can learn more about this expansive project by reading Mauricio's blog entry. I encourage you to head over and take a peak if you haven't already done so.
Plasma SoC
The Google Summer of Code 2008 is underway and we have a handful of projects related to Plasma set to go.
I'll personally be working as mentor to two projects: Aike Jan Sommer on his "Easy monitor hot-plug support in KDE" project which will ensure Plasma works Perfectly(tm) no matter what sort of runtime torture you apply to it in the form of displays coming, going and rearrannging; and Rob Scheepmaker on "Implement the 'extender' interface concept in plasma". Both Aike and Rob worked extensively prior to submitting their proposals on researching exactly what the project definitions should be and how to tackle them successfully. This even led to patches in some cases that are already in svn right now for 4.1. I was quite impressed with both of their efforts.
Aside from those two projects, we also have Chani working on "Plasma Widgets on the Screensaver" which is not only going to be coolicious but serves as a great use case (aka "excuse" ;) for working on some of the security scaffolding we currently need to have in place. Chani, who has Sebas assigned as mentor, will likely blog more about her plans, so I won't steal too much of her thunder here.
Then there is Marijn Kruisselbrink who will be working with Ade on "KDE/Plasma for small form-factor devices". We've been able to bring together a number of sources for hardware for Marijn to work on; as those devices show up I (or even better, Marijn?) will blog about them. The goal here is to work on realizing the ubuiquity dream that is part of the Way of the Plasma. Marijn had previously already gotten Plasma working on an OpenMoko Neophone (as well as MacOS, incidently) so he's proven himself in this area already. We're aiming for more than just "works" though, Marijn will be working towards "kicks ass".
Imagine moving widgets between your desktop system and your mobile device (laptop, UMPC, tablet, phone ...?) and walking out the door with them! That (and a lot of practical applications that I can't talk about quite yet) is what we'll get with proper small form factor support mated with JOLIE support.
Joseph Burns will be working on "Plasmagik: The Packager" with Riccardo as his mentor. This project is important as it will be one of key pieces of the Plasma Creative Toolkit for people to put together plasmoids, themes, engines, etc for uploading and sharing. A low barrier to entry is more than just API beauty and scripting languages: it's also about how to get the results from point A (the author) to point B (the audience).
There's also an Amarok2 project that will be working with the Plasma bits they are using, so that can't hurt either.
Unfortunately, none of the KRunner related projects made it through the final cut. This is not because they were poor proposals, but simply because we had so many excellent proposals and the impact of KRunner along with what needs to be done to it still is not widely appreciated in our developer community yet. Combined, that made it hard to get KRunner proposals through. Hopefully next year, though, as the KRunner hackers could probably use the dedicated time to fully achieve their goals and dreams.
Overall though, I'm pretty excited about the possibilities: we have mostly proven contributors with a couple of new prospects all working on well thought out and ultimately useful projects that should fit well within the time frame defined by the program.
I didn't get to participate all that much in the final selection process and I do think that it could be done better next year (particularly the web interface Google provides which is a pure nightmare for umbrella projects such as KDE), but to complain at this point would be staring a gift horse in the mouth. Hopefully we can work to improve things for next year, of course, though this year is probably going to be even more rewarding for the KDE project (and, therefore, you) than last year was. Huzzah!
I'll personally be working as mentor to two projects: Aike Jan Sommer on his "Easy monitor hot-plug support in KDE" project which will ensure Plasma works Perfectly(tm) no matter what sort of runtime torture you apply to it in the form of displays coming, going and rearrannging; and Rob Scheepmaker on "Implement the 'extender' interface concept in plasma". Both Aike and Rob worked extensively prior to submitting their proposals on researching exactly what the project definitions should be and how to tackle them successfully. This even led to patches in some cases that are already in svn right now for 4.1. I was quite impressed with both of their efforts.
Aside from those two projects, we also have Chani working on "Plasma Widgets on the Screensaver" which is not only going to be coolicious but serves as a great use case (aka "excuse" ;) for working on some of the security scaffolding we currently need to have in place. Chani, who has Sebas assigned as mentor, will likely blog more about her plans, so I won't steal too much of her thunder here.
Then there is Marijn Kruisselbrink who will be working with Ade on "KDE/Plasma for small form-factor devices". We've been able to bring together a number of sources for hardware for Marijn to work on; as those devices show up I (or even better, Marijn?) will blog about them. The goal here is to work on realizing the ubuiquity dream that is part of the Way of the Plasma. Marijn had previously already gotten Plasma working on an OpenMoko Neophone (as well as MacOS, incidently) so he's proven himself in this area already. We're aiming for more than just "works" though, Marijn will be working towards "kicks ass".
Imagine moving widgets between your desktop system and your mobile device (laptop, UMPC, tablet, phone ...?) and walking out the door with them! That (and a lot of practical applications that I can't talk about quite yet) is what we'll get with proper small form factor support mated with JOLIE support.
Joseph Burns will be working on "Plasmagik: The Packager" with Riccardo as his mentor. This project is important as it will be one of key pieces of the Plasma Creative Toolkit for people to put together plasmoids, themes, engines, etc for uploading and sharing. A low barrier to entry is more than just API beauty and scripting languages: it's also about how to get the results from point A (the author) to point B (the audience).
There's also an Amarok2 project that will be working with the Plasma bits they are using, so that can't hurt either.
Unfortunately, none of the KRunner related projects made it through the final cut. This is not because they were poor proposals, but simply because we had so many excellent proposals and the impact of KRunner along with what needs to be done to it still is not widely appreciated in our developer community yet. Combined, that made it hard to get KRunner proposals through. Hopefully next year, though, as the KRunner hackers could probably use the dedicated time to fully achieve their goals and dreams.
Overall though, I'm pretty excited about the possibilities: we have mostly proven contributors with a couple of new prospects all working on well thought out and ultimately useful projects that should fit well within the time frame defined by the program.
I didn't get to participate all that much in the final selection process and I do think that it could be done better next year (particularly the web interface Google provides which is a pure nightmare for umbrella projects such as KDE), but to complain at this point would be staring a gift horse in the mouth. Hopefully we can work to improve things for next year, of course, though this year is probably going to be even more rewarding for the KDE project (and, therefore, you) than last year was. Huzzah!
Saturday, April 19, 2008
if april showers...
If April showers bring May flowers (as the English saying goes), then what the $#&! do April snow storms bring? They'd better bring more than flowers, because as much as I love them a snowstorm requires a bit more. Maybe a small piece of jewelry, a massage or a nice night out on the town. ;)
The P-man and I arrived yesterday evening into Calgary from Frankfurt and they nearly had to divert us to Edmonton due to conditions on the ground, namely thick blowing snow. Not pretty.
We made out way home in a cab, snowing all the way, and I was left wondering if we hadn't gone through some temporal distortion warping us back to more traditionally winter months. Then, through the jet lag I remembered: this is Calgary. It can snow whenever it damn well feels like it.
I'm taking the weekend off from hacking, though I didn't manage to do the same for email so far. I played with ignoring my email, but 24 mails sent later I've obviously failed at that. ;)
I'm missing Europe already, mostly due to the snow and the great friends left behind there, I think. For now, I think I'm going to go curl up in front of a movie and relax a bit. See you on Monday =)
The P-man and I arrived yesterday evening into Calgary from Frankfurt and they nearly had to divert us to Edmonton due to conditions on the ground, namely thick blowing snow. Not pretty.
We made out way home in a cab, snowing all the way, and I was left wondering if we hadn't gone through some temporal distortion warping us back to more traditionally winter months. Then, through the jet lag I remembered: this is Calgary. It can snow whenever it damn well feels like it.
I'm taking the weekend off from hacking, though I didn't manage to do the same for email so far. I played with ignoring my email, but 24 mails sent later I've obviously failed at that. ;)
I'm missing Europe already, mostly due to the snow and the great friends left behind there, I think. For now, I think I'm going to go curl up in front of a movie and relax a bit. See you on Monday =)
Friday, April 18, 2008
home();
i'm laying in a bed in a hotel in frankfurt, germany finishing up going through my email and starting to sort through my thoughts about the last two weeks. the time in toulouse was beautiful, the plasma sprint was inspiring (the api reviews are now largely implemented even! a dot story by sebas is mostly complete ... ) and the board meetings over the last two days were simply phenomenal. but now at 08:20 and a pile of clothes and sundries to pack sprawling across the day bed i just look forward to getting home and sleeping for most of the weekend. the p-man has gotten an early start to that plan, it seems and is soundly snoozing away in the next bed.
the akademy 2008 call for presentations deadline is coming up real soon now: less than two weeks are left! so please get your proposals in so we can draw up the schedule sooner rather than later and fill it with great titles to be given by great people. if you're working on a kde related technology, that means you. =)
i'm off to the bathtub for a warm soak before breakfast and then will likely be away from active emailing for a day or two .. see you on the flip side.
the akademy 2008 call for presentations deadline is coming up real soon now: less than two weeks are left! so please get your proposals in so we can draw up the schedule sooner rather than later and fill it with great titles to be given by great people. if you're working on a kde related technology, that means you. =)
i'm off to the bathtub for a warm soak before breakfast and then will likely be away from active emailing for a day or two .. see you on the flip side.
Tuesday, April 15, 2008
milano tokamak concludes, the show moves to frankfurt
Tokamak::Mark(1)
Tokamak over and now I'm sitting in the KDE offices in Frankfurt. It was awesome meeting everyone, several for the first time in spite of having worked with them continuously, in same cases nearly daily, for the last 6-24 months (depending on the individual), for 4.5 days of intense meetings and hacking.
Tokamakaos - Danger, Will Robinson!
The success of the event lays on the shoulders of several people:
* a huge thanks to Riccardo and his family for providing a truly great location for the event and being awesome hosts
* Alexis for leading the charge towards finally getting WoC in svn, and Sebas for being his wingman (not to mention those following along on irc and getting things in great order)
* to Kevin and Richard for taking charge of the API review and putting in long, hard days to make sure we dragged ourselves through it (we're talking about spending 16 hours at a stretch pouring meticulously line by line through headers)
* to Richard for coming through on the scripting side (despite my grumpiness on the first day); to Marco (go-go panel toolbox!)
* to David, Chani, Andre, and Riccardo for working on various and sundry useful and important features and bug fixes; Nuno for rocking the Inkscape;
* to Franz for showing up in his KDE car (it has awesome KDE decals on both sides and the back, along with our URL) with great Austrian beer
* to Andreas for coming down from Oslo to share both the present and the future of QGraphicsView (holy crap are we going to blow people's mind in the next couple years on the graphics and animations front)
* Luka to making it out for a day to hang out, hack and share
* to the JOLIE people for their excellent presentation and groundwork for future collaboration (they've already started in on things, exciting!) ...
That's what it takes: lots of people Doing Their Thing(tm).
The Tokamakers ROCKED!
And the results?
- Widges on canvas: improved layouts (to say the least), QProxyWidget usage (so the device notifier shows its full interface when not in a Vertical/Horizontal containment (e.g. on the desktop, in dashboard, etc) and hundreds of lines of code removed from libplasma
- A significant number of nasty beasties tamed and expelled from the codebase
- The new krunner UI at long last well underway!
- Panel toolbox plan worked out and partly implemented
- A killer set of replacements for our current widgets that are tailored for script access and which will allow us to provide a simple but safe API, for even untrusted widgets
- Way too much pizza being eaten (34 boxes towered in a stack on the kitched table when we left ... no stack overflow, however ;)
- hundreds of API improvements to be made
- a better understanding of core concepts, user targets and future goals
- new and improved personal bonds between those who attended. Go community!
Yes, we were also serious from time to time ;)
It was pretty amazing how we completely ripped Plasma into pieces and got it mostly back together in just a couple days, with a much much better foundation to build on.
Moving fast at Tokamak
Also part of the fall out of Tokamak is that I have a new development tool ... gwenview! ;)
Those are some of the photos we took of the white board used during the API review sessions. As you can see, there are a few (*ahem*) changes to be affected. We're going to be keeping track of progress using the wiki. While the whiteboard is (almost) perfect for doing the API reviews on, the wiki is (almost) perfect for coordinating the implementation of the resulting fix recommendations. If you'd like to help us out, you can see all the Tokamak whiteboards (at readable resolutions!) yourself in this photo album and transcribe them onto the Tokamak wiki page. (Hint: The class being reviewed is written in top right corner of each board.)
While at Tokamak, I finally got compositing working flawlessly on my laptop. I've already made some small improvements to a couple of the effects due to using them. I (and probably Sebas) will blog about that stuff later, though. The effects are fairly easy to hack on, make really nice sized projects and offer immediate response/reward.
Anyways, I need to head out to the hotel now and get cleaned up for dinner. Two days of board and business meetings await.
The P-man, aka The Youngest Tokamaker, charts the future
In completely unrelated news, it seems the KDE team rocked the house at Lug Radio Live USA with an impressive looking booth and a great team behind it! =)
Sunday, April 13, 2008
day N
day .. uhm .. something of the event. code flies in every direction, we spent much of today doing API reviews in person of libplasma which is a hugely mentally tasking thing to do .. massive breakages in libplasma due to the move to WoC, though things slowly are coming back together .. many new features, a couple very interesting meetings (e.g. with the JOLIE people about bringing very sophisticated SOA infrastructure to plasma enabled applications and devices), some amazing food and of course getting to know my fellow developers even better.
i'm not going to spend too much time blog writing right now as we only have another 1.5 days together, and sebas is waiting for me to come help debug something while chani is working on a patch i threw together earlier to work out kinks.
more extensive entries when i'm in germany =)
i'm not going to spend too much time blog writing right now as we only have another 1.5 days together, and sebas is waiting for me to come help debug something while chani is working on a patch i threw together earlier to work out kinks.
more extensive entries when i'm in germany =)
Saturday, April 12, 2008
who are our users?
starting with Celeste's prelim findings we discussed our user focus yesterday. it was a spirited and useful conversation with everyone participating and offering their viewpoints.
while we do have a huge audience, given that we're working on tools for entry point user interfaces, we do have a focus on the more adventurous and often more experienced though we are moving more towards a more moderate user profile.
taking technical, reality (e.g. who our user base is right now and will be in the next 2-3 years) and communication issues into consideration we have a much clearer idea of who our user focus is. we'll continue to work on this to produce a full user profile report that we can use as a center point in this ongoing conversation with ourselves.
Andreas "GraphicsView" Hanssen from Trolltech joined us late last night and is giving today's morning presentation on QGraphicsView in Qt 4.4. the sound of keyboards ticking and machines compiling fills the spaces between his words =)
while we do have a huge audience, given that we're working on tools for entry point user interfaces, we do have a focus on the more adventurous and often more experienced though we are moving more towards a more moderate user profile.
taking technical, reality (e.g. who our user base is right now and will be in the next 2-3 years) and communication issues into consideration we have a much clearer idea of who our user focus is. we'll continue to work on this to produce a full user profile report that we can use as a center point in this ongoing conversation with ourselves.
Andreas "GraphicsView" Hanssen from Trolltech joined us late last night and is giving today's morning presentation on QGraphicsView in Qt 4.4. the sound of keyboards ticking and machines compiling fills the spaces between his words =)
Friday, April 11, 2008
day 1
wow. what a day. introductions in the morning, a sharing of hot button issues, lunch, developer meetings, hacking, dinner, more hacking. not a lot to show that's fun and interesting yet to those outside, but it's been awesome to see everyone, meet a few new faces and get the wheels rolling on a number of things. by the end of the sprint, there will be significant positive changes to be seen all over the place. but it's 01:00 and i'm heading back to the hotel to go to sleep so i can get up first thing in the morning.
Thursday, April 10, 2008
goodbye Toulouse, hello Milano
We are about to leave Toulouse behind; our bags are packed and waiting in the living room. Kevin and V. have been terrific hosts for us here and P. has enjoyed the sights, sounds and textures of this land. Together we have visited museums (fine art, aerospace), flower gardens, a Buddhist monestary and walked through the town from various angles. We even ran into some KDE hackers other than Kevin. But all good things must come to an end.
All ends are just another beginning, and in this case it is the beginning of Tokamak Mark I. For four days, starting tomorrow, over a dozen people will converge just outside Milano, Italy to work on Plasma, chart its future for 4.1 and beyond and do some community building in the process.
I'll be blogging at least daily during the event, as I'm sure others will be as well, to keep everyone abreast of what what is going down. It's going to be humongous.
I also received confirmation that I'll be presenting the international keynote at LinuxTag on Wednesday the 28th of May. The talk will be about the future of the desktop in a mobile, "web 2.0" world and the role of KDE 4 in all of that. Hopefully I'll also be presenting in the KDE track, though that schedule is still being worked out. So if you can make it to Berlin, it would be great to see you there!
Wednesday, April 09, 2008
RE: Nine Improvements Needed in KDE, by Bruce Byfield
Dear Bruce ..
Thanks for trying KDE 4.0.x and then writing about it. It's always great when people try something for a while and then give their honest opinion on things. I'd like to address some of the issues you raise, so let's start where you started:
"A more customizable panel": the issues you note, from resizing and moving to not covering the toolbox, are already addressed in svn with the exception of autohiding which is currently partially working in a WIP patch. So this set of issues is more past tense than anything at this point. There remain some burrs to work out, such as not all widgets accommodating really small panels very well still or easy moving of applets.
"A better menu": This one is less clear. You state that it seems to be based on the XP/Vista menus, yet other than having a header and a footer I really don't see many overt similarities. Vista introduced integrated search, but that's a no-brainer. Kickoff isn't a two-pane model, it has tabs .. I could go on. Certainly they are more similar with each other than, say, the MacOS alternatives and Kickoff, but that's a bit broad. In any case case, kickoff concepts were usability tested. There's always room for improvement, however.
The sliding menus thing is indeed one of those areas I'm not happy with; the rest is a marked improvement. It seems you agree. It also seems you agree with me that the old style menu sucks even more. ;) An approach I've started on to improve the menu navigation is to provide a breadcrumb control to the top of the menus. Hopefully I'll have it completed for 4.1, but I think it will largely take care of the issues you note about quick subnavigation.
But let's get really serious here: trolling through their installed apps randomly is hardly something most people do on a regular basis. If they are, we should ask ourselves "why?" because it certainly isn't what most people are wanting to do. Therefore it isn't what one should be optimizing for; indeed we should be offering better ways of getting at those things. Integrated search, favourites, and krunner's flexible searching (and not just by name, either) are all parts of the answer here.
Moreover, plasma provides the flexibility for alternatives to appear rather easily. We already have two menus in kdebase, which is one more than in kde3, with Lancelot in extragear and other experiments underway elsewhere.
"Remove the mini-icons": Ah, the infamous "call for removal". This has got to be one of my personal pet peeves. The answer to "could be better" is not "get rid of it"; well, unless one is completely happy with never improving or innovating. Since we're in the hi-tech industry, which has been all about radically changing the world for the last 50 odd years, the answer to that should be pretty obvious. So rather than "toss it", let's look at your issues and see what might be done about things.
"these mini-icons are not supported equally by all icon themes in every distro": Yep, many icon themes suck. Improve the themes. It's absolutely daft to suggest that even though we have working solutions (e.g. Oxygen, to name but one) that we should therefore tiptoe about and ensure our software sucks in other ways. The whole "must work in every possible contrived scenario" thinking is just not something that jives with the real world; with Free software there are too many scenarios, particularly contrived ones, and I'm not satisfied with being held back by the failings of others (e.g. incomplete or outmoded icon themes). This is one reason companies like Apple continue to shine in areas we don't: they control everything so can create optimal scenarios; we need to find the happy medium between "control everything" (uck!) and "let the mediocrity that comes with 'allow everything' set the height of the bar". No, set a bar and let others rise to it. That's a recipe for improvement.
"they can be hard to pinpoint with a mouse-click" That I agree with. We're actually going to be looking at how to re-work the applet handles this week at Tokamak, the first international Plasma developer sprint being held in Milan. I'll keep you posted. ;)
"add an appearance of complexity that may intimidate new users": If one makes usability statements, it's best to match them with testing (which isn't surveying, btw) or research others have done in relevant areas. The "may do $BAD_THING" is just so impossible to discuss because of the "may" and lack of any supporting data. I will note that it's one aspect that we haven't had any negative feedback on during user testing or in our issue tracker. Neat.
"redundant when each icon already has a right-click menu with the same choices.": So tell me which finger is right click on a touch screen? ;) Context menus are also "hidden" functionality: people learn to try and right click on things to see if it brings up anything useful. This is daft. Context menus should be there to house less used or more difficult options; hover interfaces make things obvious and discoverable. They also work with out a multi-button input device. Such as a stylus.
"They serve no useful purpose, and wouldn't be missed if eliminated." You may not think so, but others would differ. I'd also humbly suggest that clicking on and manipulating a resize button is more intuitive and "feels better" than "right click, select resize, move the mouse about, $DO_SOMETHING (click?) when done".
Let's move on ...
"A preview for images in the file manager": There's a Preview button in the toolbar, apparently ou missed it or it was missing for some odd reason in the build you installed. But it's there, and in 4.1 it's even nicer with cute little frames around them.
"Improved accessibility": I'm really, really disappointed in this section. Why? Because an insane amount of effort went into making sure that Qt4 works with with AT/SPI. Trolltech invested in a stack of tools to make working with D-Bus painless (and then some!) and then used those tools to create a backend for QAccessible on X11. You can read about it here on Trolltech's docs website. This was not a small amount of work and it was done because we believe in accessibility (a11y) so much.
KDE and Qt have both been very actively involved in a11y efforts for a number of years now. We hosted an a11y summit at Akademy in Ludwigsberg, Germany some 4 years ago, we've worked closely with the FSG a11y group, attended conferences around the world, adopted specs such as the X11 a11y key controls and wrote UIs for them, included numerous tools in KDE to work with these things and also taken the position that rather than duplicate every tool just because it isn't written in Qt to try and add new tools that are missing so the entire count of Free software tools by genre increases. Top this off with the work to bring a11y support on X11 up to par with what we've had on Windows and Mac in Qt for years ... it's significant.
So given both our long term interest and long term efforts that have impressive real world results .. I'm not sure a lecture on the importance of a11y, or misleading the public who reads your column to think KDE doesn't do much in the area of a11y, was warranted.
"What it lacks is an extensive screen reader like GNOME's Orca": Do you really think our time is best spent spending time reimplementing Orca just so we have something in Qt? Maybe someday someone will, but right now we have better things to do. This kind of mentality of "my toolkit or DIE!" is a disease. It makes us waste more effort and time when it isn't specifically needed. In this case, just use Orca with KDE4 apps. That's why there is AT-SPI: the bridge these gaps between Gtk+, Java, OO.o, Qt, KDE, etc...
"Drag and drop between menus, the desktop, and the panel": This is already done in svn, and not just limited to files. Rejoice! =)
That's a significant point as well, because the whole "desktop is a place to shove icons representing files" is limiting and largely redundant. What if I want to show more than one directory on my desktop? What if I want that directory to change depending on what I'm doing? Icons are demoted in Plasma to being just like any other widget, and in 4.1 we're about to replace the "desktop icons" with a simple yet much more common (and flexible) folder view.
"A broader selection of widgets": I'm not sure what you were trying to say here, other than to point out that a widget system that is only a few months old has fewer add-ons that one that is years old. I should hope so, otherwise the years old one is a complete and utter disaster. I also don't see the point of the comparison to tomboy which is rather out of scope.
That said, I currently count nearly 60 useful widget (so not counting test widgets or Hello World style widgets) in my Plasma install, and I don't have all of them. Then there is SuperKaramba which has dozens and dozens of its own. In 4.1 there are also the MacOS Dashboard widgets. So this really starts to look a bit silly =)
I'd also suggest comparing what does exist, such as the Twitter Plasma widget versus what's available elsewhere. Even though just released a couple months ago it's already nicer than what I've seen elsewhere. In fact, I know one person who switched to KDE4 from another system specifically because of that.
"KDE 4's one innovation is to permit larger version of widgets that fit on to panels on the desktop." I think that sells the rest of KDE4 short. I mean, I look at what I see in Phonon or Marble or Dolphin's nepomuk integration or ... Perhaps you are confusing "KDE 4" with "the desktop shell". Even then, I hadn't seen the desktop grid effect anywhere (to name one) not even in Compiz before KWin4.
That said, if we do want to focus just on Plasma, let's look at the pervasive scripting, the division between data provision and visualization, the inclusion of a plugin based "UI command line" with the default desktop command dialog, Containments, the use of SVG for the desktop, a properly composite aware free software shell, the ability to easily slide the same interfaces between devices of radically different scale ... I won't even mention things we don't have more fully realized such as zooming and activity-centric layouts, though that brings me to:
"why clutter your desktop with minor applications that you only occasionally want?" Well, Bruce, the answer is you don't have to. You can have nothing on your desktop whatsoever. For those who would like to build sets of tools that aid in the task they are currently working on (remember you can pull then forward by pressing Ctrl-F12 as well), it means the world. As more task oriented widgets becomes available for things like IM and presence integration, the folder listing I mentioned earlier, sharable (i.e. zeroconf aware) regions, more online data agregators ... This becomes more and more compelling.
Or we could talk about the "media center" concept. I hear it's getting pretty popular. ;) Plasma provides a way to have a widget assembly that can come and go and provide access to exactly that set of features and functionality. Yes, you may only occasionally want to skip through your film and video collection, but having the ability to call up that interface with a couple clicks is exactly what most people want to be able to do these days.
So I think you not only got the conclusion wrong, but your whole premise ("clutter your desktop ... minor applications") is askew.
"Better organized configuration tools": I'm not sure how you installed KDE 4.0, but your description of the layout of things is not what I have here. Odd. As for palm pilot and mobile phones being applications rather than control panels, that's always been the case; those are interactive tasks rather than simple configuration issues. For syncing, I'd like to see a Grand Unified panel one day, and I do agree that there is room for improvement in the ordering of things in System Settings yet. I just don't find what I'm looking at here, as a from-source install of KDE4, matching up with what you're describing.
"One of the advantages that KDE Classic had over GNOME was an initial wizard that allowed you to choose in a matter of seconds how much eye candy you wanted to run.": Interestingly, the majority of the user data we culled, including from "commercial" sources such as distributions, implied that this wizard was rather hated. It had other technical issues inherent to it, but really the first thing someone wants to do when they log in is perhaps set up their email/IM and get some work done; it's generally the tweakers (and reviewers tend to fall into tweaker mode, btw, even if they aren't tweakers in real life) who fall into the "let me tweak configuration values first!"
"font anti-aliasing, is not nearly optimal," Fonts are a difficult point right now. If you wish to wag fingers over fonts, go talk to the Free OS vendors who can't seem to get a consistent set of fonts between them, or a consistent set of font management capabilities for that matter. We are still at the mercy of the final system integrator when delivered as binaries for a given OS while we deal with a system of multiple moving targets on the source code front. It's not pretty, and I don't think the gains are to be made at the application level but in the infrastructure and OS vendor levels.
"Improved interface word choices" Here we agree; there's lots of room for improvement here, though things are already pretty decent. However, I think your examples were really poor.
You mention "sub-pixel rendering" as if that was out in the open somewhere. Instead, you can only find it once you go into the Fonts control panel (the integrated search there is nice, isn't it?), select "Enabled" instead of the default setting of "System defaults" (meaning "Let the people who knew what they were doing define what it should look like") and then click on the Configure button that becomes active next to it. Trotting that out as an example is a little inane, don't you think? I'd also ask you what you think a better term for that feature would be.
The "Setup Samba relisa and the ioslaves" is a good one, though I had to search for it a bit. It's a heading in the Sharing control panel in "Network & Connectivity" where the main tab says "Windows shares". I doubt that phrase therefore actually stumped anyone, but it's certainly odd and out of place. Thanks for pointing that one out, I'll commit a fix for that as soon as I'm done with the blog entry. (See, who need a bugzilla? These days we have the power of blogs ;-p )
Then you say: "the new KDE insists on calling its new applets "widget" -- a term that will sound vague to lay users, and inaccurate to developers for whom a widget is part of a graphical interface." Let me point you to "Apple Dashboard Widgets" or "Yahoo Widgets" or "Vista Widgets" or "Opera Widgets" ... I could go on, or diversify with entries like or "Google Gadgets", but you get the point. Widget has become a term that refers to exactly what we're doing. "Applet" may be known terminology to Java developers and KDE/GNOME users from years past, but Wiget has far more broad traction especially for this class of items.
As for "inaccurate to developers" perhaps you can find the developers who got confused or even care about it. Maybe Apple, Yahoo, Opera and Microsoft would like to know about those people too.
Moving on:
"KDE's habit of referring to both an application and its function in the menu": .. which is why we separated them very clearly in kickoff.
But all quibbles aside, you close with:
"All the same, mentioning what needs to be improved remains worthwhile. Improvements are more likely to be made if people are urging them ..."
I agree. Let's just not fall into the "therefore I need to be overtly negative at every turn, and screw the whole factual accuracy thing" trap in the process. I also hope you don't mind, Bruce, having your list of possible improvements dissected and reviewed in turn with equal voracity
I do also agree when you say:
"the question should not be why it needs so many improvements so much as how developers managed to make so many changes all at once"
It constantly amazes me as well. My answer to the question would be: a bit of daring, a measure of guts, an awesome community and a whole lot of freedom. =)
Finally, you say:
"Still, until KDE 4 settles down, potential users should be aware that it continues to be a work in progress, with a large share of unfinished features."
This is well in line with our guidance for 4.0 and somethine we've tried to make clear, so thanks for getting the word out. Until 4.1 (or 4.2 for certain use cases) arrives, there's always KDE3 which is still alive, kicking and a great work horse. For those who are early tech adopters or software developers, 4.0 is a great entry point, but it's certainly not for everyone at this point.
Again, thanks for taking the time to share your thoughts on things, and hopefully those reading this will now have a bit more of the whole story as well.
Cheers,
Aaron Seigo.
Thanks for trying KDE 4.0.x and then writing about it. It's always great when people try something for a while and then give their honest opinion on things. I'd like to address some of the issues you raise, so let's start where you started:
"A more customizable panel": the issues you note, from resizing and moving to not covering the toolbox, are already addressed in svn with the exception of autohiding which is currently partially working in a WIP patch. So this set of issues is more past tense than anything at this point. There remain some burrs to work out, such as not all widgets accommodating really small panels very well still or easy moving of applets.
"A better menu": This one is less clear. You state that it seems to be based on the XP/Vista menus, yet other than having a header and a footer I really don't see many overt similarities. Vista introduced integrated search, but that's a no-brainer. Kickoff isn't a two-pane model, it has tabs .. I could go on. Certainly they are more similar with each other than, say, the MacOS alternatives and Kickoff, but that's a bit broad. In any case case, kickoff concepts were usability tested. There's always room for improvement, however.
The sliding menus thing is indeed one of those areas I'm not happy with; the rest is a marked improvement. It seems you agree. It also seems you agree with me that the old style menu sucks even more. ;) An approach I've started on to improve the menu navigation is to provide a breadcrumb control to the top of the menus. Hopefully I'll have it completed for 4.1, but I think it will largely take care of the issues you note about quick subnavigation.
But let's get really serious here: trolling through their installed apps randomly is hardly something most people do on a regular basis. If they are, we should ask ourselves "why?" because it certainly isn't what most people are wanting to do. Therefore it isn't what one should be optimizing for; indeed we should be offering better ways of getting at those things. Integrated search, favourites, and krunner's flexible searching (and not just by name, either) are all parts of the answer here.
Moreover, plasma provides the flexibility for alternatives to appear rather easily. We already have two menus in kdebase, which is one more than in kde3, with Lancelot in extragear and other experiments underway elsewhere.
"Remove the mini-icons": Ah, the infamous "call for removal". This has got to be one of my personal pet peeves. The answer to "could be better" is not "get rid of it"; well, unless one is completely happy with never improving or innovating. Since we're in the hi-tech industry, which has been all about radically changing the world for the last 50 odd years, the answer to that should be pretty obvious. So rather than "toss it", let's look at your issues and see what might be done about things.
"these mini-icons are not supported equally by all icon themes in every distro": Yep, many icon themes suck. Improve the themes. It's absolutely daft to suggest that even though we have working solutions (e.g. Oxygen, to name but one) that we should therefore tiptoe about and ensure our software sucks in other ways. The whole "must work in every possible contrived scenario" thinking is just not something that jives with the real world; with Free software there are too many scenarios, particularly contrived ones, and I'm not satisfied with being held back by the failings of others (e.g. incomplete or outmoded icon themes). This is one reason companies like Apple continue to shine in areas we don't: they control everything so can create optimal scenarios; we need to find the happy medium between "control everything" (uck!) and "let the mediocrity that comes with 'allow everything' set the height of the bar". No, set a bar and let others rise to it. That's a recipe for improvement.
"they can be hard to pinpoint with a mouse-click" That I agree with. We're actually going to be looking at how to re-work the applet handles this week at Tokamak, the first international Plasma developer sprint being held in Milan. I'll keep you posted. ;)
"add an appearance of complexity that may intimidate new users": If one makes usability statements, it's best to match them with testing (which isn't surveying, btw) or research others have done in relevant areas. The "may do $BAD_THING" is just so impossible to discuss because of the "may" and lack of any supporting data. I will note that it's one aspect that we haven't had any negative feedback on during user testing or in our issue tracker. Neat.
"redundant when each icon already has a right-click menu with the same choices.": So tell me which finger is right click on a touch screen? ;) Context menus are also "hidden" functionality: people learn to try and right click on things to see if it brings up anything useful. This is daft. Context menus should be there to house less used or more difficult options; hover interfaces make things obvious and discoverable. They also work with out a multi-button input device. Such as a stylus.
"They serve no useful purpose, and wouldn't be missed if eliminated." You may not think so, but others would differ. I'd also humbly suggest that clicking on and manipulating a resize button is more intuitive and "feels better" than "right click, select resize, move the mouse about, $DO_SOMETHING (click?) when done".
Let's move on ...
"A preview for images in the file manager": There's a Preview button in the toolbar, apparently ou missed it or it was missing for some odd reason in the build you installed. But it's there, and in 4.1 it's even nicer with cute little frames around them.
"Improved accessibility": I'm really, really disappointed in this section. Why? Because an insane amount of effort went into making sure that Qt4 works with with AT/SPI. Trolltech invested in a stack of tools to make working with D-Bus painless (and then some!) and then used those tools to create a backend for QAccessible on X11. You can read about it here on Trolltech's docs website. This was not a small amount of work and it was done because we believe in accessibility (a11y) so much.
KDE and Qt have both been very actively involved in a11y efforts for a number of years now. We hosted an a11y summit at Akademy in Ludwigsberg, Germany some 4 years ago, we've worked closely with the FSG a11y group, attended conferences around the world, adopted specs such as the X11 a11y key controls and wrote UIs for them, included numerous tools in KDE to work with these things and also taken the position that rather than duplicate every tool just because it isn't written in Qt to try and add new tools that are missing so the entire count of Free software tools by genre increases. Top this off with the work to bring a11y support on X11 up to par with what we've had on Windows and Mac in Qt for years ... it's significant.
So given both our long term interest and long term efforts that have impressive real world results .. I'm not sure a lecture on the importance of a11y, or misleading the public who reads your column to think KDE doesn't do much in the area of a11y, was warranted.
"What it lacks is an extensive screen reader like GNOME's Orca": Do you really think our time is best spent spending time reimplementing Orca just so we have something in Qt? Maybe someday someone will, but right now we have better things to do. This kind of mentality of "my toolkit or DIE!" is a disease. It makes us waste more effort and time when it isn't specifically needed. In this case, just use Orca with KDE4 apps. That's why there is AT-SPI: the bridge these gaps between Gtk+, Java, OO.o, Qt, KDE, etc...
"Drag and drop between menus, the desktop, and the panel": This is already done in svn, and not just limited to files. Rejoice! =)
That's a significant point as well, because the whole "desktop is a place to shove icons representing files" is limiting and largely redundant. What if I want to show more than one directory on my desktop? What if I want that directory to change depending on what I'm doing? Icons are demoted in Plasma to being just like any other widget, and in 4.1 we're about to replace the "desktop icons" with a simple yet much more common (and flexible) folder view.
"A broader selection of widgets": I'm not sure what you were trying to say here, other than to point out that a widget system that is only a few months old has fewer add-ons that one that is years old. I should hope so, otherwise the years old one is a complete and utter disaster. I also don't see the point of the comparison to tomboy which is rather out of scope.
That said, I currently count nearly 60 useful widget (so not counting test widgets or Hello World style widgets) in my Plasma install, and I don't have all of them. Then there is SuperKaramba which has dozens and dozens of its own. In 4.1 there are also the MacOS Dashboard widgets. So this really starts to look a bit silly =)
I'd also suggest comparing what does exist, such as the Twitter Plasma widget versus what's available elsewhere. Even though just released a couple months ago it's already nicer than what I've seen elsewhere. In fact, I know one person who switched to KDE4 from another system specifically because of that.
"KDE 4's one innovation is to permit larger version of widgets that fit on to panels on the desktop." I think that sells the rest of KDE4 short. I mean, I look at what I see in Phonon or Marble or Dolphin's nepomuk integration or ... Perhaps you are confusing "KDE 4" with "the desktop shell". Even then, I hadn't seen the desktop grid effect anywhere (to name one) not even in Compiz before KWin4.
That said, if we do want to focus just on Plasma, let's look at the pervasive scripting, the division between data provision and visualization, the inclusion of a plugin based "UI command line" with the default desktop command dialog, Containments, the use of SVG for the desktop, a properly composite aware free software shell, the ability to easily slide the same interfaces between devices of radically different scale ... I won't even mention things we don't have more fully realized such as zooming and activity-centric layouts, though that brings me to:
"why clutter your desktop with minor applications that you only occasionally want?" Well, Bruce, the answer is you don't have to. You can have nothing on your desktop whatsoever. For those who would like to build sets of tools that aid in the task they are currently working on (remember you can pull then forward by pressing Ctrl-F12 as well), it means the world. As more task oriented widgets becomes available for things like IM and presence integration, the folder listing I mentioned earlier, sharable (i.e. zeroconf aware) regions, more online data agregators ... This becomes more and more compelling.
Or we could talk about the "media center" concept. I hear it's getting pretty popular. ;) Plasma provides a way to have a widget assembly that can come and go and provide access to exactly that set of features and functionality. Yes, you may only occasionally want to skip through your film and video collection, but having the ability to call up that interface with a couple clicks is exactly what most people want to be able to do these days.
So I think you not only got the conclusion wrong, but your whole premise ("clutter your desktop ... minor applications") is askew.
"Better organized configuration tools": I'm not sure how you installed KDE 4.0, but your description of the layout of things is not what I have here. Odd. As for palm pilot and mobile phones being applications rather than control panels, that's always been the case; those are interactive tasks rather than simple configuration issues. For syncing, I'd like to see a Grand Unified panel one day, and I do agree that there is room for improvement in the ordering of things in System Settings yet. I just don't find what I'm looking at here, as a from-source install of KDE4, matching up with what you're describing.
"One of the advantages that KDE Classic had over GNOME was an initial wizard that allowed you to choose in a matter of seconds how much eye candy you wanted to run.": Interestingly, the majority of the user data we culled, including from "commercial" sources such as distributions, implied that this wizard was rather hated. It had other technical issues inherent to it, but really the first thing someone wants to do when they log in is perhaps set up their email/IM and get some work done; it's generally the tweakers (and reviewers tend to fall into tweaker mode, btw, even if they aren't tweakers in real life) who fall into the "let me tweak configuration values first!"
"font anti-aliasing, is not nearly optimal," Fonts are a difficult point right now. If you wish to wag fingers over fonts, go talk to the Free OS vendors who can't seem to get a consistent set of fonts between them, or a consistent set of font management capabilities for that matter. We are still at the mercy of the final system integrator when delivered as binaries for a given OS while we deal with a system of multiple moving targets on the source code front. It's not pretty, and I don't think the gains are to be made at the application level but in the infrastructure and OS vendor levels.
"Improved interface word choices" Here we agree; there's lots of room for improvement here, though things are already pretty decent. However, I think your examples were really poor.
You mention "sub-pixel rendering" as if that was out in the open somewhere. Instead, you can only find it once you go into the Fonts control panel (the integrated search there is nice, isn't it?), select "Enabled" instead of the default setting of "System defaults" (meaning "Let the people who knew what they were doing define what it should look like") and then click on the Configure button that becomes active next to it. Trotting that out as an example is a little inane, don't you think? I'd also ask you what you think a better term for that feature would be.
The "Setup Samba relisa and the ioslaves" is a good one, though I had to search for it a bit. It's a heading in the Sharing control panel in "Network & Connectivity" where the main tab says "Windows shares". I doubt that phrase therefore actually stumped anyone, but it's certainly odd and out of place. Thanks for pointing that one out, I'll commit a fix for that as soon as I'm done with the blog entry. (See, who need a bugzilla? These days we have the power of blogs ;-p )
Then you say: "the new KDE insists on calling its new applets "widget" -- a term that will sound vague to lay users, and inaccurate to developers for whom a widget is part of a graphical interface." Let me point you to "Apple Dashboard Widgets" or "Yahoo Widgets" or "Vista Widgets" or "Opera Widgets" ... I could go on, or diversify with entries like or "Google Gadgets", but you get the point. Widget has become a term that refers to exactly what we're doing. "Applet" may be known terminology to Java developers and KDE/GNOME users from years past, but Wiget has far more broad traction especially for this class of items.
As for "inaccurate to developers" perhaps you can find the developers who got confused or even care about it. Maybe Apple, Yahoo, Opera and Microsoft would like to know about those people too.
Moving on:
"KDE's habit of referring to both an application and its function in the menu": .. which is why we separated them very clearly in kickoff.
But all quibbles aside, you close with:
"All the same, mentioning what needs to be improved remains worthwhile. Improvements are more likely to be made if people are urging them ..."
I agree. Let's just not fall into the "therefore I need to be overtly negative at every turn, and screw the whole factual accuracy thing" trap in the process. I also hope you don't mind, Bruce, having your list of possible improvements dissected and reviewed in turn with equal voracity
I do also agree when you say:
"the question should not be why it needs so many improvements so much as how developers managed to make so many changes all at once"
It constantly amazes me as well. My answer to the question would be: a bit of daring, a measure of guts, an awesome community and a whole lot of freedom. =)
Finally, you say:
"Still, until KDE 4 settles down, potential users should be aware that it continues to be a work in progress, with a large share of unfinished features."
This is well in line with our guidance for 4.0 and somethine we've tried to make clear, so thanks for getting the word out. Until 4.1 (or 4.2 for certain use cases) arrives, there's always KDE3 which is still alive, kicking and a great work horse. For those who are early tech adopters or software developers, 4.0 is a great entry point, but it's certainly not for everyone at this point.
Again, thanks for taking the time to share your thoughts on things, and hopefully those reading this will now have a bit more of the whole story as well.
Cheers,
Aaron Seigo.
Tuesday, April 08, 2008
Phonon with VLC and MPLayer
Fresh off the intarwebs: Tanguy Krotoff from the VLC project announced availability of working VLC and MPlayer backends for Phonon. The VLC backend uses libvlc from the latest dev version of VLC, 0.9. Sweet.
Monday, April 07, 2008
Qt Centre Programming Contest and Plasma!
The folks over at Qt Centre, a site devoted to the Qt programming community, have announced the start of the Second Annual Qt Programming Contest. What's really cool is that one of the categories is ... Plasmoid! Yes, they'll be naming a winner in the category of best Plasma add-on. Coool...
I'll be the guest judge for this category, so I'm looking forward to the submissions.
I suppose this means I really, really need to get those tutorials on techbase, huh? ;)
I'll be the guest judge for this category, so I'm looking forward to the submissions.
I suppose this means I really, really need to get those tutorials on techbase, huh? ;)
Sunday, April 06, 2008
in france
I'm in France right now. Toulouse, to be more precise. Kevin Ottens' (you may know him from Solid in KDE4) living room to be even more precise. It's 6:30 in the morning and Kevin and I are sitting here getting some work done early in the day so that we may go out a bit earlier in the afternoon to enjoy some of the city.
I've already taken an ungodly number of pictures in my first day here as I play with my new toy: a Cannon EOS 400. I've never actually owned an SLR before, and there's much to learn, but I'm having fun with it. It's been great so far traveling with P.: we was awesome on the flight and airports and has been just great as we travel about the city here. Kevin and his better half, Virginie, have been great hosts thus far. Part of the wonder of working using cooperative methods is that it sets the stage and mood for friendships to bloom and blossom.
In a few days we head to Milan for Tokamak: Plasma Developer Sprint Mark I, where we will get to meet several of the Plasma folk and move the project even further ahead. I have come armed with a bevy of use cases that extend beyond the traditional desktop as well as a laundry list of more down to earth, immediate and pressing challenges to be met. I'm excited.
Which is in part why I felt like blogging today: I'm in a good mood. The last few weeks have been rather more difficult. A friend killed himself two weekends ago, I had some relationship maintenance to do with an ex that wasn't pleasant but necessary for our continued friendship, I've been working through some very hard decisions about what I want to do in the next year (move to Vancouver, so P can be near his mom again? become entrepeneurial again or remain a free software hippy?) ... so a lot has been on my mind. For me, sharing my thoughts and otherwise interacting with people beyond my own little head is a slightly stressful event. I enjoy it, but it takes a lot of energy to do. It's easier to just remain quiet and kick back. I love human contact, though; I'm one of those people who goes to fairs just to walk, unknown and ignored, through the crowds.
During the quiet, however, I have been up to my usual devices: new stuff in plasma continues to roll, like the Plasma::WebContent widget, as well a bug fixes. Lots of patches have come through and been reviewed (I missed review board more and more, maybe we should set one up on a proper KDE server so we don't have to live without it, ever?).
I've also been thinking about things such as the external interpretation of my position within KDE. A recent article referred to me as the "project lead" which isn't really true; I'm the project lead within Plasma and I certainly try and help with organization, setting vision, helping defray issues that bubble up within the community, spend a lot of time talking to others both publicly and privately about KDE and Free software, etc .. but KDE doesn't have a "lead developer". However, I understand why someone from the outside, searching for a name for what it is I do would default back to "lead developer". It doesn't make me feel very comfortable, however. I feel much more like an ambassador for the project, a representative of this much bigger thing. So I'm going to try and see if I can't edge the conversation in that direction in the future: Aaron Seigo, KDE Ambassador. I'm also very happy to see more ambassadors rising as well: I'm seeing more of Wade Olsen, Will Stephenson, Sebastian Kugler as well as others appearing on the radar here and there. Ian Monroe will be doing the ambassador dance at the LinuxFoundation Collab Summit this week, while more people are giving really compelling talks at various events about KDE. A distributed approach is much more reflective of KDE and much more robust.
On a selfish note, it also takes some pressure off of my own shoulders and lets me enjoy doing it a bit more. ;) Playing with a good team is much more enjoyable.
Unfortunately, doing the ambassadorial stuff (both inside and outside the project) is a lot less fun for most people than making pieces of art (be it in code, words, pictures, sound..). It would be great if those who are stepping up and out get the full support of those in and around the project: they are rare birds to be cherished. =)
Anyways, enough about all that ... The progress with the bug triage days, wiki and mailing list have been great. A big thanks to George Goldberg for blogging about it and helping make it become a reality.
I've also been watching with glee (yes, glee! =) as KDE4 technologies continue to whizz together; it's no secret that the real impact of the Pillars of KDE4 will be realized only as they are tapped by various applications. So when Digikam (which worked out of the box with no configuration with my camera.. huzzah!) moves to using Marble for their geolocation interface everyone wins; as Akonadi and Nepomuk circle each other closer and closer, everyone wins; as Okular uses Phonon to play media embedded in documents, everyone wins ... well, you get the picture.
Speaking of everyone winning, Rafael has started the process of taking the job viewer d-bus interface he developed during the KDE4 cycle and working it into a proposal for adoption as a freedesktop.org specification. What does the "job viewer d-bus interface" do? It lets long-lasting desktop "jobs" that contain progress information (burning a CD, indexing files, receiving or deleting mail, downloading a torrent, copying a file, etc) to communicate with a visualization service. So if this makes it's way to "freedesktop.org spec" and then implemented broadly, applications will be able to show their job progress in the desktop "native" user interface (e.g. kuiserver in KDE or mathusalem in GNOME). Neat.
Along the same vein, we have a DataEngine and Applet in playground right now that mostly implements the galago notification spec. It's in the org.freedesktop namespace, though it's not on freedesktop.org which is rather... odd and has gone through rather little collaborative development (not for wont of trying) so it's also a bit rough in places, but I think having a common visualization interface for notifications would also be useful. So .. we're trying to build that bridge a bit. I've submitted a laundry list of desired changes to the galago spec. So far I've received no feedback on them though I know the galago people have to have read it because it was sent in reply to a galago developer's email; if that situation doesn't rectify itself within a reasonable time frame, I might end up just forking the spec entirely, cleaning it up and submitting it for proper freedesktop.org approval (aka not just throwing it in the org.freedesktop namespace and calling it a day). I hope we can work together on it, however.
As Lubos noted, however, the galago spec is really not suited for general notification systems. It is however, as I noted in return, just fine for popup visualization, much like the job viewer is for jobs. Hopefully we'll eventually get a notification system spec up somewhere (knotify would be a great starting point: it's extremely robust, powerful and very well proven) as a compliment to the popup visualization spec. I don't expect that to happen soon (we're all very busy already with other things), but it is on the horizon.
Finally: I've discovered that honey withfeta goat cheese (e.g. on a pizza) is insanely great. OMG! The ballance of the subtle yet salty cheese against the sweet, rich flavour of the honey is wonderful. Viva Vive la France!
(Noting how long this entry is .. I'll try and blog more regularly to keep the size of the postings to a more sensible size ;)
I've already taken an ungodly number of pictures in my first day here as I play with my new toy: a Cannon EOS 400. I've never actually owned an SLR before, and there's much to learn, but I'm having fun with it. It's been great so far traveling with P.: we was awesome on the flight and airports and has been just great as we travel about the city here. Kevin and his better half, Virginie, have been great hosts thus far. Part of the wonder of working using cooperative methods is that it sets the stage and mood for friendships to bloom and blossom.
In a few days we head to Milan for Tokamak: Plasma Developer Sprint Mark I, where we will get to meet several of the Plasma folk and move the project even further ahead. I have come armed with a bevy of use cases that extend beyond the traditional desktop as well as a laundry list of more down to earth, immediate and pressing challenges to be met. I'm excited.
Which is in part why I felt like blogging today: I'm in a good mood. The last few weeks have been rather more difficult. A friend killed himself two weekends ago, I had some relationship maintenance to do with an ex that wasn't pleasant but necessary for our continued friendship, I've been working through some very hard decisions about what I want to do in the next year (move to Vancouver, so P can be near his mom again? become entrepeneurial again or remain a free software hippy?) ... so a lot has been on my mind. For me, sharing my thoughts and otherwise interacting with people beyond my own little head is a slightly stressful event. I enjoy it, but it takes a lot of energy to do. It's easier to just remain quiet and kick back. I love human contact, though; I'm one of those people who goes to fairs just to walk, unknown and ignored, through the crowds.
During the quiet, however, I have been up to my usual devices: new stuff in plasma continues to roll, like the Plasma::WebContent widget, as well a bug fixes. Lots of patches have come through and been reviewed (I missed review board more and more, maybe we should set one up on a proper KDE server so we don't have to live without it, ever?).
I've also been thinking about things such as the external interpretation of my position within KDE. A recent article referred to me as the "project lead" which isn't really true; I'm the project lead within Plasma and I certainly try and help with organization, setting vision, helping defray issues that bubble up within the community, spend a lot of time talking to others both publicly and privately about KDE and Free software, etc .. but KDE doesn't have a "lead developer". However, I understand why someone from the outside, searching for a name for what it is I do would default back to "lead developer". It doesn't make me feel very comfortable, however. I feel much more like an ambassador for the project, a representative of this much bigger thing. So I'm going to try and see if I can't edge the conversation in that direction in the future: Aaron Seigo, KDE Ambassador. I'm also very happy to see more ambassadors rising as well: I'm seeing more of Wade Olsen, Will Stephenson, Sebastian Kugler as well as others appearing on the radar here and there. Ian Monroe will be doing the ambassador dance at the LinuxFoundation Collab Summit this week, while more people are giving really compelling talks at various events about KDE. A distributed approach is much more reflective of KDE and much more robust.
On a selfish note, it also takes some pressure off of my own shoulders and lets me enjoy doing it a bit more. ;) Playing with a good team is much more enjoyable.
Unfortunately, doing the ambassadorial stuff (both inside and outside the project) is a lot less fun for most people than making pieces of art (be it in code, words, pictures, sound..). It would be great if those who are stepping up and out get the full support of those in and around the project: they are rare birds to be cherished. =)
Anyways, enough about all that ... The progress with the bug triage days, wiki and mailing list have been great. A big thanks to George Goldberg for blogging about it and helping make it become a reality.
I've also been watching with glee (yes, glee! =) as KDE4 technologies continue to whizz together; it's no secret that the real impact of the Pillars of KDE4 will be realized only as they are tapped by various applications. So when Digikam (which worked out of the box with no configuration with my camera.. huzzah!) moves to using Marble for their geolocation interface everyone wins; as Akonadi and Nepomuk circle each other closer and closer, everyone wins; as Okular uses Phonon to play media embedded in documents, everyone wins ... well, you get the picture.
Speaking of everyone winning, Rafael has started the process of taking the job viewer d-bus interface he developed during the KDE4 cycle and working it into a proposal for adoption as a freedesktop.org specification. What does the "job viewer d-bus interface" do? It lets long-lasting desktop "jobs" that contain progress information (burning a CD, indexing files, receiving or deleting mail, downloading a torrent, copying a file, etc) to communicate with a visualization service. So if this makes it's way to "freedesktop.org spec" and then implemented broadly, applications will be able to show their job progress in the desktop "native" user interface (e.g. kuiserver in KDE or mathusalem in GNOME). Neat.
Along the same vein, we have a DataEngine and Applet in playground right now that mostly implements the galago notification spec. It's in the org.freedesktop namespace, though it's not on freedesktop.org which is rather... odd and has gone through rather little collaborative development (not for wont of trying) so it's also a bit rough in places, but I think having a common visualization interface for notifications would also be useful. So .. we're trying to build that bridge a bit. I've submitted a laundry list of desired changes to the galago spec. So far I've received no feedback on them though I know the galago people have to have read it because it was sent in reply to a galago developer's email; if that situation doesn't rectify itself within a reasonable time frame, I might end up just forking the spec entirely, cleaning it up and submitting it for proper freedesktop.org approval (aka not just throwing it in the org.freedesktop namespace and calling it a day). I hope we can work together on it, however.
As Lubos noted, however, the galago spec is really not suited for general notification systems. It is however, as I noted in return, just fine for popup visualization, much like the job viewer is for jobs. Hopefully we'll eventually get a notification system spec up somewhere (knotify would be a great starting point: it's extremely robust, powerful and very well proven) as a compliment to the popup visualization spec. I don't expect that to happen soon (we're all very busy already with other things), but it is on the horizon.
Finally: I've discovered that honey with
(Noting how long this entry is .. I'll try and blog more regularly to keep the size of the postings to a more sensible size ;)
