I've been pondering the question of "when should we backport features?" It's fashionable right now to backport features in Plasma (and, I imagine, other applications) from the development track to stable releases and then include those stable releases plus the backported code from unstable branches to the general user base.
It has been shown that this leads to bugs since the features backported are not always completed or been properly QA'd (that's the meaning of a "development branch"). It also diminishes the goals of the upstream development team by changing the timing and combination of features provided (which can have morale diminishing effects of "stealing their thunder"). It also exposes users to unnecessary risk: what happens if we change how the configuration is stored and retrieved for any given feature? What happens if we change how the feature works, or even withdraw the feature from a release due to scheduling?
There is a reason we have release cycles, and backporting here and there circumvents all of those reasons. It's a bit ironic that some doing the backporting are also involved in planning releases and understand those reasons, implying that it's good enough for upstream but not downstream.
Of course Free software is great because it lets you do whatever you want (within the bounds of that license). Some KDE distributors see good reasons in doing these backports: they want to support KDE 4.1 for a longer period of time and their user base demands a certain feature that is only available in the next release after 4.1. Or they don't have flexible release schedules and so can't wait for 4.2 or they have a policy of not offering upgrades such as 4.2 for a release based on 4.1 (a form of self-imposed inflexibility). Or they simply want to show off as being "better than the other KDE teams" while others then prove they can "keep up". There are numerous reasons for backporting, some better than others.
It remains a judgment call in all cases, however. I urge those doing the backporting to use their judgment wisely and consider both their users and upstream developers in the process.
One unfortunate result of this backporting fad is that every time we do anything interesting in Plasma these days we get requests from someone to backport it, as if that was always easy and came with no downside. It's getting a bit ridiculous and completely runs counter to the idea of release and testing processes, and puts us in the Plasma team in an uncomfortable position of saying "No" to questions (and people) we should never have to be confronted with.
There is a middle ground, a balance point to be found. Right now I don't think we're there, though with a bit of thought and care we can reach it.
What do you think is a good reason or motivation to backport features that are in a development branch back to a stable branch?
Tuesday, October 28, 2008
thin layers
Ade blogged recently that some of the people sharing beers around a table one evening were ponder the question "Why isn't Phonon just a thin wrapper around GStreamer?" and couldn't come up with a good answer.
The answer is pretty simple, however: Phonon is a thin layer over GStreamer when it is used with the GStreamer back-end.
What it isn't is a thin layer for only GStreamer, and the reason for that is similarly straightforward: our target platforms are your computers, where "your" is defined as "people of the world". Reality is that not all of your computers use GStreamer, and it isn't KDE's role to try and ignore that reality.
In that sense it's just like how KDE runs also on BSD or OpenSolaris: it isn't our job to make people running those OSes to switch to Linux.
In that sense it's just like how Qt is a "thin layer" over X11, but not exclusively as it supports at least four other windowing systems and a multitude of operating systems.
We wrote the GStreamer backend, bringing thousands of applications to GStreamer (which begs one to ask why people are looking gift horses in the mouth), because we believe in GStreamer as a solution. If in five year's time GStreamer has taken over the world (as defined by "our users") then everyone wins and nobody loses; if that doesn't happen KDE still doesn't lose.
So why is Phonon not a thin layer over only GStreamer? Because we cater to the whole world, today and tomorrow, even as we take care of our preferred choices and platforms through our efforts.
The answer is pretty simple, however: Phonon is a thin layer over GStreamer when it is used with the GStreamer back-end.
What it isn't is a thin layer for only GStreamer, and the reason for that is similarly straightforward: our target platforms are your computers, where "your" is defined as "people of the world". Reality is that not all of your computers use GStreamer, and it isn't KDE's role to try and ignore that reality.
In that sense it's just like how KDE runs also on BSD or OpenSolaris: it isn't our job to make people running those OSes to switch to Linux.
In that sense it's just like how Qt is a "thin layer" over X11, but not exclusively as it supports at least four other windowing systems and a multitude of operating systems.
We wrote the GStreamer backend, bringing thousands of applications to GStreamer (which begs one to ask why people are looking gift horses in the mouth), because we believe in GStreamer as a solution. If in five year's time GStreamer has taken over the world (as defined by "our users") then everyone wins and nobody loses; if that doesn't happen KDE still doesn't lose.
So why is Phonon not a thin layer over only GStreamer? Because we cater to the whole world, today and tomorrow, even as we take care of our preferred choices and platforms through our efforts.
Friday, October 24, 2008
e.V. update
I've been meaning to post a quick update with my KDE e.V. hat on for a couple weeks now. I'm in between conference calls, so I figure this is my chance. ;)
Since Akadamy '08, we've had 11 people join KDE e.V. as members. They were all just announced formally on the mailing list, and it's terrific to see the e.V. continue to grow and see the flow of new developers mature into a known contributors who decide to take a step into the foundation that supports so much of KDE. This is how the e.V. stays relevant to the project as it provides a bond of trust that the directions the e.V. takes will reflect the current needs of the project.
KDE e.V. has been ticking out the progress points since Akademy in other ways as well. While Akademy is our Big Event each year, we do a lot more than that. We of course help coordinate (e.g. via our mammoth booth box) and fund (travel and lodging mostly) attendance at events around the world (though primarily Europe still, as that's where most of the "heat" is still), we also have our developer sprints. You'll be seeing news of these upcoming events unfold in the last quarter of this year as topics ranging from IDEs to imaging get addressed in these highly focused and well orchestrated developer sprints.
We also are providing support for the KDE Americas event this year, being held in Jamaica. It's actually the second annual event, with the first one having been the 4.0 launch event in January in California. I expect the location of the event to move around and about the Americas just as Akademy does in Europe. It's likely to keep focus on places with friendly climates in January/February and ease of travel for those in the Americas. That's the long winded way of saying "it's like to be held mostly in the lower USA, Central America, etc".
We're also gearing up to complete some office adjustment in Frankfurt. Based on our our experience this last year with the office, we will be moderately expanding/improving our processes there. Our first year "experiment" has exceeded our goals in terms of benefits and we feel there is yet more room for benefit, so it makes sense to strengthen this area. Our plans remain within reason and our budget while allowing us to continue to fund that effort to grow KDE e.V. in terms of both scope and effectivity. As the plans for the office solidify, we will post updates and be taking input on matters from the membership.
One area that the e.V. staff is really helping us out with is the coming Akademy + GUADEC combined event. Stormy from the GNOME Foundation and Claudia from the e.V. office are working together and providing critical support for the process. I'm increasingly optimistic about the success of next year's event as we lay more and more of the pieces in place. Doing a combined event was never going to be easy as it meant bringing more people to the table, in this case two foundation boards (KDE e.V. and the GNOME Foundation) which means an inevitable increase in communications and coordination (C2) overhead. Fortunately the command part of the equation (C3) is managed by the on-the-ground team in the Canaries, so that remains effective.
Where do we go from here? Onwards, upwards .. but with direction. We are still sorting out many details that have sprung up due to the Nokia purchase of Trolltech (now Qt Software). This has meant things such as working through the relevant details of the FreeQt Foundation agreements. We should see both news and closure on various aspects of the Nokia-buys-Trolltech how-does-that-affect-us chapter in the final quarter of this year.
We are also looking at new opportunities for the e.V. as they arise while ensuring we keep our focus, laserlike, on our most important current targets.
Other than that, one topic that begins to rattle about in my own skull is that of succession. With some of us having been on the board for a few years, it's time we started thinking about who might make good members of a future board. The current board won't be around forever, after all, and I'd like to be prepared for a smooth hand off to new bodies when the time comes. That means laying plans and goals out in the near term so that we don't end up with uncertainty when the inevitable board turnover occurs sometime in the future.
Ok, my e.V. hat is off now ... back to coding. Well, I lie: back to a phone call first, but then back to coding. ;)
Since Akadamy '08, we've had 11 people join KDE e.V. as members. They were all just announced formally on the mailing list, and it's terrific to see the e.V. continue to grow and see the flow of new developers mature into a known contributors who decide to take a step into the foundation that supports so much of KDE. This is how the e.V. stays relevant to the project as it provides a bond of trust that the directions the e.V. takes will reflect the current needs of the project.
KDE e.V. has been ticking out the progress points since Akademy in other ways as well. While Akademy is our Big Event each year, we do a lot more than that. We of course help coordinate (e.g. via our mammoth booth box) and fund (travel and lodging mostly) attendance at events around the world (though primarily Europe still, as that's where most of the "heat" is still), we also have our developer sprints. You'll be seeing news of these upcoming events unfold in the last quarter of this year as topics ranging from IDEs to imaging get addressed in these highly focused and well orchestrated developer sprints.
We also are providing support for the KDE Americas event this year, being held in Jamaica. It's actually the second annual event, with the first one having been the 4.0 launch event in January in California. I expect the location of the event to move around and about the Americas just as Akademy does in Europe. It's likely to keep focus on places with friendly climates in January/February and ease of travel for those in the Americas. That's the long winded way of saying "it's like to be held mostly in the lower USA, Central America, etc".
We're also gearing up to complete some office adjustment in Frankfurt. Based on our our experience this last year with the office, we will be moderately expanding/improving our processes there. Our first year "experiment" has exceeded our goals in terms of benefits and we feel there is yet more room for benefit, so it makes sense to strengthen this area. Our plans remain within reason and our budget while allowing us to continue to fund that effort to grow KDE e.V. in terms of both scope and effectivity. As the plans for the office solidify, we will post updates and be taking input on matters from the membership.
One area that the e.V. staff is really helping us out with is the coming Akademy + GUADEC combined event. Stormy from the GNOME Foundation and Claudia from the e.V. office are working together and providing critical support for the process. I'm increasingly optimistic about the success of next year's event as we lay more and more of the pieces in place. Doing a combined event was never going to be easy as it meant bringing more people to the table, in this case two foundation boards (KDE e.V. and the GNOME Foundation) which means an inevitable increase in communications and coordination (C2) overhead. Fortunately the command part of the equation (C3) is managed by the on-the-ground team in the Canaries, so that remains effective.
Where do we go from here? Onwards, upwards .. but with direction. We are still sorting out many details that have sprung up due to the Nokia purchase of Trolltech (now Qt Software). This has meant things such as working through the relevant details of the FreeQt Foundation agreements. We should see both news and closure on various aspects of the Nokia-buys-Trolltech how-does-that-affect-us chapter in the final quarter of this year.
We are also looking at new opportunities for the e.V. as they arise while ensuring we keep our focus, laserlike, on our most important current targets.
Other than that, one topic that begins to rattle about in my own skull is that of succession. With some of us having been on the board for a few years, it's time we started thinking about who might make good members of a future board. The current board won't be around forever, after all, and I'd like to be prepared for a smooth hand off to new bodies when the time comes. That means laying plans and goals out in the near term so that we don't end up with uncertainty when the inevitable board turnover occurs sometime in the future.
Ok, my e.V. hat is off now ... back to coding. Well, I lie: back to a phone call first, but then back to coding. ;)
the next battle lines
Microsoft recently conceded the Vista struggle and is now refocusing it's market on the yet-to-materialize Windows 7. Sure, Vista is slow and piggish and has some rather cute ideas of what "bling" means. Sure, it found new ways to annoy users and drag usability down. But in past years, they could have pushed that down the throat of the market. We know they could have because they did: each version of Windows that came out required more hardware and had its own "fun" quirks. One might point to the increased stability of XP as a difference, but then Vista has its improvements in that area as well.
In past rev cycles, people would have just beefed up their computers and learned to deal with the new funk. If we look at all the consumer level computers out right now, they are currently capable of running Vista and the hardware companies love the idea of selling bigger systems and seeing hardware churn due to increasing software requirements. But right now that's pretty much all that is propping Vista up: pre-installs on those new beefier-than-2-years-ago machines.
This is not 1998 or 2001 anymore; this time Microsoft failed to push their product out against the desire of the market. What's changed? The market has choice, and it knows it.
People now see both Linux and Mac as viable options and no longer feel beholden to trudge along besides Microsoft and their pace. These platforms are now viable because of their improved user interfaces and friendliness, and even the Mac would not be where it is right now without Free software for them to build on (and occasionally mistreat in the process, unfortunately).
We should see the failure of Vista as a success for us that we helped create. Of course, KDE is not yet the dominant user platform so we shouldn't smile and be happy with it. Microsoft won't stop, Apple won't stop, neither should we.
I see three new battle lines for us over the next five years: making Windows 7 look as bad or worse than Vista does in comparison to our offerings (while continuing to land beachheads with our applications on that operating system); taking Windows Mobile off the table as a choice; besting the iP-devices (iPhone, iPod) on the consumer market. We have all the tools available to us, we just need to execute over the next 2-3 years.
I write this because I continue to see "why Vista sucks" articles being written and can't help but think that that battle is done, so we need to move our sights on to new fields. I write this because I see more and more Linux based mobile coming out, but most of it is really sub-par and that concerns me.
We know that our strengths are community and ubiquity. Those are awesome strengths because they play directly into the trends that are likely to play out over the next 10 years in the industry, namely increasing socialization of technology and the spread of these technologies to cover the desktop, the portable, the phone and the web with such vigor that we won't even recognize the landscape in 10 years time. Let's continue to underscore those strengths, make the world aware of them and continue to make the best damn software money can't buy. =)
In past rev cycles, people would have just beefed up their computers and learned to deal with the new funk. If we look at all the consumer level computers out right now, they are currently capable of running Vista and the hardware companies love the idea of selling bigger systems and seeing hardware churn due to increasing software requirements. But right now that's pretty much all that is propping Vista up: pre-installs on those new beefier-than-2-years-ago machines.
This is not 1998 or 2001 anymore; this time Microsoft failed to push their product out against the desire of the market. What's changed? The market has choice, and it knows it.
People now see both Linux and Mac as viable options and no longer feel beholden to trudge along besides Microsoft and their pace. These platforms are now viable because of their improved user interfaces and friendliness, and even the Mac would not be where it is right now without Free software for them to build on (and occasionally mistreat in the process, unfortunately).
We should see the failure of Vista as a success for us that we helped create. Of course, KDE is not yet the dominant user platform so we shouldn't smile and be happy with it. Microsoft won't stop, Apple won't stop, neither should we.
I see three new battle lines for us over the next five years: making Windows 7 look as bad or worse than Vista does in comparison to our offerings (while continuing to land beachheads with our applications on that operating system); taking Windows Mobile off the table as a choice; besting the iP-devices (iPhone, iPod) on the consumer market. We have all the tools available to us, we just need to execute over the next 2-3 years.
I write this because I continue to see "why Vista sucks" articles being written and can't help but think that that battle is done, so we need to move our sights on to new fields. I write this because I see more and more Linux based mobile coming out, but most of it is really sub-par and that concerns me.
We know that our strengths are community and ubiquity. Those are awesome strengths because they play directly into the trends that are likely to play out over the next 10 years in the industry, namely increasing socialization of technology and the spread of these technologies to cover the desktop, the portable, the phone and the web with such vigor that we won't even recognize the landscape in 10 years time. Let's continue to underscore those strengths, make the world aware of them and continue to make the best damn software money can't buy. =)
scheduling
The decision was made to file off some remaining sharp edges from libplasma and then move it into kdelibs on November 1. However, I was thrown a few curve balls this week in the form of some schedule changes due to things maturing quicker than I expected.
Instead of being around the house working on Plasma next week, I'm going to be in London on Monday for meetings and then off to Finland until the end of the work week. That means that the two weeks I thought I'd have to spend with the team finalizing the couple remaining bits of libplasma API is cut short. As of today I'm busy doing meeting agendas, presentations, organizing the house for my departure and what not.
We did manage to get ToolTipManager reviewed and polished, though, thanks in no small part to our resident API reviewer (aka "API slave driver" ;) Kevin Ottens and there's some final work being done with Corona with regards to screen geometry management (more on that and Kephal in a later blog report), but we still have Service and AbstractRunner to finish out. At this point, I'm not sure I'm going to get to these things before I fly out and the odds of having the concentration time needed to go through such things during the week I'm on the road are low.
So, depending on how things go over the next few days and what the rest of the Plasma team decides, we may end up pushing back the plans by a week. That would still put us well within the time frame of the feature part of the cycle, with hard freeze not up until mid November. Of course, the rest of the team may be able to pick up the slack in my absence, but everyone's pretty busy already so it would be quite understandable if they don't. Or I might end up with lots of hacking time at night in Finland, who knows. I'll let kde-core-devel know what's up before I fly out Sunday evening in any case.
This also leads me look at November 9th as the first Saturday that I could do a videocast. I'd like the first one to be at least somewhat decent (aka not me running around in airports or whatever) and be realistically able to follow it up with one the following week. So I've tentatively set the time for my first videocast for November 9th at 19:00 UTC. It'll be recorded and downloadable later, but that time was the "prime time" slot according to the web poll so many of you took the time to graciously fill out. It also works out nicely because the next two biggest days are Sunday and Monday, so the majority of people who want to should be able to check it out shortly after the broadcast.
Right now, though, I'm off to do some housework ... because that's the sort of crazy fun life I lead. Yee-haw, dishes! ;)
Instead of being around the house working on Plasma next week, I'm going to be in London on Monday for meetings and then off to Finland until the end of the work week. That means that the two weeks I thought I'd have to spend with the team finalizing the couple remaining bits of libplasma API is cut short. As of today I'm busy doing meeting agendas, presentations, organizing the house for my departure and what not.
We did manage to get ToolTipManager reviewed and polished, though, thanks in no small part to our resident API reviewer (aka "API slave driver" ;) Kevin Ottens and there's some final work being done with Corona with regards to screen geometry management (more on that and Kephal in a later blog report), but we still have Service and AbstractRunner to finish out. At this point, I'm not sure I'm going to get to these things before I fly out and the odds of having the concentration time needed to go through such things during the week I'm on the road are low.
So, depending on how things go over the next few days and what the rest of the Plasma team decides, we may end up pushing back the plans by a week. That would still put us well within the time frame of the feature part of the cycle, with hard freeze not up until mid November. Of course, the rest of the team may be able to pick up the slack in my absence, but everyone's pretty busy already so it would be quite understandable if they don't. Or I might end up with lots of hacking time at night in Finland, who knows. I'll let kde-core-devel know what's up before I fly out Sunday evening in any case.
This also leads me look at November 9th as the first Saturday that I could do a videocast. I'd like the first one to be at least somewhat decent (aka not me running around in airports or whatever) and be realistically able to follow it up with one the following week. So I've tentatively set the time for my first videocast for November 9th at 19:00 UTC. It'll be recorded and downloadable later, but that time was the "prime time" slot according to the web poll so many of you took the time to graciously fill out. It also works out nicely because the next two biggest days are Sunday and Monday, so the majority of people who want to should be able to check it out shortly after the broadcast.
Right now, though, I'm off to do some housework ... because that's the sort of crazy fun life I lead. Yee-haw, dishes! ;)
Tuesday, October 21, 2008
plasma is now feature complete?
Note: The following covers features and material that will be available in 4.2, which will not be released until January 2009.
No X11 desktop shell can be considered complete unless it has "eyes", right? Behold, new eyes plasmoid in all its scalable SVG greatness!
Now that this is in kdeplasma-addons, our work here is obviously done. =P
On a more serious note, the Plasma team is making great progress these days. I particularly like the new Plasma style notifications that are part of the new system tray:
If you have more than one notification, they stack up on top of each other. As you can see they have cute curved edges, even without composite, and they are themable. We'll be adding the UI server jobs there as well. And yes, those are Extenders! =)
The new system tray supports icon hiding, embedded Plasmoids and more. Fun! The panel configuration bar is looking really slick, and when the panel configuration is shown right clicks "pass through" the Plasmoids themselves so you can get to the context menu for things like removal or configuration easily.
You'll also be able to install scripted Plasomids from the Internet properly in 4.2.0:
Unfortunately those two scripts are packaged incorrectly and thus do not actually work with the automagic installation. At least you get a cute error dialog now when that happens, and properly formed packages do install.
The first "developer corner" I'll be doing on the videocast will be on making Plasmoid packages. We'll work backwards from there to actually writing a simple Plasmoid from the ground up. =)
explosions
If you updated your Plasma in the last 24-48 hours and got a HUUUUUUUUGE panel that painted at the top of your screen .... know that you were not alone. =) There was a small accident, as sometimes happens in the dev branch, leading to the battery widget growing a little .. uhm .. large and dragging other widgets in the panel with it as it did so.
You may have also noticed our fun new taskbar, complete with its own cute ways of crashing.
Both issues are fixed in svn but I've seen a few people mention it on IRC, emails and blogs (thankfully all with understanding and patience =), so I figured it was worthwhile to let everyone know ...
The root cause of the problem, in case you're at all interested, was that we merged a ton of new code into trunk, including a new taskbar and new system tray implementation among many other things, and it took a day or so to stabilize. It sucks doing it in trunk where everyone following trunk can get bitten by it. I feel we need to adjust our workflow in this regard a bit (specifically where in svn we do integration work), but that won't happen before 4.2.0 is out as we're already too busy to push something as disruptive as that on ourselves right now. We're focused on making 4.2.0 rock, which is a big enough task as it is ;)
You may have also noticed our fun new taskbar, complete with its own cute ways of crashing.
Both issues are fixed in svn but I've seen a few people mention it on IRC, emails and blogs (thankfully all with understanding and patience =), so I figured it was worthwhile to let everyone know ...
The root cause of the problem, in case you're at all interested, was that we merged a ton of new code into trunk, including a new taskbar and new system tray implementation among many other things, and it took a day or so to stabilize. It sucks doing it in trunk where everyone following trunk can get bitten by it. I feel we need to adjust our workflow in this regard a bit (specifically where in svn we do integration work), but that won't happen before 4.2.0 is out as we're already too busy to push something as disruptive as that on ourselves right now. We're focused on making 4.2.0 rock, which is a big enough task as it is ;)
Monday, October 20, 2008
KDE videocast, but when?
As I write this, over 470 people have taken the time to fill out the poll asking if I should do a KDE videocast and the affirmatives were overwhelming.
A significant percentage, nearly 1 in 5, are interested in development tutorials and information related to development. I didn't expect quite that big a percentage, to be honest, but that's great news.
A few were interested in the business aspects of things, but the majority are mostly interested in either anything and everything or else information of interest to the end user.
So I've decided that I will do a weekly show. Given the responses and some further thinking about it all, I've been working on a draft schedule that I could mold each show around:
It's 55 minutes of material, which would give me 5 minutes of flexibility to keep it under an hour. I'm not sure if it's too long, though, and I should keep it to 30 minutes instead. But I'm such a babbler that I could easily fill the hour. If I'm to do a weekly developer tutorial, then there's no hope of a 30 minute episode. With the above schedule, though, you essentially get 25-30 minutes of "talk show", 15 minutes of "town hall" and 15 minutes of "developer corner". So it's kind of 3 shows in one, when looked at that way. I might even record them as three separate segments, though back-to-back, so people can just watch the parts they are interested in.
Anyways, other than a few details I'm still working out on the technical end of things, I need to know when to do it. As I would like some interaction on the show, it will be important to do it at a time when people will actually be able to watch it. =)
So I've put together a simple three question survey that will help me answer that question. I promise it's the last set of questions I'll ask you to fill out as I go through the deign process for the show.
A significant percentage, nearly 1 in 5, are interested in development tutorials and information related to development. I didn't expect quite that big a percentage, to be honest, but that's great news.
A few were interested in the business aspects of things, but the majority are mostly interested in either anything and everything or else information of interest to the end user.
So I've decided that I will do a weekly show. Given the responses and some further thinking about it all, I've been working on a draft schedule that I could mold each show around:
- Intro: 2 minutes of saying "Hi" and what the topics are for the show
- "The Week in Review": 3 minutes covering quickie like release related updates, progress stats and news headlines from places such as theDot
- "The Headline": 10 minutes on a topic I find interesting in the KDE and/or FOSS environment that week.
- "Feature of the Week": 10 minute segment showcasing a specific feature in a KDE application
- "Town Hall": 15 minutes of open Q&A with people in the IRC channel
- "Developer corner": 15 minute hands-on developer tutorial, covering a specific KDE coding technique or topic. May build some topics week-to-week
It's 55 minutes of material, which would give me 5 minutes of flexibility to keep it under an hour. I'm not sure if it's too long, though, and I should keep it to 30 minutes instead. But I'm such a babbler that I could easily fill the hour. If I'm to do a weekly developer tutorial, then there's no hope of a 30 minute episode. With the above schedule, though, you essentially get 25-30 minutes of "talk show", 15 minutes of "town hall" and 15 minutes of "developer corner". So it's kind of 3 shows in one, when looked at that way. I might even record them as three separate segments, though back-to-back, so people can just watch the parts they are interested in.
Anyways, other than a few details I'm still working out on the technical end of things, I need to know when to do it. As I would like some interaction on the show, it will be important to do it at a time when people will actually be able to watch it. =)
So I've put together a simple three question survey that will help me answer that question. I promise it's the last set of questions I'll ask you to fill out as I go through the deign process for the show.
Saturday, October 18, 2008
tomorrow: plasma meeting, and a poll for YOU!
Quick notification: on Saturday the 18th (tomorrow by my clock, but today already for many others) there is a Plasma meeting to determine our game plan leading up to the hard feature freeze mid-November. It will start at 15:00 UTC. Plasma people: be there, or be square!
I'm also considering doing a weekly live broadcast via Ustream.tv. I'd like to do some technical tutorials, do some general user updates and some KDE business related updates (e.V. stuff, for instance). I'd like to make it interactive with people asking questions or providing input on an IRC channel. I'm still not completely sold on the idea ... so I'd like to hear what you think.
Btw, I haven't found any Free internet broadcasters (meaning ones that don't use flash or other proprietary stuff), so if you know of one please let me know.
Also, if anyone knows of any decent Free software that runs on Linux that can combine a live video stream with a live desktop stream, please let me know. Otherwise, I think there's a great opportunity for an interesting v4l2 based project just waiting to be filled: imagine if we had the Free sofware tools to do live education on both usage and deveopment of Free software. The mind boggles! =)
(Oh, and speaking of "ways I communicate to others", for those that haven't stumbled upon it, I also twitter, because it's what all the cool kids are doing and I like to do what the cool kids do in a form of silent ironic mockery. Or something. Meh.)
I'm also considering doing a weekly live broadcast via Ustream.tv. I'd like to do some technical tutorials, do some general user updates and some KDE business related updates (e.V. stuff, for instance). I'd like to make it interactive with people asking questions or providing input on an IRC channel. I'm still not completely sold on the idea ... so I'd like to hear what you think.
Btw, I haven't found any Free internet broadcasters (meaning ones that don't use flash or other proprietary stuff), so if you know of one please let me know.
Also, if anyone knows of any decent Free software that runs on Linux that can combine a live video stream with a live desktop stream, please let me know. Otherwise, I think there's a great opportunity for an interesting v4l2 based project just waiting to be filled: imagine if we had the Free sofware tools to do live education on both usage and deveopment of Free software. The mind boggles! =)
(Oh, and speaking of "ways I communicate to others", for those that haven't stumbled upon it, I also twitter, because it's what all the cool kids are doing and I like to do what the cool kids do in a form of silent ironic mockery. Or something. Meh.)
more on MacOS dashboard stuff
Beat Wolf has made good progress this week on improving the MacOS Dashboard widget support in Plasma. We now have the full widget API implemented (though some of the methods are just stubs as they don't really make sense for Plasma) so Dashboard widgets can now store and retrieve their settings, get notification of being closed, etc. We don't yet have the "flip" animation bit there, but that leads us to the current state of affairs:
Beat has now moved onto the JavaScript files that Apple provides. The JavaScript files contain classes that implement animation timers, sliders, buttons, scroll areas, scroll bars and that info button thing. Many widgets reference these JavaScript files using absolute paths to where they are shipped on MacOS. Obviously this doesn't work very well for Plasma unless you run it on MacOS. ;)
So first things first, Beat put a little trick into the Dashboard installer that replaces the requests for Apple's files with requests for our own files when the widget is installed. So now installed Dashboard widgets will actually load our own JavaSript files.
Only .. we don't have those files .... yet! You see,the ones that Apple ships are not freely redistributable unless you include them with a widget that you write for MacOS. Uh-oh.
The answer? Reverse engineering, of course!
If you are a JavaScript guru, the sort who laughs AJAX in the face and eats JavaScript driven HTML snippets for lunch, check out Apple's kindly provided documentation and help us create those JavaSript files. You can find us in #plasma on irc.freenode.net or on panel-devel at kde dot org, and we'd love your help because we're more the juggling flaming bowling balls C++ type of crew right now and less the trapeze swinging web programmers type crew.
If you do want to help out, please do not look at Apple's JavaScript files as you implement them. Look only at the API documentation, otherwise your work will be "tainted" and we will not be able to legally use it. And that would be a shame.
Beat has now moved onto the JavaScript files that Apple provides. The JavaScript files contain classes that implement animation timers, sliders, buttons, scroll areas, scroll bars and that info button thing. Many widgets reference these JavaScript files using absolute paths to where they are shipped on MacOS. Obviously this doesn't work very well for Plasma unless you run it on MacOS. ;)
So first things first, Beat put a little trick into the Dashboard installer that replaces the requests for Apple's files with requests for our own files when the widget is installed. So now installed Dashboard widgets will actually load our own JavaSript files.
Only .. we don't have those files .... yet! You see,the ones that Apple ships are not freely redistributable unless you include them with a widget that you write for MacOS. Uh-oh.
The answer? Reverse engineering, of course!
If you are a JavaScript guru, the sort who laughs AJAX in the face and eats JavaScript driven HTML snippets for lunch, check out Apple's kindly provided documentation and help us create those JavaSript files. You can find us in #plasma on irc.freenode.net or on panel-devel at kde dot org, and we'd love your help because we're more the juggling flaming bowling balls C++ type of crew right now and less the trapeze swinging web programmers type crew.
If you do want to help out, please do not look at Apple's JavaScript files as you implement them. Look only at the API documentation, otherwise your work will be "tainted" and we will not be able to legally use it. And that would be a shame.
massif improvements
So a few nights ago Maksim-of-KHTML mentioned in passing that it might be interesting to run Plasma through Valgrind's Massif tool. He said he'd done so recently with Konqueror and it had shown some interesting things, such as the creation, parsing, writing, etc of a massive history configuration file (it was 1.5MB on his machine, 800k on mine .. not a small config file to be parsing or saving out constantly).
I tried to ignore it.
Really, i did.
But once the seed was planted it festered. I looked at the clock and it was late evening / early nighttime. "I should go to bed," I thought. But nooooooo... like the occasional *ahem* OCD sufferer that I am, I fired up Massif and pushed Plasma through it like a log through a chipper. The results were quite interesting.
My current plasma config has two desktop Containments/Activities and one Panel Containment/Activity. The panel is the standard layout for a laptop, and the one Activity has the standard folderview and wallpaper but also sports a few extra Plasmoids I use or are working on. The other desktop Activity is a FolderView pointed at a folder with 31 files in it and a different wallpaper. Both Activities are 1280x800 in size. This is the configuration I used for all the tests (except where I turned off wallpapers to see their impact on things) so as to emulate a real world scenario. Namely, mine. ;)
The first thing I noticed in the output was that Plasma was doing a lot of allocations at startup for parsing XML. What XML? SVGs. That was to be expected, really, but I didn't expect it to be the primary source of allocations. Eventually the wallpapers dwarf that memory usage, allocating some 9MB of memory for image data for my two desktop Activities. But still ..
For some time now I'd wanted to use a KPixmapCache to store the results of SVG parsing between runs of Plasma. We were already using a runtime memory cache via QPixmapCache, but KPixmapCache would take it one step further. So I started implementing a cache in Plasma::Theme that Plasma::SVG could use.
(Interesting side-note: KPixmapCache was one of last year's Google Summer of Code projects...)
I rapidly ran into issues because we use SVGs rather .. aggressively in Plasma. We don't just use them for static images, but also embed rendering hints in them, render specific elements of SVGs into larger composite images and various other tricks. This made the goal of "don't open a single SVG on startup" a bit harder to accomplish.
Over the last couple of days, Marco and I worked on various parts of what would be a complete solution, and today Marco nailed the final remaining blocker ... it is now possible to start Plasma up without touching a single SVG file. The cost is some disk space; how much disk space is something we'll work on nailing down. Right now it's a fixed sized cache, but I hope to make it an adaptive cache.
The wins are pretty signifcant. In my first massif runs Plasma would spike up to ~18-19MB of allocations and end up at around 7MB of allocations according to Massif. (Note that this is not the total memory usage, but counts of allocations ... slightly different things. =) Now it spikes up to about 1MB less than that, but more signficantly it ends up at ~2MB of allocations by the end of startup.
It also means we're reading already rendered images from an mmap'd cache file on disk, and this gains my Plasma config a ~10% start up improvement with warm caches on my system. That's not bad, of cousre .. but then again we're talking the difference between 1.8 to 1.9 and 1.6 to 1.65 seconds. So maybe not the most earth shattering of changes to the user. ;)
Update: I did some quick cold-cache timings: sync && echo 3 > /proc/sys/vm/drop_caches as root, then start plasma; did that four times both with and without disk caching, discarded the highest number in each sample set and averaged the remaining times; hopefully I got the methodology mildly right. ;) Assuming I did, the savings are also ~10% on cold start though that translates to 500ms instead of 200ms.
Now I'm seeing things like kDebug() usage and QLibraryPrivate::isPlugin as top allocators at start up. I've reported the latter to the Qt Software engineers, as improving that one dramatically shouldn't be too difficult as right now it's re-allocating (which means load and parse) the Trolltech.conf settings file with each plugin we load. You may have noticed that Plasma uses a "few" plugins "here and there". *cough*
The worst offender is still the wallpapers, of course. They are rendered in separate threads, and so only add ~150ms to start up with my above set-up, but they also cost about 5MB of peak allocation per 1280x800 Activity I have. I have some ideas for how to improve that situation somewhat, though.
Humorously (and I use that word as a replacement for "tragically"), the system tray takes nearly 7 times longer to load its icons into the tray than the rest of Plasma takes to start up. The more icons you have in your tray, the worse it gets. As we shave those 100ths of a second off of Plasma start up time, the system tray makes me cry a little more inside with each passing day.
Anyways, we now have the task ahead of us of profiling the benefits of different size caches and caching strategies in different usage scenarios. Caching can be turned on/off and the size controlled in the configuration file of the libplasma powered application, with something like this:
A huge thanks to Marco for helping me get this rather detailed and perhaps less-than-fun (to say the least) set of work done. I applaud everyone who works on Free software, but doubly so those who take on the less glamorous work. Hats off to Marco, he is certainly this week's Plasma Hacker Extraordinaire! =)
I tried to ignore it.
Really, i did.
But once the seed was planted it festered. I looked at the clock and it was late evening / early nighttime. "I should go to bed," I thought. But nooooooo... like the occasional *ahem* OCD sufferer that I am, I fired up Massif and pushed Plasma through it like a log through a chipper. The results were quite interesting.
My current plasma config has two desktop Containments/Activities and one Panel Containment/Activity. The panel is the standard layout for a laptop, and the one Activity has the standard folderview and wallpaper but also sports a few extra Plasmoids I use or are working on. The other desktop Activity is a FolderView pointed at a folder with 31 files in it and a different wallpaper. Both Activities are 1280x800 in size. This is the configuration I used for all the tests (except where I turned off wallpapers to see their impact on things) so as to emulate a real world scenario. Namely, mine. ;)
The first thing I noticed in the output was that Plasma was doing a lot of allocations at startup for parsing XML. What XML? SVGs. That was to be expected, really, but I didn't expect it to be the primary source of allocations. Eventually the wallpapers dwarf that memory usage, allocating some 9MB of memory for image data for my two desktop Activities. But still ..
For some time now I'd wanted to use a KPixmapCache to store the results of SVG parsing between runs of Plasma. We were already using a runtime memory cache via QPixmapCache, but KPixmapCache would take it one step further. So I started implementing a cache in Plasma::Theme that Plasma::SVG could use.
(Interesting side-note: KPixmapCache was one of last year's Google Summer of Code projects...)
I rapidly ran into issues because we use SVGs rather .. aggressively in Plasma. We don't just use them for static images, but also embed rendering hints in them, render specific elements of SVGs into larger composite images and various other tricks. This made the goal of "don't open a single SVG on startup" a bit harder to accomplish.
Over the last couple of days, Marco and I worked on various parts of what would be a complete solution, and today Marco nailed the final remaining blocker ... it is now possible to start Plasma up without touching a single SVG file. The cost is some disk space; how much disk space is something we'll work on nailing down. Right now it's a fixed sized cache, but I hope to make it an adaptive cache.
The wins are pretty signifcant. In my first massif runs Plasma would spike up to ~18-19MB of allocations and end up at around 7MB of allocations according to Massif. (Note that this is not the total memory usage, but counts of allocations ... slightly different things. =) Now it spikes up to about 1MB less than that, but more signficantly it ends up at ~2MB of allocations by the end of startup.
It also means we're reading already rendered images from an mmap'd cache file on disk, and this gains my Plasma config a ~10% start up improvement with warm caches on my system. That's not bad, of cousre .. but then again we're talking the difference between 1.8 to 1.9 and 1.6 to 1.65 seconds. So maybe not the most earth shattering of changes to the user. ;)
Update: I did some quick cold-cache timings: sync && echo 3 > /proc/sys/vm/drop_caches as root, then start plasma; did that four times both with and without disk caching, discarded the highest number in each sample set and averaged the remaining times; hopefully I got the methodology mildly right. ;) Assuming I did, the savings are also ~10% on cold start though that translates to 500ms instead of 200ms.
Now I'm seeing things like kDebug() usage and QLibraryPrivate::isPlugin as top allocators at start up. I've reported the latter to the Qt Software engineers, as improving that one dramatically shouldn't be too difficult as right now it's re-allocating (which means load and parse) the Trolltech.conf settings file with each plugin we load. You may have noticed that Plasma uses a "few" plugins "here and there". *cough*
The worst offender is still the wallpapers, of course. They are rendered in separate threads, and so only add ~150ms to start up with my above set-up, but they also cost about 5MB of peak allocation per 1280x800 Activity I have. I have some ideas for how to improve that situation somewhat, though.
Humorously (and I use that word as a replacement for "tragically"), the system tray takes nearly 7 times longer to load its icons into the tray than the rest of Plasma takes to start up. The more icons you have in your tray, the worse it gets. As we shave those 100ths of a second off of Plasma start up time, the system tray makes me cry a little more inside with each passing day.
Anyways, we now have the task ahead of us of profiling the benefits of different size caches and caching strategies in different usage scenarios. Caching can be turned on/off and the size controlled in the configuration file of the libplasma powered application, with something like this:
[CachePolicies]
CacheTheme=true
ThemeCacheKb=102400
A huge thanks to Marco for helping me get this rather detailed and perhaps less-than-fun (to say the least) set of work done. I applaud everyone who works on Free software, but doubly so those who take on the less glamorous work. Hats off to Marco, he is certainly this week's Plasma Hacker Extraordinaire! =)
Tuesday, October 14, 2008
FOSS Weekly
This week I'll be a guest on the FLOSS Weekly show. It's co-hosted by Randal Schwartz, Perlmonger extraordinaire, and Leo Laporte. We'll be recording the show mid-week and it will be released on Saturday the 18th. Be sure to tune in!
Update: Randal noted in the comments section that "you can listen to the show by going to http://live.twit.tv - and I'll be monitoring the IRC channel that's linked from there, so if you want to ask questions live, please do so, and I'll bring them in when I can." Seemed important enough to actually note in the main section here.. ;) You can catch the show live on Wednesday at 14:00 PST (21:00 UTC?).
I'd also like to try something a little different this time ... I'd like input from the contributor community before I go on-air.
As an ambassador for the KDE community, I try and keep my finger on as much of the pulse of the project as possible and listen to what people are saying, thinking and doing. The idea is to be able to speak with accuracy and sensitivity about KDE to the outside world. Sometimes this means having to present ideas or plans that I don't personally agree with, but which the community as a general whole has endorsed and/or gained consensus on. Thankfully that's not the usual case. ;)
Aaaaanways ... I realize that as KDE gets larger and larger it's harder and harder for me to peer into the minds of everyone, even if I do read most email on most of our mailing lists and what not.
So if you are a KDE contributor and there is a topic or project you think should get some "air time", please drop me a line before Wednesday. Better yet, send it to kde-promo at kde dot org where more than just myself can pick up on it.
Update: Randal noted in the comments section that "you can listen to the show by going to http://live.twit.tv - and I'll be monitoring the IRC channel that's linked from there, so if you want to ask questions live, please do so, and I'll bring them in when I can." Seemed important enough to actually note in the main section here.. ;) You can catch the show live on Wednesday at 14:00 PST (21:00 UTC?).
I'd also like to try something a little different this time ... I'd like input from the contributor community before I go on-air.
As an ambassador for the KDE community, I try and keep my finger on as much of the pulse of the project as possible and listen to what people are saying, thinking and doing. The idea is to be able to speak with accuracy and sensitivity about KDE to the outside world. Sometimes this means having to present ideas or plans that I don't personally agree with, but which the community as a general whole has endorsed and/or gained consensus on. Thankfully that's not the usual case. ;)
Aaaaanways ... I realize that as KDE gets larger and larger it's harder and harder for me to peer into the minds of everyone, even if I do read most email on most of our mailing lists and what not.
So if you are a KDE contributor and there is a topic or project you think should get some "air time", please drop me a line before Wednesday. Better yet, send it to kde-promo at kde dot org where more than just myself can pick up on it.
ECMAScript Plasmoids
We shipped rudimentary support for both HTML/CSS/JS and ECMAScript (QScript) Plasmoids in 4.1. Petri has been working on the HTML based ones and improving that. There is work on a "full" QScript Plasmoid / DataEngine / Runner ScriptEngine set going on in playground, but that work happens in fits and starts at best.
What I'm most concerned about at the moment, however, is the QScript based Plasmoid ScriptEngine currently in kdebase. It's meant to be a minimal approach binding just what is necessary and no more. It currently binds Plasma::DataEngine and provides the basics needed for painting, canvas style.
To take it to where it ought to be bindings for Plasmas::Service, Plasma::Widgets and probably the QGraphicsLayouts are needed. Some additional facilities to load data from the local file system or the network would also be useful.
These facilities can be added one at a time, and given how QScript works they can be done in large part by making sure the proper things are marked as Q_SCRIPTABLE in the Plasma classes. So thankfully making these kinds of "bindings" are far easier and more straightforward than bindings usually are.
The reason this particular ScriptEngine could be rather important is that it comes with no extra dependencies (QScript comes with Qt, after all), quick load times and would enable us to produce a ScriptEngine that is both easily approached (limited API) and easily secured (we can limit what API is available to each Plasmoid at runtime).
If you are interested in helping out with the QScript ScriptEngine, drop me an email. Unlike the MacOS Dashboard work that needed to be done, there are a good number of small targets here that could easily accommodate 3-4 people without problem. Drop me an email if you're interested. (aseigo at kde dot org, in case you don't have it.)
If we can get HTML, ECMAScript and Python together in a good state for 4.2, we will have the ability to offer both flexibility and safety for Plasmoid development. We can start moving people off of C++ in more situations and onto these dynamic languages, both speeding up development time as well as reducing the possibility of crashes.
What I'm most concerned about at the moment, however, is the QScript based Plasmoid ScriptEngine currently in kdebase. It's meant to be a minimal approach binding just what is necessary and no more. It currently binds Plasma::DataEngine and provides the basics needed for painting, canvas style.
To take it to where it ought to be bindings for Plasmas::Service, Plasma::Widgets and probably the QGraphicsLayouts are needed. Some additional facilities to load data from the local file system or the network would also be useful.
These facilities can be added one at a time, and given how QScript works they can be done in large part by making sure the proper things are marked as Q_SCRIPTABLE in the Plasma classes. So thankfully making these kinds of "bindings" are far easier and more straightforward than bindings usually are.
The reason this particular ScriptEngine could be rather important is that it comes with no extra dependencies (QScript comes with Qt, after all), quick load times and would enable us to produce a ScriptEngine that is both easily approached (limited API) and easily secured (we can limit what API is available to each Plasmoid at runtime).
If you are interested in helping out with the QScript ScriptEngine, drop me an email. Unlike the MacOS Dashboard work that needed to be done, there are a good number of small targets here that could easily accommodate 3-4 people without problem. Drop me an email if you're interested. (aseigo at kde dot org, in case you don't have it.)
If we can get HTML, ECMAScript and Python together in a good state for 4.2, we will have the ability to offer both flexibility and safety for Plasmoid development. We can start moving people off of C++ in more situations and onto these dynamic languages, both speeding up development time as well as reducing the possibility of crashes.
python plasmoids
Simon Edwards committed initial support for writing Plasmoids in Python today. (Pythonoids? Pymoids? hm...) There are some build issues to work out, as it relies on CMake files from kdebindings; those probably need to get moved to kdelibs or some-such.
The support is for the full Plasma API, so essentially anything you can do in C++ you can do in Python. There are a couple of example Python plugins in there, and I hope we can get some tutorials up on Techbase demonstrating how to use the Python bindings.
There's also support for Python DataEngines in there. Huzzah...
The support is for the full Plasma API, so essentially anything you can do in C++ you can do in Python. There are a couple of example Python plugins in there, and I hope we can get some tutorials up on Techbase demonstrating how to use the Python bindings.
There's also support for Python DataEngines in there. Huzzah...
Saturday, October 11, 2008
feature completing mac os dashboard widget support
Update: A number of people have contacted me about this and work has begun. I'll keep you all updated as to progress. Thanks to those who met the call with action!
Right now Plasma can load and display MacOS Dashboard widgets .. but not all of them. If you look at the API reference from Apple you'll see that there are 6 properties (or callbacks) and 8 methods that are available in the JavaScript runtime for these widgets.
Right now Plasma implements exactly zero of them in the Dashboard ScriptEngine, causing several widgets to fail when loaded.
Implementing most of these would be pretty trivial, and they can all be done one at a time. The six properties all have equivalents in the C++, so it would just be a matter of hooking those up. The eight methods are all easily implementable using the KDE libraries and several would probably be one-liners (such as the openApplication or openURL methods), the preferences flip ones would require a small amount of HTML+JS hacking to do the flip animation .. leaving just
Personally, I'm not overly motivated to work on this given everything else that's currently on my plate. It's one of those things that I will eventually get to because it needs to get done, but that's not overly inspiring, is it? ;)
It occurred to me that this would be a great little project with a very manageable scope, working on a very small body of code that is a plugin (so you don't need to reload the desktop as a whole or deal with long compiles) that would give immediate results and can be worked on one piece at a time to go from zero to fourteen.
If you are interested in working on this, please drop me an email or visit us in #plasma on irc and I'll get you started.
Right now Plasma can load and display MacOS Dashboard widgets .. but not all of them. If you look at the API reference from Apple you'll see that there are 6 properties (or callbacks) and 8 methods that are available in the JavaScript runtime for these widgets.
Right now Plasma implements exactly zero of them in the Dashboard ScriptEngine, causing several widgets to fail when loaded.
Implementing most of these would be pretty trivial, and they can all be done one at a time. The six properties all have equivalents in the C++, so it would just be a matter of hooking those up. The eight methods are all easily implementable using the KDE libraries and several would probably be one-liners (such as the openApplication or openURL methods), the preferences flip ones would require a small amount of HTML+JS hacking to do the flip animation .. leaving just
system method which likely are used for calls that don't exist outside of MacOS in many cases but which could still be provided as a JavaScript wrapper around QProcess.Personally, I'm not overly motivated to work on this given everything else that's currently on my plate. It's one of those things that I will eventually get to because it needs to get done, but that's not overly inspiring, is it? ;)
It occurred to me that this would be a great little project with a very manageable scope, working on a very small body of code that is a plugin (so you don't need to reload the desktop as a whole or deal with long compiles) that would give immediate results and can be worked on one piece at a time to go from zero to fourteen.
If you are interested in working on this, please drop me an email or visit us in #plasma on irc and I'll get you started.
Wednesday, October 08, 2008
dear KDE3 KDesktop users:
I'm looking for someone with a built-from-source KDE 3 around to test this patch to kdebase/kdesktop/minicli.cpp:
- QString Minicli::calculate(const QString &exp)
+ QString Minicli::calculate(const QString &input)
{
QString result, cmd;
+ QString exp = input;
+ //replace commas with dots so european decimals can be calculated
+ exp.replace(QChar(','), ".");
If someone out there could apply it and confirm that it indeed works (symptoms of success would include "100,3*4" coming out as101.2 401.2), that will make one Pascal d'Hermilly, some guy in Finland and other European-style-command-is-a-decimal-point sorts still using KDE3 happy.
As I don't have a KDE3 codebase kicking around, it's a little inconvenient for me to test this. Any takers? =)
- QString Minicli::calculate(const QString &exp)
+ QString Minicli::calculate(const QString &input)
{
QString result, cmd;
+ QString exp = input;
+ //replace commas with dots so european decimals can be calculated
+ exp.replace(QChar(','), ".");
If someone out there could apply it and confirm that it indeed works (symptoms of success would include "100,3*4" coming out as
As I don't have a KDE3 codebase kicking around, it's a little inconvenient for me to test this. Any takers? =)
Tuesday, October 07, 2008
the exciting world of KDE 4
I haven't blogged for a week or so .. but it's not because I haven't been busy or that nothing exciting has been going on. Quite the opposite, actually, but it left me feeling like I really didn't want to write a blog entry on top of it all. ;) This afternoon felt like a good time to pick up the (digital) pen again, though. This entry will probably be a bit scattered due to the backlog of things to share with you that have piled up.
While chatting with a friend, I noticed a really nice touch in Kopete when they sent me a bunch of files:
I remember back when Kopete would pop up a dialog somewhere randomly asking me if I'd like to accept the file transfer. This is so much nicer; kudos to the Kopete developers.
There is a running joke in KDE circles that goes like this: "* marble". It came about due to Marble's mastermind, Torsten, and his constant (but consistent!) reminding of people about the mapping application. He would often do so with great brevity, however: often it would take the form of an email reply to a list of examples or features with that one additional line: "* marble", and now any time we end up with a list (regardless of what it is a list of) chances are someone will pop off a "* marble" for old times sake.
Torsten's continued work, along with the great and ongoing support Marble receives from its team of dedicated developers, has paid off. Marble has begun to get noticed far and wide. Torsten has sent me links to several articles on various websites that mention Marble testifying to this. Why the interest? Easy: it stands in a category of its own in the F/OSS landscape, and when you are a crowd of one competing against the likes of Google Earth and cooperating with one of the biggest Free information projects in the world (Open Street Map) you get people's attention.
Even the Free Software Foundation has taken notice, listing Marble as part of its High Priority Software Projects. Free Software Magazine is also carrying a nice article on Open Street Map that covers Marble as well. It's really encouraging to see some of the KDE apps get more and more of the positive attention they deserve.
It isn't just individual applications like Marble, though, that are catching people's attention. I somehow ended up being listed on silicon.com's 2008 Agenda Setters list at position 40. They claim their list contains "the top 50 most influential individuals in the worldwide technology and IT industries – business leaders, CEOs, CIOs, techies, open source gurus, security experts, visionaries, entrepreneurs and politicos". Scratching my head as how I ended up on this list, it all made sense once I read this summary they put together. Really, they didn't put me on that list ... they put KDE on that list.
They called us "exciting", commended us "for the backbone it has provided for other popular applications" and noted both our application development platform as well as KOffice (though not by name, unfortunately).
So it is obvious that everyone who has been involved in making KDE what it is deserves part of that nod from silicon.com, and that we are catching the imagination of the industry. In fact, KDE is only one of three FOSS projects on that list (the others being Samba and Ubuntu) and there are not that many other FOSS faces to be seen either (Wales, Stallman, Shuttleworth, Allison). It's a pretty cool achievement that we've been able to push awareness of our work that far. Congratulations to everyone in our community of creative minds and hearts!
In more nuts-and-bolts news, Plasma continues to shape up for 4.2 nicely. Thanks to work spearheaded by Christian Mollekopf we now have a taskbar that can group and sort tasks and display them in multiple rows. It's all configurable of course, and right now there are two grouping and two sorting strategies that let you group by program or manually (drag and drop tasks around to form groups) and sort by program name or manually (again, by drag and drop). The manual sorting and grouping is a feature that Kicker never got, but now we have it in Plasma.
Following our "visualization should be separated data management" philosophy, Christian implemented all the sorting and grouping inside of libtaskmanager. This means that other approaches to visualizing the windows running on your system can also take advantage of these same features if they should wish to do so. It also keeps the default tasks widget itself a bit simpler than it would otherwise be: it can concentrate just on getting display right, which is already complex enough for a task bar. =)
We also have a new system tray that's about to migrate into the KDE default workspace. Jason Stubbs implemented it in a way that not only works better than the existing one with the current system tray widgets we have to put with, but wrote it so that we can plugin multiple "protocols" into it. This opens the way for new approaches to the system tray, which we will continue to explore, without having to lose support for or coherency with existing system tray solutions. Frederik-of-folderview-fame also added support for the _NET_SYSTEM_TRAY_VISUAL hint and handling of argb windows correctly. It also support hiding icons, showing desktop and system notifications and more. It's a new widget, and still has lots of room for improvement over time, but we finally have a system tray widget that is designed to be extensible behind the scenes so we can explore and implement a truly unified notification area and start moving away from some of the limitations of the existing system tray protocol on X11.
Will Stephenson was online today discussing the new network manager Plasmoid, something the OpenSuse team is working on. This isn't strictly for 4.2, however: they will be shipping it with their 4.1 based desktops as well, though we'll be working on making it a bit sexier for 4.2. Even the clocks are getting their due helping attention: tooltips, time zone configuration and wheel scrolling were both recently improved by Anne-Marie and Rafał Miłecki. In fact, there isn't much in Plasma that isn't getting nice improvements for 4.2.
On my hitlist for this week is working on a new Add Widgets dialog that hopefully will both look a bit more "Plasma" and allow for things like removing packages and hooking into third party widget shops (e.g. Google's online gadgets listings), finishing up the last bits of Plasma::Service (Montesi and I have been working through what bits were necessary in the Jolie Metaservice and he's finished up his side of the work, so now the pressure is on me ;) and hooking up both Plasma (for controlling the active context) and the KDE file dialog to Nepomuk (for searching). That probably sounds like a hell of a lot of work, and while it isn't a small amount of work, a lot of it is really just icing on the cake that has been a long time in the oven. The work for being able to use Nepomuk in the file dialog for search, for instance, has largely been done by Sebastian Trueg in his working on the Nepomuk ioslave which just made it into the KDE runtime for 4.2.
In non-KDE life, yesterday the P-man went to a farm with his class where he helped build a staircase for a barn, fed horses (he returned with some of their hoof clippings, too), rode a donkey and led cows out to the pasture. He loved it, which is great as not enough city kids get exposure to these things in my opinion.
Ok, that's probably enough for one entry. ;) I really need to be more consistent in my blogging intervals so that they don't all end up as long and scattered as this one...
While chatting with a friend, I noticed a really nice touch in Kopete when they sent me a bunch of files:
I remember back when Kopete would pop up a dialog somewhere randomly asking me if I'd like to accept the file transfer. This is so much nicer; kudos to the Kopete developers.
There is a running joke in KDE circles that goes like this: "* marble". It came about due to Marble's mastermind, Torsten, and his constant (but consistent!) reminding of people about the mapping application. He would often do so with great brevity, however: often it would take the form of an email reply to a list of examples or features with that one additional line: "* marble", and now any time we end up with a list (regardless of what it is a list of) chances are someone will pop off a "* marble" for old times sake.
Torsten's continued work, along with the great and ongoing support Marble receives from its team of dedicated developers, has paid off. Marble has begun to get noticed far and wide. Torsten has sent me links to several articles on various websites that mention Marble testifying to this. Why the interest? Easy: it stands in a category of its own in the F/OSS landscape, and when you are a crowd of one competing against the likes of Google Earth and cooperating with one of the biggest Free information projects in the world (Open Street Map) you get people's attention.
Even the Free Software Foundation has taken notice, listing Marble as part of its High Priority Software Projects. Free Software Magazine is also carrying a nice article on Open Street Map that covers Marble as well. It's really encouraging to see some of the KDE apps get more and more of the positive attention they deserve.
It isn't just individual applications like Marble, though, that are catching people's attention. I somehow ended up being listed on silicon.com's 2008 Agenda Setters list at position 40. They claim their list contains "the top 50 most influential individuals in the worldwide technology and IT industries – business leaders, CEOs, CIOs, techies, open source gurus, security experts, visionaries, entrepreneurs and politicos". Scratching my head as how I ended up on this list, it all made sense once I read this summary they put together. Really, they didn't put me on that list ... they put KDE on that list.
They called us "exciting", commended us "for the backbone it has provided for other popular applications" and noted both our application development platform as well as KOffice (though not by name, unfortunately).
So it is obvious that everyone who has been involved in making KDE what it is deserves part of that nod from silicon.com, and that we are catching the imagination of the industry. In fact, KDE is only one of three FOSS projects on that list (the others being Samba and Ubuntu) and there are not that many other FOSS faces to be seen either (Wales, Stallman, Shuttleworth, Allison). It's a pretty cool achievement that we've been able to push awareness of our work that far. Congratulations to everyone in our community of creative minds and hearts!
In more nuts-and-bolts news, Plasma continues to shape up for 4.2 nicely. Thanks to work spearheaded by Christian Mollekopf we now have a taskbar that can group and sort tasks and display them in multiple rows. It's all configurable of course, and right now there are two grouping and two sorting strategies that let you group by program or manually (drag and drop tasks around to form groups) and sort by program name or manually (again, by drag and drop). The manual sorting and grouping is a feature that Kicker never got, but now we have it in Plasma.
Following our "visualization should be separated data management" philosophy, Christian implemented all the sorting and grouping inside of libtaskmanager. This means that other approaches to visualizing the windows running on your system can also take advantage of these same features if they should wish to do so. It also keeps the default tasks widget itself a bit simpler than it would otherwise be: it can concentrate just on getting display right, which is already complex enough for a task bar. =)
We also have a new system tray that's about to migrate into the KDE default workspace. Jason Stubbs implemented it in a way that not only works better than the existing one with the current system tray widgets we have to put with, but wrote it so that we can plugin multiple "protocols" into it. This opens the way for new approaches to the system tray, which we will continue to explore, without having to lose support for or coherency with existing system tray solutions. Frederik-of-folderview-fame also added support for the _NET_SYSTEM_TRAY_VISUAL hint and handling of argb windows correctly. It also support hiding icons, showing desktop and system notifications and more. It's a new widget, and still has lots of room for improvement over time, but we finally have a system tray widget that is designed to be extensible behind the scenes so we can explore and implement a truly unified notification area and start moving away from some of the limitations of the existing system tray protocol on X11.
Will Stephenson was online today discussing the new network manager Plasmoid, something the OpenSuse team is working on. This isn't strictly for 4.2, however: they will be shipping it with their 4.1 based desktops as well, though we'll be working on making it a bit sexier for 4.2. Even the clocks are getting their due helping attention: tooltips, time zone configuration and wheel scrolling were both recently improved by Anne-Marie and Rafał Miłecki. In fact, there isn't much in Plasma that isn't getting nice improvements for 4.2.
On my hitlist for this week is working on a new Add Widgets dialog that hopefully will both look a bit more "Plasma" and allow for things like removing packages and hooking into third party widget shops (e.g. Google's online gadgets listings), finishing up the last bits of Plasma::Service (Montesi and I have been working through what bits were necessary in the Jolie Metaservice and he's finished up his side of the work, so now the pressure is on me ;) and hooking up both Plasma (for controlling the active context) and the KDE file dialog to Nepomuk (for searching). That probably sounds like a hell of a lot of work, and while it isn't a small amount of work, a lot of it is really just icing on the cake that has been a long time in the oven. The work for being able to use Nepomuk in the file dialog for search, for instance, has largely been done by Sebastian Trueg in his working on the Nepomuk ioslave which just made it into the KDE runtime for 4.2.
In non-KDE life, yesterday the P-man went to a farm with his class where he helped build a staircase for a barn, fed horses (he returned with some of their hoof clippings, too), rode a donkey and led cows out to the pasture. He loved it, which is great as not enough city kids get exposure to these things in my opinion.
Ok, that's probably enough for one entry. ;) I really need to be more consistent in my blogging intervals so that they don't all end up as long and scattered as this one...
Wednesday, October 01, 2008
Trolls, QEdje and Plasma
For some reason, Artur's blog about the integration of QEdje into Plasma (now in kdebase!) got listed waaaaaaay down the list on planet.kde.org; so here's a link to the awesomeness titled Trolls, QEdje and Plasma. Enjoy! =)
shooting the pipe
We have a pipeline for Plasma development: if it's an obvious fix/improvement, we commit and rely on post-commit peer review; if it's a manageable patch (no more than a few hundred lines of code) to a core component, we post it on the review board for comment; if it's a huge set of changes, use a branch; if it's a new plugin (plasmoid, runner, dataengine, scriptengine, wallpaper, etc) then start it in playground, move it to kdereview when it's ready and finally to either kdebase or kdeplasma-addons.
Leading up to the 4.0 release when everything was in a mad rush, and then briefly after 4.0 as well, we had an "open trunk/" policy. It was often pretty disastrous and I'd lose whole days to sorting the problems out.
These days patches and plugins alike appear fairly constantly, usually with little or no notice, outside of trunk/. It's a great feature, as it lets people experiment freely without having to worry about destabilizing things or having to get people to validate their ideas before having code to show. It's not uncommon to see a Plasmoid be forked and worked on in the playground with a few fundamental changes to the design of it, sometimes resulting in failure but often in something better than what was started with. The freedom that the playground offers is vital.
(This is not a unique-to-Plasma development style, of course.)
The main challenge for me is keeping up with it all: Right now in kdereview we have two Runners, six Plasmoids, two DataEngines andone ScriptEngine (update: it just got moved to kdebase) under inspection. These should all end up in 4.2.0.
I spent part of today and yesterday going through the Plasmoids in our playground area and have so far come up with six candidates for immediate movement to kdereview, three that should be prioritized for completion (due to the important nature of the feature they provide) and two more that are likely candidates for 4.2 (but aren't there yet). There's another nine that are similarly close and could all be moved to completion with a bit more effort. There are five plasmoids and a handful of scripting examples that will likely form the basis for a set of "How To" examples. There are another 17 I have yet to look at and five that I've just deferred examination on.
And that's just Plasmoids. I still have to take a run through the DataEngines, Runners, ScriptEngines and Wallpapers in playground to complete this round of shooting the development pipeline.
The effort is more than worth it, though, as others have put tons of their time and effort into these additions, and it is these additions which both validate, test and bring user perceivable value to the infrastructure beneath them.
What I do find interesting in going through a lot of these plugins is that when putting finishing touches on things I'm usually removing code and letting the underlying frameworks do more of the work. People tend to create things with a bit more complexity than necessary, and it's fun to watch how as we careful tend to central API like libplasma how the code on the edges shrinks.
When creating a clock, only the code necessary for a clock itself should be present.
I'm really excited about the set of examples, though, as we'll finally have a nice set of simple, clean, clear and self-contained bits of code to demonstrate various techniques in Plasma.
Anyways .. this is a mostly content free blog entry, I know. But whenever I get to poke my head out of the framework code and into the plugins other people are writing I get all giddy. ;)
Leading up to the 4.0 release when everything was in a mad rush, and then briefly after 4.0 as well, we had an "open trunk/" policy. It was often pretty disastrous and I'd lose whole days to sorting the problems out.
These days patches and plugins alike appear fairly constantly, usually with little or no notice, outside of trunk/. It's a great feature, as it lets people experiment freely without having to worry about destabilizing things or having to get people to validate their ideas before having code to show. It's not uncommon to see a Plasmoid be forked and worked on in the playground with a few fundamental changes to the design of it, sometimes resulting in failure but often in something better than what was started with. The freedom that the playground offers is vital.
(This is not a unique-to-Plasma development style, of course.)
The main challenge for me is keeping up with it all: Right now in kdereview we have two Runners, six Plasmoids, two DataEngines and
I spent part of today and yesterday going through the Plasmoids in our playground area and have so far come up with six candidates for immediate movement to kdereview, three that should be prioritized for completion (due to the important nature of the feature they provide) and two more that are likely candidates for 4.2 (but aren't there yet). There's another nine that are similarly close and could all be moved to completion with a bit more effort. There are five plasmoids and a handful of scripting examples that will likely form the basis for a set of "How To" examples. There are another 17 I have yet to look at and five that I've just deferred examination on.
And that's just Plasmoids. I still have to take a run through the DataEngines, Runners, ScriptEngines and Wallpapers in playground to complete this round of shooting the development pipeline.
The effort is more than worth it, though, as others have put tons of their time and effort into these additions, and it is these additions which both validate, test and bring user perceivable value to the infrastructure beneath them.
What I do find interesting in going through a lot of these plugins is that when putting finishing touches on things I'm usually removing code and letting the underlying frameworks do more of the work. People tend to create things with a bit more complexity than necessary, and it's fun to watch how as we careful tend to central API like libplasma how the code on the edges shrinks.
When creating a clock, only the code necessary for a clock itself should be present.
I'm really excited about the set of examples, though, as we'll finally have a nice set of simple, clean, clear and self-contained bits of code to demonstrate various techniques in Plasma.
Anyways .. this is a mostly content free blog entry, I know. But whenever I get to poke my head out of the framework code and into the plugins other people are writing I get all giddy. ;)
Subscribe to:
Posts (Atom)
