KDE developers around the world: we're currently just 14 closed bug reports away from a break even week! As of right now 475 bugs have been opened in the last 7 days, and people have resolved 461 reports.
I'd love to see KDE 4.2 get released with bugs.kde.org hosting less than 17,000 open reports and the only way to get there is to turn those status columns green!
Last week we delivered a crushing blow with twice as many closed as opened. If one removes the mass resolution of the 300+ aRts bugs with UNMAINTAINED, we were still 200 or so reports in the positive side of the ledger when Saturday rolled around.
Obviously, we won't have quite such a dramatic showing this week, but let's at least not lose ground after we've done so well recently.
Here's towards a better, slightly more perfect KDE 4.2.0! =)
Saturday, November 29, 2008
Friday, November 28, 2008
KDE Videocast Episode 3, November 29!
Episode 3 of my KDE videocast will be broadcast live at 17:00 UTC on Saturday, November 29nd over at UStream.
This week's show will look like this:
A non-flv version with all the media and text files used in the show will be offered via bittorrent after the show so you can download it for offline viewing, in addition to the usual online clip at UStream. The torrent will also have the files provided individually this time versus the (bad idea) of a single archive.
See you there tomorrow!
This week's show will look like this:
- Hello, viewers!
- Week in review: KDE 4.2 Beta 1, Gran Canaria Desktop Summit and a developer activity recap.
- The Headline: The realities of meeting modern user needs, or "Why do Amarok and Akonadi use MySQL?"
- Feature of the Week: It's a two-fer! Migrating to Akonadi using kres-migrator and finding places with Marble's new search capabilities.
- Town Hall: Bring your questions to #aseigo on irc.freenode.net, or leave one in the comment section below if you can't show up! I'll have my sack of answers at the ready at showtime.
- Developer Corner: Using Phonon to add rich media support easily to your application.
A non-flv version with all the media and text files used in the show will be offered via bittorrent after the show so you can download it for offline viewing, in addition to the usual online clip at UStream. The torrent will also have the files provided individually this time versus the (bad idea) of a single archive.
See you there tomorrow!
abi checkers
Do you know of a tool that runs on Linux, preferably is FOSS, and can compare the ABI of two C++ libraries? If so, leave a link for me in the comments! =)
Thursday, November 27, 2008
on my other perspective
I didn't mention it in my last blog entry on supppy chains because .. well .. it's not anything I can really say much about at this time, but: I'm currently spending some time consulting to a commercial project where one of the integral components is based on a Linux distribution. (Holy crap, how is that for vague?)
So for a good part of my days over the last while, I've had the experience of being downstream from KDE as well as the distributions who are KDE's downstreams. Some days it feels like I'm in a mobius loop as I shift positions in the production sequence. =)
It's been nice to be able to hold that perspective for extended periods of time, though. Being downstream (once removed!) from KDE (and the rest of the stack) is a rather different experience and mindset from being upstream to a distro. That's probably stating the obvious, but it's certainly another part of what has gotten me thinking about these issues more deeply.
Holding both experiences concurrently has given me the context to do things like explore negotiating with myself, role playing both sides of the conversation. (I don't actually self-negotiate when it comes to the real-world work issues; this is more a "mental exercises for hot showers" type material.)
More practically, I have to apply my goals and needs as a downstream without prejudice because I have a team that relies on and demands that; in a different point of the week (or sometimes the same day, even) I have to apply my goals and needs as an upstream without prejudice because, well, I have a team that relies on and demands that.
It is said that you can not slave for two masters, and at first I thought I'd run into issues with this until I realized that my master for whom I slave is one and the same: Free software. I just get to play the role of two different servants whose work must dovetail.
Given that these "supply chain" issues are kicking my ass in both of my servant roles, it's become something of an un-ignorable burning itch. Like athletes foot, or jock itch. Yeah, not pleasant.
I do also want to give a positive example (that I personally had nothing to do with) to show that this up/down coordination can work out well. The challenge was that a KDE4 user interface to network manager was needed.
Preferably it would be an improvement over the KDE3 one and it should work with the latest, greatest network manager stuff. Now, network manager is "upstream" to KDE and the distributions who really, really want this are downstream from us. Along comes Novell, one of our downstreams, and they say, "We really need both a better KDE network manager GUI for OpenSuse and it needs to use KDE4 libraries." They (Will Stephenson being huge in this role) start working on it. That work goes into the upstream repository while it is worked on, thus building a partnership through shared infrastructure.
Unfortunately KDE 4.2 goes into feature freeze before the network manager interface is ready. So people talk about it and determine that it could be in shape by the time 4.2.0 comes out, it just can't be part of the 4.2.0 release proper. OpenSuse could then ship this thing with their KDE4 packages even though it's not actually released via upstream yet. Sebastian Kugler, an "upstream" Plasma developer, starts pitching in to help make it happen. Everyone is informed and comfortable with the situation.
It seems to be working out well, but what happened differently here?
People along different parts of the production/supply chain got together and coordinated. Needs were communicated upwards in advance of crunch-time, and a coordinated effort emerged. Upstream was given a heads up about the inclusion of a non-released component that is just That Important(tm), and upstream actually got involved and puts resources on it to help ensure success. Upstream's happy because they get help from a much needed component from downstream, downstream's happy because they fill a need.
It's not a perfect world (perfect would have been inclusion with 4.2.0, or heck, even 4.0 if we really want to go for Perfect(tm)), but it's close enough (they are still using the KDE3 network manager in the meantime) and everyone is informed and comfortable with the plans. Needles to say, the user wins across the board and nobody is losing.
This all seems common sense, doesn't it?
Yet it is a much rarer occurrence in the FOSS desktop world than it ought to be. We are often chasing our upstreams, who are often running off on their own tangent, while we're doing the same thing to our downstreams. Every so often someone screws the upstream over because they don't feel they have a better choice, and the upstream gets miffed. All perfectly logical, but not very brilliant.
So why did common sense prevail in this case? In part because Will, Sebas and the Plasma team all know each other and get along. We talk often, have shared values and open lines of communication. Obviously this is not an easy dynamic to replicate.
So we know that with agreeable circumstances it can work out. We know that release schedules don't need to get in the way even if they don't line up perfectly. We know that resource allocation can be modified in response to voiced need. We know that different points in the chain can work together as if we were actually coordinated in some logical fashion. We do not have to guess at the plasusibility of it, then, we just need to figure out how to replicate the phenomenon.
What we are (or at least I am) missing are sure-fire ways to replicate these results when:
And it all needs to fit into 40-60 hours a week. Cue the Mission Impossible theme song? =) It may sound like it when it's put that way, but I have faith that we can construct an 80% solution that will blow away our current 20%-because-we-get-lucky track record.
So for a good part of my days over the last while, I've had the experience of being downstream from KDE as well as the distributions who are KDE's downstreams. Some days it feels like I'm in a mobius loop as I shift positions in the production sequence. =)
It's been nice to be able to hold that perspective for extended periods of time, though. Being downstream (once removed!) from KDE (and the rest of the stack) is a rather different experience and mindset from being upstream to a distro. That's probably stating the obvious, but it's certainly another part of what has gotten me thinking about these issues more deeply.
Holding both experiences concurrently has given me the context to do things like explore negotiating with myself, role playing both sides of the conversation. (I don't actually self-negotiate when it comes to the real-world work issues; this is more a "mental exercises for hot showers" type material.)
More practically, I have to apply my goals and needs as a downstream without prejudice because I have a team that relies on and demands that; in a different point of the week (or sometimes the same day, even) I have to apply my goals and needs as an upstream without prejudice because, well, I have a team that relies on and demands that.
It is said that you can not slave for two masters, and at first I thought I'd run into issues with this until I realized that my master for whom I slave is one and the same: Free software. I just get to play the role of two different servants whose work must dovetail.
Given that these "supply chain" issues are kicking my ass in both of my servant roles, it's become something of an un-ignorable burning itch. Like athletes foot, or jock itch. Yeah, not pleasant.
I do also want to give a positive example (that I personally had nothing to do with) to show that this up/down coordination can work out well. The challenge was that a KDE4 user interface to network manager was needed.
Preferably it would be an improvement over the KDE3 one and it should work with the latest, greatest network manager stuff. Now, network manager is "upstream" to KDE and the distributions who really, really want this are downstream from us. Along comes Novell, one of our downstreams, and they say, "We really need both a better KDE network manager GUI for OpenSuse and it needs to use KDE4 libraries." They (Will Stephenson being huge in this role) start working on it. That work goes into the upstream repository while it is worked on, thus building a partnership through shared infrastructure.
Unfortunately KDE 4.2 goes into feature freeze before the network manager interface is ready. So people talk about it and determine that it could be in shape by the time 4.2.0 comes out, it just can't be part of the 4.2.0 release proper. OpenSuse could then ship this thing with their KDE4 packages even though it's not actually released via upstream yet. Sebastian Kugler, an "upstream" Plasma developer, starts pitching in to help make it happen. Everyone is informed and comfortable with the situation.
It seems to be working out well, but what happened differently here?
People along different parts of the production/supply chain got together and coordinated. Needs were communicated upwards in advance of crunch-time, and a coordinated effort emerged. Upstream was given a heads up about the inclusion of a non-released component that is just That Important(tm), and upstream actually got involved and puts resources on it to help ensure success. Upstream's happy because they get help from a much needed component from downstream, downstream's happy because they fill a need.
It's not a perfect world (perfect would have been inclusion with 4.2.0, or heck, even 4.0 if we really want to go for Perfect(tm)), but it's close enough (they are still using the KDE3 network manager in the meantime) and everyone is informed and comfortable with the plans. Needles to say, the user wins across the board and nobody is losing.
This all seems common sense, doesn't it?
Yet it is a much rarer occurrence in the FOSS desktop world than it ought to be. We are often chasing our upstreams, who are often running off on their own tangent, while we're doing the same thing to our downstreams. Every so often someone screws the upstream over because they don't feel they have a better choice, and the upstream gets miffed. All perfectly logical, but not very brilliant.
So why did common sense prevail in this case? In part because Will, Sebas and the Plasma team all know each other and get along. We talk often, have shared values and open lines of communication. Obviously this is not an easy dynamic to replicate.
So we know that with agreeable circumstances it can work out. We know that release schedules don't need to get in the way even if they don't line up perfectly. We know that resource allocation can be modified in response to voiced need. We know that different points in the chain can work together as if we were actually coordinated in some logical fashion. We do not have to guess at the plasusibility of it, then, we just need to figure out how to replicate the phenomenon.
What we are (or at least I am) missing are sure-fire ways to replicate these results when:
- We don't all know each other, or know each other very well
- We aren't in constant, regular communication with each other
- We rely on each other for different pieces of the puzzle
- We have independent bodies setting each group's agenda/roadmap
- The topic isn't always as limited and focussed as "an interface for the user to activate a network connection".
And it all needs to fit into 40-60 hours a week. Cue the Mission Impossible theme song? =) It may sound like it when it's put that way, but I have faith that we can construct an 80% solution that will blow away our current 20%-because-we-get-lucky track record.
Wednesday, November 26, 2008
free software supply chains
Over the past few months I've been quietly tracking our upstream and downstream interactions. The motivation for this has been my experience with the KDE 4 series, in which we have both been on more people's radar (when was the last time NVidia mentioned KDE 3 in a driver release?) and seen more trainwrecks both up- and down-stream from us.
In particular, the "distribution backporting" issue has really gotten out of hand. It's no longer just individual unbaked features that are being backported and shipped with stable KDE releases, but now entire applications are being pulled from pre-beta SVN and shipped with stable KDE releases. I know of two different applications this has now happened to.
Just as disturbing, some downtreams feel that they have the right to speak for us as an upstream to their communities and have, by doing so, misled people and abused KDE's relationship with users in doing so.
Of course, I'm still reeling from the issues Plasma has run into all across the X.org and Qt map. Features those projects have advertised, in some cases for years, simply were not mature or tested until we showed up and found out the hard way by running headlong into pointy skewers of buggy or simply featureless code bases which got that way due to not having real world applications at the ready to tease them into shape.
The losers in this are all around: users get sub-par product, KDE's relationships are damaged both with users and downstreams, upstreams look incompetent when really they just got caught out unawares and downstreams provide a muddled experience in their delivery phases.
This is not a healthy situation. I hope that's stating the obvious and that we're all in agreement thus far.
Note that I haven't really said anything about who's to blame for this. Take the case of lacking real world applications to test our frameworks with: who is at fault? Should KDE have been there earlier pushing on these areas back when these features were first being trialed? Should those writing these frameworks have ensured there were real world type applications doing meaningful things with their new fangled hotness before claiming stability and maturity? Not easy questions, are they? Personally, I'm not one for fingerpointing unless you really get it obviously wrong after having had a workable solution pointed out to you. We aren't at that point, however, with nearly any of the above.
While tracking these issues and trying to make heads and tails of them, often with great frustration draped across my brow, I have also been looking for analogs elsewhere. Most problems have already been at least identified, and most problems that have been identified have a history of attempted solutions. Just because I haven't had to deal with a particular problem first hand doesn't mean someone else hasn't, and so I've been searching for solutions (good or bad) elsewhere.
In talking with some of our downstreams, I've found it increasingly useful to talk about things in terms of supply chains and the kinds of relationships that end up forming around them. Unlike "traditional" software development where the supply chain is tightly managed and usually completely or nearly completely internal, the open source model seems to me to be a lot more like the free market dynamics seen in commodity markets and how supply trickles on through the machinery to eventually create products the consumer purchases. At least, that's been my impression. Feel free to correct me in the comments section of this blog entry. ;)
Mapping our current situation on to that of supply chain dyanmics does give us a well studied and highly optimized set of solutions that other people have already torn their hair, hearts and souls out over. So I'll be slowly edumecating myself about SCM (no, not that SCM, this SCM), something I'm only mildly versed in at best, and thinking about how to apply it sensibly, if at all possible, to improve our current state of affairs. It could be a dead end, but it could also be a source of inspiration. There's only one way to find out.
I'm devoting brain time to this because it is going to be increasingly critical to get our act together if we want to take on the next level of competition we face in the market without gutting our values and our resources. We have to communicate and coordinate much, much better between the different points in our software supply chain and get our roles correctly aligned with each other. Right now it's very ad-hoc and the network of people has grown beyond that which is sustainable based on a who-knows-who game masquerading as personal relationships.
I hope to meet with several of our partners at the Gran Canaria Desktop Summit in mid-2009 to discuss these things directly, and to have brought myself up to speed enough on the issues to be able to formulate and deploye systematic support solutions. If you have a great SCM book you think I should be reading in the next couple months, please comment below. I'm also wondering how I might gain access to the Supply Chain Council's full SCOR reference manual.
In particular, the "distribution backporting" issue has really gotten out of hand. It's no longer just individual unbaked features that are being backported and shipped with stable KDE releases, but now entire applications are being pulled from pre-beta SVN and shipped with stable KDE releases. I know of two different applications this has now happened to.
Just as disturbing, some downtreams feel that they have the right to speak for us as an upstream to their communities and have, by doing so, misled people and abused KDE's relationship with users in doing so.
Of course, I'm still reeling from the issues Plasma has run into all across the X.org and Qt map. Features those projects have advertised, in some cases for years, simply were not mature or tested until we showed up and found out the hard way by running headlong into pointy skewers of buggy or simply featureless code bases which got that way due to not having real world applications at the ready to tease them into shape.
The losers in this are all around: users get sub-par product, KDE's relationships are damaged both with users and downstreams, upstreams look incompetent when really they just got caught out unawares and downstreams provide a muddled experience in their delivery phases.
This is not a healthy situation. I hope that's stating the obvious and that we're all in agreement thus far.
Note that I haven't really said anything about who's to blame for this. Take the case of lacking real world applications to test our frameworks with: who is at fault? Should KDE have been there earlier pushing on these areas back when these features were first being trialed? Should those writing these frameworks have ensured there were real world type applications doing meaningful things with their new fangled hotness before claiming stability and maturity? Not easy questions, are they? Personally, I'm not one for fingerpointing unless you really get it obviously wrong after having had a workable solution pointed out to you. We aren't at that point, however, with nearly any of the above.
While tracking these issues and trying to make heads and tails of them, often with great frustration draped across my brow, I have also been looking for analogs elsewhere. Most problems have already been at least identified, and most problems that have been identified have a history of attempted solutions. Just because I haven't had to deal with a particular problem first hand doesn't mean someone else hasn't, and so I've been searching for solutions (good or bad) elsewhere.
In talking with some of our downstreams, I've found it increasingly useful to talk about things in terms of supply chains and the kinds of relationships that end up forming around them. Unlike "traditional" software development where the supply chain is tightly managed and usually completely or nearly completely internal, the open source model seems to me to be a lot more like the free market dynamics seen in commodity markets and how supply trickles on through the machinery to eventually create products the consumer purchases. At least, that's been my impression. Feel free to correct me in the comments section of this blog entry. ;)
Mapping our current situation on to that of supply chain dyanmics does give us a well studied and highly optimized set of solutions that other people have already torn their hair, hearts and souls out over. So I'll be slowly edumecating myself about SCM (no, not that SCM, this SCM), something I'm only mildly versed in at best, and thinking about how to apply it sensibly, if at all possible, to improve our current state of affairs. It could be a dead end, but it could also be a source of inspiration. There's only one way to find out.
I'm devoting brain time to this because it is going to be increasingly critical to get our act together if we want to take on the next level of competition we face in the market without gutting our values and our resources. We have to communicate and coordinate much, much better between the different points in our software supply chain and get our roles correctly aligned with each other. Right now it's very ad-hoc and the network of people has grown beyond that which is sustainable based on a who-knows-who game masquerading as personal relationships.
I hope to meet with several of our partners at the Gran Canaria Desktop Summit in mid-2009 to discuss these things directly, and to have brought myself up to speed enough on the issues to be able to formulate and deploye systematic support solutions. If you have a great SCM book you think I should be reading in the next couple months, please comment below. I'm also wondering how I might gain access to the Supply Chain Council's full SCOR reference manual.
Sunday, November 23, 2008
KDE Video Cast, Episode 2: Torrent it!
I got up early this morning so I could luxuriate in a hot shower, get dressed and go over my notes before the video cast this morning. It was an hour earlier and the second episode, so live attendance was down a fair amount: it peaked at "only" 194, which was 27 fewer than last week. I expected a spike on the first week (curiosity) and I knew shifting the time by an hour would suck as well. Oh well =)
I did, however, manage to figure out how to put text messages on the stream as well as videos hosted on Youtube. Unfortunately, these only show during the live broadcast and are not part of the resulting recorded version. I put a link to the show notes on the screen during the live broadcast thinking that would help people downloading it later, but ... fail. Additionally, UStream dropped out twice. My internet connection was fine (I was still in the chats), the server side just thunked out twice in a few minute span.
On the plus side the audio was better, I used a solid color backdrop, and the downloaded version is in mpeg format this week instead of flv's that won't work for anyone. Also included in the torrent are the show notes and the media I reference in the show, including a short Kopete screencast and a couple of JavaScript Plasmoids.
I am learning exactly what I want from a DIY broadcast software and am becoming increasingly tempted to see what Solid+Phonon in KDE 4.3 are capable of doing for me. For now, I just learn the quirks of what's available and soldier on improving each episode incrementally.
You can grab the torrent here and enjoy it at your leisure. Cheers! =)
I did, however, manage to figure out how to put text messages on the stream as well as videos hosted on Youtube. Unfortunately, these only show during the live broadcast and are not part of the resulting recorded version. I put a link to the show notes on the screen during the live broadcast thinking that would help people downloading it later, but ... fail. Additionally, UStream dropped out twice. My internet connection was fine (I was still in the chats), the server side just thunked out twice in a few minute span.
On the plus side the audio was better, I used a solid color backdrop, and the downloaded version is in mpeg format this week instead of flv's that won't work for anyone. Also included in the torrent are the show notes and the media I reference in the show, including a short Kopete screencast and a couple of JavaScript Plasmoids.
I am learning exactly what I want from a DIY broadcast software and am becoming increasingly tempted to see what Solid+Phonon in KDE 4.3 are capable of doing for me. For now, I just learn the quirks of what's available and soldier on improving each episode incrementally.
You can grab the torrent here and enjoy it at your leisure. Cheers! =)
Friday, November 21, 2008
Video Cast Episode 2, Nov 22nd!
This week's show will be one hour earlier than the usual schedule calls for: we'll be going live at 16:00 UTC on Saturday, November 22nd over at UStream.
This week's show will look like this:
An ogv will be available via bittorrent after the show so you can download it for offline viewing, in addition to the usual online clip at UStream.
As for why the bump up by an hour this week: There is a winter fair at the P-man's school on Saturday, and we'll be there for much of day. So I'll be broadcasting at 16:00 UTC instead. Apologies for the inconvenience, I hope you can still make it! We'll be back to the regular time next week.
Update: Due topopular demand metelliuscode's suggestion in the comments section, if you can't make the live broadcast for the Town Hall section but have a burning question to ask, leave it in the comments section of this blog entry and I'll pick one or two of the better ones to address during the Town Hall.
This week's show will look like this:
- Hello, viewers!
- Week in review: KOffice beta, Amarok release candidate, bugs.kde.org improves and developer activity recap.
- The Headline: Entrepreneurial opportunities and the Free Software desktop: where is all the diversity?
- Feature of the Week: New MSN bling and graceful interfaces in Kopete
- Town Hall: Bring your questions to #aseigo on irc.freenode.net! I'll have my sack of answers at the ready.
- Developer Corner: Writing a Plasmoid in JavaScript.
An ogv will be available via bittorrent after the show so you can download it for offline viewing, in addition to the usual online clip at UStream.
As for why the bump up by an hour this week: There is a winter fair at the P-man's school on Saturday, and we'll be there for much of day. So I'll be broadcasting at 16:00 UTC instead. Apologies for the inconvenience, I hope you can still make it! We'll be back to the regular time next week.
Update: Due to
Thursday, November 20, 2008
plasma systray, 4.2
So I've talked abut the system tray in 4.2 a few times recently, though mostly in passing. Today we hit a new milestone which marks the system tray area being feature complete for 4.2 (though not defect free .. yet!):
The white arrow on the edge is the expander: click on it and hidden icons show up. If you have no hidden system tray icons then the expander isn't shown.
You can see a progress meter for a file copy in there as well. Application jobs stack up there, as do system notifications. They automatically hide within reasonable times, are fully themable, support user interaction (such as pause, stop, resume, open, etc. buttons) and, since they are Extenders, can be detached and put elsewhere. This isn't limited to file operations, however: any application job can use this and in fact gets support for this for free when using KJob from libkdecore. Yes, that means even apps without a GUI can show their job progress in the system tray area! Possible uses? How about print progress, or K3B's burning status, or..?
The last icon on the right is pretty interesting as well. It means "you have some application jobs on the go or some system notifications available". Clicking on it hides or shows the list of jobs and notifications. We're using a generic computer or laptop icon (depending on whether it's a laptop or not) but still, we ought to have some more specific art done up for this use case. So it's a useful bit there: you can click it to hide long-running jobs so they don't endlessly bug you on the screen, and click it to get them back easily. But that's not the really interesting part. That icon is doing two pretty neat things in particular:
First, it's saying "put me at the end of the list, because I'm a special kind of entry". This marks the start of us starting to make the system tray experience richer, and we will eventually extend this kind of expressiveness to all KDE 4 system tray using applications.
Second, it's not "really" a system tray icon. At least not in the freedesktop.org sense. The system tray Plasmoid doesn't care though. It just sees it as another entry to manage like all the rest. Well, it can do a slightly better job with it because it's a native QGraphicsWidget, but it doesn't really know that either. It's more of a nice side effect of not using XEmbed in this case, but a set of D-Bus protocols instead: one for jobs and one for notifications. And yes, we've talked on the XDG list about both these systems for adoption as freedesktop.org specifications; the notifications one is based on the galago spec minus some "curiosities".
Now imagine if all the system tray icons were done similarly: not with XEmbed but over D-Bus. We wouldn't have to rewrite any part of the new system tray Plasmoid for that to work, we'd just add another SystemTray::Protocol to it and away it would go, happy as a clam. That is, in fact, precisely what we intend to do after KDE 4.2 is out.
This shows one of the strengths of Plasma that is born out of the purposeful design rules the entire team keeps in mind when we work on things: we write things to not be rewritten again in the future. We don't write really complicated stuff (that's how we can achieve such rapid growth in the number of components while not simultaneously exploding with instability), we just write things that are reasonably flexible. This prevents the "just tack on another room to the side of house" syndrome. We could have done something pretty similar with the D-Bus transition with the KDE3 system tray, but it would have been adding something to it that it wasn't written in mind for from the start. That way leads to head-meets-table-at-rapid-speed events, and having had enough of those already in my life, I try to help make sure we avoid more of them in the future.
What's really impressive is that the rest of the team Gets It(tm). As with many things in Plasma, the system tray was truly a team effort. Rob worked on the jobs integration, Dmitry worked on the notifications integration, Jason worked on the core design for the Plasmoid and took care of the X11 magic, I did the show/hide of hidden icons and lot of polishing work and Marco touched it with his usual graceful polishing wand here and there. I'm probably missing someone, too, as usual. =P
It is one of the bigger widgets, though, in terms of code. The Plasmoid itself is a little over 3,700 LOC and two DataEngines (reusable by others, of course =) were written for it: applicationjobs (336 LOC) and notifications (200 LOC). The freedesktop.org protocol implementation accounts for 1,105 lines of the widget. That's nearly twice the amount of code for the other three protocols combined (jobs, notifications and Plasmoids) and far, far more than twice as complex. The UI parts are are also pretty complex, though, given what it has to do and what it's meant to do in the future and currently weighs in at a hefty 1,294 lines. The core classes representing the concepts of Tasks and Protocols is the other 700 or so lines.
And there, in a nutshell, is more than you ever wanted to know about the new system tray Plasmoid.
The white arrow on the edge is the expander: click on it and hidden icons show up. If you have no hidden system tray icons then the expander isn't shown.
You can see a progress meter for a file copy in there as well. Application jobs stack up there, as do system notifications. They automatically hide within reasonable times, are fully themable, support user interaction (such as pause, stop, resume, open, etc. buttons) and, since they are Extenders, can be detached and put elsewhere. This isn't limited to file operations, however: any application job can use this and in fact gets support for this for free when using KJob from libkdecore. Yes, that means even apps without a GUI can show their job progress in the system tray area! Possible uses? How about print progress, or K3B's burning status, or..?
The last icon on the right is pretty interesting as well. It means "you have some application jobs on the go or some system notifications available". Clicking on it hides or shows the list of jobs and notifications. We're using a generic computer or laptop icon (depending on whether it's a laptop or not) but still, we ought to have some more specific art done up for this use case. So it's a useful bit there: you can click it to hide long-running jobs so they don't endlessly bug you on the screen, and click it to get them back easily. But that's not the really interesting part. That icon is doing two pretty neat things in particular:
First, it's saying "put me at the end of the list, because I'm a special kind of entry". This marks the start of us starting to make the system tray experience richer, and we will eventually extend this kind of expressiveness to all KDE 4 system tray using applications.
Second, it's not "really" a system tray icon. At least not in the freedesktop.org sense. The system tray Plasmoid doesn't care though. It just sees it as another entry to manage like all the rest. Well, it can do a slightly better job with it because it's a native QGraphicsWidget, but it doesn't really know that either. It's more of a nice side effect of not using XEmbed in this case, but a set of D-Bus protocols instead: one for jobs and one for notifications. And yes, we've talked on the XDG list about both these systems for adoption as freedesktop.org specifications; the notifications one is based on the galago spec minus some "curiosities".
Now imagine if all the system tray icons were done similarly: not with XEmbed but over D-Bus. We wouldn't have to rewrite any part of the new system tray Plasmoid for that to work, we'd just add another SystemTray::Protocol to it and away it would go, happy as a clam. That is, in fact, precisely what we intend to do after KDE 4.2 is out.
This shows one of the strengths of Plasma that is born out of the purposeful design rules the entire team keeps in mind when we work on things: we write things to not be rewritten again in the future. We don't write really complicated stuff (that's how we can achieve such rapid growth in the number of components while not simultaneously exploding with instability), we just write things that are reasonably flexible. This prevents the "just tack on another room to the side of house" syndrome. We could have done something pretty similar with the D-Bus transition with the KDE3 system tray, but it would have been adding something to it that it wasn't written in mind for from the start. That way leads to head-meets-table-at-rapid-speed events, and having had enough of those already in my life, I try to help make sure we avoid more of them in the future.
What's really impressive is that the rest of the team Gets It(tm). As with many things in Plasma, the system tray was truly a team effort. Rob worked on the jobs integration, Dmitry worked on the notifications integration, Jason worked on the core design for the Plasmoid and took care of the X11 magic, I did the show/hide of hidden icons and lot of polishing work and Marco touched it with his usual graceful polishing wand here and there. I'm probably missing someone, too, as usual. =P
It is one of the bigger widgets, though, in terms of code. The Plasmoid itself is a little over 3,700 LOC and two DataEngines (reusable by others, of course =) were written for it: applicationjobs (336 LOC) and notifications (200 LOC). The freedesktop.org protocol implementation accounts for 1,105 lines of the widget. That's nearly twice the amount of code for the other three protocols combined (jobs, notifications and Plasmoids) and far, far more than twice as complex. The UI parts are are also pretty complex, though, given what it has to do and what it's meant to do in the future and currently weighs in at a hefty 1,294 lines. The core classes representing the concepts of Tasks and Protocols is the other 700 or so lines.
And there, in a nutshell, is more than you ever wanted to know about the new system tray Plasmoid.
Wednesday, November 19, 2008
.. and speaking of bugs
Speaking of bugs (in my last blog entry), we (the Plasma team) have a goal to have no more than 200 defect reports open for Plasma and its components when 4.2.0 hits. We're currently surfing at ~110,000 lines of code, with a ton of that being new in 4.2; that means a goal of approximately one report per 500 lines.
Update: I just realized I missed counting KRunner, libplasmaclock and libtaskmanager, which adds another 6,096 LOC to the total, bringing us close to the 120KLOC mark. If we added KRunner to it, we're at ~122KLOC; but that's a separate component when counting these bugs.
Another metric might be components: by my count we are shipping 100 plugins (I may have missed some, so it's at least 100), three libraries (libplasma in kdelibs; libtaskmanaer and libplasmaclock in workspace) and six apps (plasma desktop shell, plasma on screensaver, plasmapkg, the desktop theme customizer/creator, the data engine explorer and the plasmoid viewer). That's 109 discrete components meaning we're aiming for less than two reports per component, and some of those components are bigger than small.
We started at a dizzying 450+ reports about a week ago, but through careful triage and lots of commits we're already down to 294. There will be a flood of new reports with the betas that are about to come out and the bugs will get progressively more difficult to fix as we pick off the low-hanging fruit and get left with more NMBs (Nasty Monster Bugs).
The Plasma team seems to both value making things as high quality as we can given the various constraints we live within and enjoy destroying the beasties with a rather lovably mad passion. This makes me confident that we'll make our goal.
Now that we're into the feature freeze period, it's probably an idea for the KDE sub-projects to set themselves release goals. Whether it's bug counts, artwork finesse, performance benchmarks or whatever, goals can't hurt. If you do set such goals for your project, be sure to make them reasonable and clearly described to everyone on the team. This ensures that the goal will be shared and has a tangible end point that people can strive for. When the goal is met, everyone can enjoy the feeling of triumph. This is where team leadership is very useful, as an email to a list with a positive tone and a realistic set of metrics contained within can really help rev things up without burning people out in the process. =)
This is probably nothing new to most KDE (and coding) veterans, but I thought I'd mention it anyways. Happyhacking bug hunting ..
Update: I just realized I missed counting KRunner, libplasmaclock and libtaskmanager, which adds another 6,096 LOC to the total, bringing us close to the 120KLOC mark. If we added KRunner to it, we're at ~122KLOC; but that's a separate component when counting these bugs.
Another metric might be components: by my count we are shipping 100 plugins (I may have missed some, so it's at least 100), three libraries (libplasma in kdelibs; libtaskmanaer and libplasmaclock in workspace) and six apps (plasma desktop shell, plasma on screensaver, plasmapkg, the desktop theme customizer/creator, the data engine explorer and the plasmoid viewer). That's 109 discrete components meaning we're aiming for less than two reports per component, and some of those components are bigger than small.
We started at a dizzying 450+ reports about a week ago, but through careful triage and lots of commits we're already down to 294. There will be a flood of new reports with the betas that are about to come out and the bugs will get progressively more difficult to fix as we pick off the low-hanging fruit and get left with more NMBs (Nasty Monster Bugs).
The Plasma team seems to both value making things as high quality as we can given the various constraints we live within and enjoy destroying the beasties with a rather lovably mad passion. This makes me confident that we'll make our goal.
Now that we're into the feature freeze period, it's probably an idea for the KDE sub-projects to set themselves release goals. Whether it's bug counts, artwork finesse, performance benchmarks or whatever, goals can't hurt. If you do set such goals for your project, be sure to make them reasonable and clearly described to everyone on the team. This ensures that the goal will be shared and has a tangible end point that people can strive for. When the goal is met, everyone can enjoy the feeling of triumph. This is where team leadership is very useful, as an email to a list with a positive tone and a realistic set of metrics contained within can really help rev things up without burning people out in the process. =)
This is probably nothing new to most KDE (and coding) veterans, but I thought I'd mention it anyways. Happy
paddling upstream
Matt Rogers recently added UPSTREAM as a report resolution type on bugs.kde.org for us. I asked for this because a lot of issues in Plasma were the result of bugs elsewhere in the stack and I hated closing those reports as INVALID since they were not INVALID at all: they just weren't something we could do anything about in the Plasma code base.
Technically not all the bugs we close are really UPSTREAM, though. Some are DOWNSTREAM, namely the bugs caused by packaging foobars or poor backporting decision making and/or execution by OSVs (operating system vendors, aka "distributions" in the Linux realm). However, since we don't have DOWNSTREAM as an option we mark them all as UPSTREAM, noting where in the stack the problem really is in the comments section.
We've only had the UPSTREAM designation for a couple weeks now and already we've closed 19 reports in Plasma as such. That's probably about 10% of reports, which may sound high (and, well, it is) but it's actually a lot lower than it was.
First off, OSVs are actually getting better at packaging Plasma which is leading to fewer problems there. We're also making it easier on them by having fewer interesting Plasmoids in playground and keeping binary compatibility in libplasma while having a symbols check on plugin load (thanks to an upstream, actually; namely Dirk @ OpenSuse). I expect to see an uptick in this category, though, as we're already seeing reports coming in from packages being pushed out with half-baked backports.
Second contributing factor is that the graphics driver issues are actually getting sorted out bit by bit. The newest NVidia driver, for instance, actually works across the board with Plasma. Performance is great (even across multiple screens, apparently) and no artifacts to be seen. They aren't the only ones working successfully through issues, either, and so this area of UPSTREAM bugs is slowly but surefly declining.
Third, bugs in Qt are getting hammered out and fixed. Alexis Menard, who was a student of Kevin Ottens (explaining how he got involved with KDE in the first place =) and a Plasma hacker for the last year and a half or so is now working at Qt Software in Oslo and doing a great job of triaging issues Plasma reveals in QGraphicsView and elsewhere. So that source of UPSTREAM should also be diminishing in the coming months.
As much as it's fun to go "hey, that bug's not our fault! *CLOSE*" it really pains me to mark things as UPSTREAM because it means our software suffers due to bugs in other people's code that I don't work on and therefore have a limited ability to affect positive change in. Working around other people's bugs is sometimes possible .. but a matter of last resort, and completely off the table when it results in a worsened user experience.
For the last year we've really taken it in the proverbial ass over UPSTREAM issues, but it seems that the clouds are finally parting and the sun is shining through. 2009 may actually be a year in which the overwhelming majority of bugs filed against Plasma are actually our own screw ups. =)
Technically not all the bugs we close are really UPSTREAM, though. Some are DOWNSTREAM, namely the bugs caused by packaging foobars or poor backporting decision making and/or execution by OSVs (operating system vendors, aka "distributions" in the Linux realm). However, since we don't have DOWNSTREAM as an option we mark them all as UPSTREAM, noting where in the stack the problem really is in the comments section.
We've only had the UPSTREAM designation for a couple weeks now and already we've closed 19 reports in Plasma as such. That's probably about 10% of reports, which may sound high (and, well, it is) but it's actually a lot lower than it was.
First off, OSVs are actually getting better at packaging Plasma which is leading to fewer problems there. We're also making it easier on them by having fewer interesting Plasmoids in playground and keeping binary compatibility in libplasma while having a symbols check on plugin load (thanks to an upstream, actually; namely Dirk @ OpenSuse). I expect to see an uptick in this category, though, as we're already seeing reports coming in from packages being pushed out with half-baked backports.
Second contributing factor is that the graphics driver issues are actually getting sorted out bit by bit. The newest NVidia driver, for instance, actually works across the board with Plasma. Performance is great (even across multiple screens, apparently) and no artifacts to be seen. They aren't the only ones working successfully through issues, either, and so this area of UPSTREAM bugs is slowly but surefly declining.
Third, bugs in Qt are getting hammered out and fixed. Alexis Menard, who was a student of Kevin Ottens (explaining how he got involved with KDE in the first place =) and a Plasma hacker for the last year and a half or so is now working at Qt Software in Oslo and doing a great job of triaging issues Plasma reveals in QGraphicsView and elsewhere. So that source of UPSTREAM should also be diminishing in the coming months.
As much as it's fun to go "hey, that bug's not our fault! *CLOSE*" it really pains me to mark things as UPSTREAM because it means our software suffers due to bugs in other people's code that I don't work on and therefore have a limited ability to affect positive change in. Working around other people's bugs is sometimes possible .. but a matter of last resort, and completely off the table when it results in a worsened user experience.
For the last year we've really taken it in the proverbial ass over UPSTREAM issues, but it seems that the clouds are finally parting and the sun is shining through. 2009 may actually be a year in which the overwhelming majority of bugs filed against Plasma are actually our own screw ups. =)
Tuesday, November 18, 2008
harvest comes after the seed is planted
Opening new markets, forging new friendships and strengthening existing relationships is an ongoing challenge. It requires a consistent effort over time and rarely shows imediate results. Done with honesty, openness, fairness and perseverance it does pay off.
In that way, it's not unlike planting a vegetable garden. After fertilizing and tilling the soil (often after last year's harvest to allow it to sit and take and then again before planting), you put seeds and newly sprouted plants in the soil at the start of the growing season. You tend to the land for months watering and weeding and chasing out pests and generally maintaining the plants themselves. Finally the plants start to produce things we can eat and the joy of the harvest continues. Done right, even a reasonably sized plot can provide a family with food not just through the harvest months but through the winter as well ... when you get to start the process over again.
For those living in warmer climes where the growing season is year-round, it's even more practical to just till and till through the year. Making such a "tropical climate" is every organization's goal when it comes to relationship development, though reality is that not everyone gets to live in the tropics. =)
Harvest festivals are common throughout the world because it gives a well needed "Huzzah!" to the end of a long stretch of work that is done for future gain. It reminds the people that their hard work did pay off, that they should continue planting to make food and that they should be grateful for the bounty they receive.
Ok .. where am I going with all this? Well, a couple years ago at Akademy 2006 in Ireland we put together a speaking track and arranged meetings around the topic of KDE and FOSS in Asia. The soil was being tilled and fertilized.
People came from China, Korea, India and beyond representing both community and companies. We met, we talked, we forged relationships, we exchanged business cards and email addresses. Seeds were being planted. It was the first time I'd personally been able to meet with several of them, including people from Red Flag. We talked about how to draw people from cultures rather different in terms of computer usage, social norms and communication patterns closer to the KDE upstream community. Everyone agreed that working together more would benefit us all, and that simple things like having people send patches upstream would be great.
Red Flag people sent a raft of patches directly after Akademy 2006, but as usual with large patch drops some were already done upstream, some no longer applied cleanly, some were incorrect ... a couple made it through though and that was an interesting first step. Seedlings poked their first leaves through the soil.
Over the next two years, people on the Asian continent continued to work on the communities, such as the awesome KDE India community while others continued to work hard even on their own. When Sung-Jae joined KDE e.V. as a member this year and expressed with great heartfelt emotion his efforts and struggles for FOSS in his country of Korea, it was very evident how hard he'd been working on the KDE garden plot at his home. ASUS hosted a couple of Linux developer events and KDE people flew to Taiwan to participate.
Then about a week ago I noticed something: I was seeing patches for KDE 4 posted to mailing lists from Red Flag employees (plural!) using their work email addresses. Besides signaling that they were working on a KDE 4 based release of their operating systems and preparing the move from 3.5 to 4.2, this was new: they were working on sending their patches upstream as they were working on them.
Yesterday, a Red Flag developer got his KDE svn commit account. This told me that finally we were in the harvest time. The seeds planted in 2006 had sprouted, bloomed and were producing fruit.
I hope this is just the first such harvest and that we continue to build strong bonds with those in Asia. This has been a huge challenge for us, being largely Amero-European, due to the differences in culture and language. Both sides have been learning and growing in the process, but I am thankful everyone has stuck with it through the growing season.
I don't think it's unreasonable to suggest that those involved take a moment to step back and appreciate the progress we've all made in Asia over the last 2 years with a bit of a harvest celebration, so to speak.
After all, a new growing season is upon us and we'll need to sow new seeds, expand our garden plot a bit further and look forward to our growing harvest in the next year.
In that way, it's not unlike planting a vegetable garden. After fertilizing and tilling the soil (often after last year's harvest to allow it to sit and take and then again before planting), you put seeds and newly sprouted plants in the soil at the start of the growing season. You tend to the land for months watering and weeding and chasing out pests and generally maintaining the plants themselves. Finally the plants start to produce things we can eat and the joy of the harvest continues. Done right, even a reasonably sized plot can provide a family with food not just through the harvest months but through the winter as well ... when you get to start the process over again.
For those living in warmer climes where the growing season is year-round, it's even more practical to just till and till through the year. Making such a "tropical climate" is every organization's goal when it comes to relationship development, though reality is that not everyone gets to live in the tropics. =)
Harvest festivals are common throughout the world because it gives a well needed "Huzzah!" to the end of a long stretch of work that is done for future gain. It reminds the people that their hard work did pay off, that they should continue planting to make food and that they should be grateful for the bounty they receive.
Ok .. where am I going with all this? Well, a couple years ago at Akademy 2006 in Ireland we put together a speaking track and arranged meetings around the topic of KDE and FOSS in Asia. The soil was being tilled and fertilized.
People came from China, Korea, India and beyond representing both community and companies. We met, we talked, we forged relationships, we exchanged business cards and email addresses. Seeds were being planted. It was the first time I'd personally been able to meet with several of them, including people from Red Flag. We talked about how to draw people from cultures rather different in terms of computer usage, social norms and communication patterns closer to the KDE upstream community. Everyone agreed that working together more would benefit us all, and that simple things like having people send patches upstream would be great.
Red Flag people sent a raft of patches directly after Akademy 2006, but as usual with large patch drops some were already done upstream, some no longer applied cleanly, some were incorrect ... a couple made it through though and that was an interesting first step. Seedlings poked their first leaves through the soil.
Over the next two years, people on the Asian continent continued to work on the communities, such as the awesome KDE India community while others continued to work hard even on their own. When Sung-Jae joined KDE e.V. as a member this year and expressed with great heartfelt emotion his efforts and struggles for FOSS in his country of Korea, it was very evident how hard he'd been working on the KDE garden plot at his home. ASUS hosted a couple of Linux developer events and KDE people flew to Taiwan to participate.
Then about a week ago I noticed something: I was seeing patches for KDE 4 posted to mailing lists from Red Flag employees (plural!) using their work email addresses. Besides signaling that they were working on a KDE 4 based release of their operating systems and preparing the move from 3.5 to 4.2, this was new: they were working on sending their patches upstream as they were working on them.
Yesterday, a Red Flag developer got his KDE svn commit account. This told me that finally we were in the harvest time. The seeds planted in 2006 had sprouted, bloomed and were producing fruit.
I hope this is just the first such harvest and that we continue to build strong bonds with those in Asia. This has been a huge challenge for us, being largely Amero-European, due to the differences in culture and language. Both sides have been learning and growing in the process, but I am thankful everyone has stuck with it through the growing season.
I don't think it's unreasonable to suggest that those involved take a moment to step back and appreciate the progress we've all made in Asia over the last 2 years with a bit of a harvest celebration, so to speak.
After all, a new growing season is upon us and we'll need to sow new seeds, expand our garden plot a bit further and look forward to our growing harvest in the next year.
Monday, November 17, 2008
24
The last twenty-four hours have been packed.
The P-man and I went over to a friend's last night where he, three others and I sat on a covered and semi-enclosed deck with a propane heater that hums not unlike a brass instrument in a symphony during the pre-show warm up when you light it. We talked about our week and what we'd each done and played music on guitars while others sang along. Winner of the harrowing tale of the night category went to E who had to change his number after a girl he picked up at a wedding went psychotic on him and started endlessly stalking him and telling him untruths like "I'm pregnant.." holy restraining-order-in-the-making. E also took some great pics, which I hope to have soon as well.
We got home and I was in bed by 1 or 2 or so, and I proceeded to sleep in until noon. I love sleeping through the morning. I've been able to sleep in at least a bit pretty much all week as P hasn't had school this week. He's back tomorrow though, so my sleep hours diminish back to the usual.
When I got up P was playing a video game and I suggested we make pancakes. I got out a recipe and all the ingredients and P made the batter while I washed the last night's dishes. I cooked them in a frying pan to a nice golden hue and we ate them with maple syrup.
I cleaned up the house a bit, had a shower and then hit the email. About an hour later I came across the request by the PolicyKit-kde developers to sneak their code in without going through kdereview. The release team reps were against breaking the norms, Kevin was against anything related to a framework going in so late and Lubos wasn't impressed because about a month ago it wasn't working at all. PolicyKit-kde is two small apps that give the user a GUI to interact with PolicyKit, which is used to do things that require special user priveleges in a way that allows a great amount of sys admin control. Think of it as a sudo for GUIs that uses D-Bus.
The fellow who designed and wrote a lot of it is a GNOME developer, but he designed it to be desktop agnostic. I take my hat of to David Zeuthen for that, but we in KDE haven't really taken advantage of that feature. So anytime you want to use PolicyKit and it requires user interaction via a GUI ... you need more than just KDE around. For desktop basics like this, there's really no excuse, especially since PackageKit-kde is only about 1400 lines of code. Due to this, and that it apparently works decently now, I'm hoping it will go into 4.2. This will also allow KDE app developers to more comfortable start working on PolicyKit integration where it makes sense (e.g. in System Settings).
If it doesn't make it into 4.2 it will be in 4.3, but please make sure that your distro packages it with their KDE build before then! I went over the code a bit myself today and wrote up a lengthy summary email about the matter to kde-core-devel. It's in the hands of the release team now.
After that I made dinner and the P-man and I tucked into a simple pasta and salad affair. Hunger once again addressed, I folded a load of laundry and put P into a bath so he'd be clean and fresh for school in the morning. As he soaked and played, I worked on adding per-virtual-desktop-views for Plasma.
I committed the feature to svn just a while ago and it does work. There are some quirks and some issues it highlights, but nothing bigger than what we've worked through before so I'm not overly worried. It will be an experimental feature in 4.2, which means no GUI. If you want to try it out, put perVirtualDesktopViews=true in your plasmarc in the [General] section. I'm not overly interested in bug reports at this time on it, however. I have other issues to fry.
For instance, I rearranged how screen addition, removal and changes are managed inside the Plasma desktop shell. We now have Kephal for that which should address many of the issues we were having by relying only on QDesktopWidget and how xrandr 1.2 loves to be useless for a desktop application. Kephal provides a rather decent API for managing screens and promises to bring sanity to it all. Both KWin and Plasma will be using it in 4.2.
I also want to attack some zooming issues in the next two months to make it more streamlined and easier to use. There are also some quirks with the new drag-and-place-where-you-want-it cashew.
So, lots to do. =)
But tonight I'm done. It's half past 11 and I just finished folding the second, and thankfully last, load of laundry for the night. The alarm is set for 06:45, so I should be heading to bed within the next hour or two. First, however, I thought I'd blog .. and then I'm going to call a good friend and talk for a while. =)
The P-man and I went over to a friend's last night where he, three others and I sat on a covered and semi-enclosed deck with a propane heater that hums not unlike a brass instrument in a symphony during the pre-show warm up when you light it. We talked about our week and what we'd each done and played music on guitars while others sang along. Winner of the harrowing tale of the night category went to E who had to change his number after a girl he picked up at a wedding went psychotic on him and started endlessly stalking him and telling him untruths like "I'm pregnant.." holy restraining-order-in-the-making. E also took some great pics, which I hope to have soon as well.
We got home and I was in bed by 1 or 2 or so, and I proceeded to sleep in until noon. I love sleeping through the morning. I've been able to sleep in at least a bit pretty much all week as P hasn't had school this week. He's back tomorrow though, so my sleep hours diminish back to the usual.
When I got up P was playing a video game and I suggested we make pancakes. I got out a recipe and all the ingredients and P made the batter while I washed the last night's dishes. I cooked them in a frying pan to a nice golden hue and we ate them with maple syrup.
I cleaned up the house a bit, had a shower and then hit the email. About an hour later I came across the request by the PolicyKit-kde developers to sneak their code in without going through kdereview. The release team reps were against breaking the norms, Kevin was against anything related to a framework going in so late and Lubos wasn't impressed because about a month ago it wasn't working at all. PolicyKit-kde is two small apps that give the user a GUI to interact with PolicyKit, which is used to do things that require special user priveleges in a way that allows a great amount of sys admin control. Think of it as a sudo for GUIs that uses D-Bus.
The fellow who designed and wrote a lot of it is a GNOME developer, but he designed it to be desktop agnostic. I take my hat of to David Zeuthen for that, but we in KDE haven't really taken advantage of that feature. So anytime you want to use PolicyKit and it requires user interaction via a GUI ... you need more than just KDE around. For desktop basics like this, there's really no excuse, especially since PackageKit-kde is only about 1400 lines of code. Due to this, and that it apparently works decently now, I'm hoping it will go into 4.2. This will also allow KDE app developers to more comfortable start working on PolicyKit integration where it makes sense (e.g. in System Settings).
If it doesn't make it into 4.2 it will be in 4.3, but please make sure that your distro packages it with their KDE build before then! I went over the code a bit myself today and wrote up a lengthy summary email about the matter to kde-core-devel. It's in the hands of the release team now.
After that I made dinner and the P-man and I tucked into a simple pasta and salad affair. Hunger once again addressed, I folded a load of laundry and put P into a bath so he'd be clean and fresh for school in the morning. As he soaked and played, I worked on adding per-virtual-desktop-views for Plasma.
I committed the feature to svn just a while ago and it does work. There are some quirks and some issues it highlights, but nothing bigger than what we've worked through before so I'm not overly worried. It will be an experimental feature in 4.2, which means no GUI. If you want to try it out, put perVirtualDesktopViews=true in your plasmarc in the [General] section. I'm not overly interested in bug reports at this time on it, however. I have other issues to fry.
For instance, I rearranged how screen addition, removal and changes are managed inside the Plasma desktop shell. We now have Kephal for that which should address many of the issues we were having by relying only on QDesktopWidget and how xrandr 1.2 loves to be useless for a desktop application. Kephal provides a rather decent API for managing screens and promises to bring sanity to it all. Both KWin and Plasma will be using it in 4.2.
I also want to attack some zooming issues in the next two months to make it more streamlined and easier to use. There are also some quirks with the new drag-and-place-where-you-want-it cashew.
So, lots to do. =)
But tonight I'm done. It's half past 11 and I just finished folding the second, and thankfully last, load of laundry for the night. The alarm is set for 06:45, so I should be heading to bed within the next hour or two. First, however, I thought I'd blog .. and then I'm going to call a good friend and talk for a while. =)
Saturday, November 15, 2008
i took my curtain call
Despite the horrible audio clipping at the start and occasional clipping throughout (it decided to not see my USB mic for some reason today and nothing i did could convince it otherwise), the "hey, it's my living room!" recording lair and it being the first hour long show I've done ("Dammit, look into the camera!!!") ... show one is in the can. We peaked at 225 viewers during the live recording, and we'll see how many people watch it over the coming week.
You can watch it (and future episodes) here on my "Seigo on KDE" channel; you need to scroll down to the Video Clips section to watch the recorded show. The show notes that accompany the show are here and include links to the screenshots and other files referenced.
Apologies in advance for all the non-free software .. If there was a good, live-streaming site with a decent interface I'd hop to it in a heartbeat. Maximizing impact while minimizing the impact on my time is critical.
Where are all the FOSS web dev projects? identi.ca is a nice start and Slashdot is the long time standard bearer, but we just don't see many online services that use FOSS frameworks ...
Update: There is now a torrent of the show available, thanks to Serenity on irc.
You can watch it (and future episodes) here on my "Seigo on KDE" channel; you need to scroll down to the Video Clips section to watch the recorded show. The show notes that accompany the show are here and include links to the screenshots and other files referenced.
Apologies in advance for all the non-free software .. If there was a good, live-streaming site with a decent interface I'd hop to it in a heartbeat. Maximizing impact while minimizing the impact on my time is critical.
Where are all the FOSS web dev projects? identi.ca is a nice start and Slashdot is the long time standard bearer, but we just don't see many online services that use FOSS frameworks ...
Update: There is now a torrent of the show available, thanks to Serenity on irc.
Friday, November 14, 2008
my glowing heart .. er .. panel
I was talking with Thomas Zander on irc last night about the Plasma desktop shell and how it's shaping up. I was going on about how happy I am that we're able to ship the thinnest default panel we've been able to thus far in a KDE release: KDE 3 had a 46px default, 4.0 had a 48px default, 4.1 had a more reasonable 38px default ... and 4.2 will have a much slimmer 35px default. Personally I prefer really, really thin panels but for the default we're constrained by things like the size of systemtray icons and making it look nice with them. (I have some thoughts about how we can mitigate this in 4.3 with a variable height panel ... but that's not for 4.2.)
Still, being able to shave 11 pixels off the KDE3 default and 3 more pixels off of 4.1 (which shed a few pounds already) is great. Thomas noted, however, that he has wide panels and hides them. Fair enough, that's one of the beautiful things about autohiding panels.
He noted, however, that Plasma only unhides the panel when you move the mouse in the space the panel actually exists. So, for example, if you have a panel taking up 50% of the right side of the screen and it is vertically centered, the top and bottom quarter of the screen won't untrigger a hide.
Whereas Kicker would just unhide everything on a screen edge when you came in contact with it, Plasma tries to respect people's choice of panel size. I often have a small panel in the top left of my screen for quick launch the handful of apps I use-and-close throughout the day; I really don't need it popping out when my mouse reaches for the left side of a maximized window. So Plasma's size sensitivity is a nice improvement (and it does it without polling the mouse.. woo!).
Thomas said it'd be neat if the panel 'glowed' when off screen. I thought about it for all of about 2 seconds before running off to implement it. It was just too cool of an idea to not do it right now. Excitability: 1, Sleep: 0.
I figured that if I made the input only window Plasma uses to trigger unhiding a bit bigger, say 30 px larger than necessary on all sides, and painted a small glow where the panel was when the mouse entered that input only window ... it would look to the user like the panel "sensed" the mouse was near and announced its existence. This would give Thomas a hint as to where his panel actually was without having to hunt too much: just get near it and then follow the glow. Since input-only windows don't paint to screen nor capture events (unless they go out of their way to do so), this wouldn't otherwise interfere with the user interacting with other windows. It should be completely seamless.
How hard could it be, right?
I had a proof of concept up and running in less than five minutes. I spent another hour or so on various details before going to bed (somewhere around 03:00 *sigh*) and then implemented the painting of the glow today (SVG makes this stuff sooo easy) and committed.
The only caveat is that the glow painting looks horrible without window compositing. So even though all the mechanics work perfectly without composite, there is no glow when there is no window compositor due to aesthetics. If we come up with an aesthetically pleasing solution for the non-composited scenario, turning it on is a matter of deleting a couple lines of code.
So, the end result (other than me losing an hour more sleep last night) is that if you have composite and you have a hidden panel, it will glow as your mouse nears. Think of it as your panel saying, "Oh! Hello! I was wondering when you'd return!" =)
Still, being able to shave 11 pixels off the KDE3 default and 3 more pixels off of 4.1 (which shed a few pounds already) is great. Thomas noted, however, that he has wide panels and hides them. Fair enough, that's one of the beautiful things about autohiding panels.
He noted, however, that Plasma only unhides the panel when you move the mouse in the space the panel actually exists. So, for example, if you have a panel taking up 50% of the right side of the screen and it is vertically centered, the top and bottom quarter of the screen won't untrigger a hide.
Whereas Kicker would just unhide everything on a screen edge when you came in contact with it, Plasma tries to respect people's choice of panel size. I often have a small panel in the top left of my screen for quick launch the handful of apps I use-and-close throughout the day; I really don't need it popping out when my mouse reaches for the left side of a maximized window. So Plasma's size sensitivity is a nice improvement (and it does it without polling the mouse.. woo!).
Thomas said it'd be neat if the panel 'glowed' when off screen. I thought about it for all of about 2 seconds before running off to implement it. It was just too cool of an idea to not do it right now. Excitability: 1, Sleep: 0.
I figured that if I made the input only window Plasma uses to trigger unhiding a bit bigger, say 30 px larger than necessary on all sides, and painted a small glow where the panel was when the mouse entered that input only window ... it would look to the user like the panel "sensed" the mouse was near and announced its existence. This would give Thomas a hint as to where his panel actually was without having to hunt too much: just get near it and then follow the glow. Since input-only windows don't paint to screen nor capture events (unless they go out of their way to do so), this wouldn't otherwise interfere with the user interacting with other windows. It should be completely seamless.
How hard could it be, right?
I had a proof of concept up and running in less than five minutes. I spent another hour or so on various details before going to bed (somewhere around 03:00 *sigh*) and then implemented the painting of the glow today (SVG makes this stuff sooo easy) and committed.
The only caveat is that the glow painting looks horrible without window compositing. So even though all the mechanics work perfectly without composite, there is no glow when there is no window compositor due to aesthetics. If we come up with an aesthetically pleasing solution for the non-composited scenario, turning it on is a matter of deleting a couple lines of code.
So, the end result (other than me losing an hour more sleep last night) is that if you have composite and you have a hidden panel, it will glow as your mouse nears. Think of it as your panel saying, "Oh! Hello! I was wondering when you'd return!" =)
video cast details
The first live videocast hosted by your truly talking will be broadcast via my channel on UStream. It's not a perfect solution as I'm still not sure how to get a screen capture up that isn't canned, and it's a whole lotta non-free software. However, it's what I have available right now, perhaps (hopefully) it will improve as we go along.
It will be live at 17:00 UTC on Saturday the 15th and you can join the irc channel #aseigo on irc.freenode.net around that time to join in the fun.
I promise that it will not be smooth, slick or overly amazing (first runs, especially at something completely new, rarely are) .. but it should be informative, interesting and fun.
The schedule looks like this:
If there are topics you'd like to see covered in future shows, leave them in the comments.
Update: I know I mentioned this previously in blog entries (or comments?) about the video cast, but the show will also be available for viewing after the live show time. So if you can't make it, don't worry ... you can catch it at your leisure later.
It will be live at 17:00 UTC on Saturday the 15th and you can join the irc channel #aseigo on irc.freenode.net around that time to join in the fun.
I promise that it will not be smooth, slick or overly amazing (first runs, especially at something completely new, rarely are) .. but it should be informative, interesting and fun.
The schedule looks like this:
- Introducing the first show
- Week in review: KDE e.V. hires full time administrator, KDE 4.2 enters beta phase, KOffice runs forward.
- The Headline: First show .. big topic! Since 4.2 Beta 1 is just around the corner, I'll be discussing what 4.2 means for KDE, what it means for users and what it means for those building, or wanting to build, products on top of or around KDE.
- Feature of the Week: we'll be looking at the new KMail headers in 4.2, accompanied by screencast and screen shots
- Town Hall: Bring your questions! I'll have my sack of answers at the ready.
- Developer Corner: Using Plasma::Packages for widgets, wallpapers and custom content. This is the first in a series that will go through the creation of a non-C++ Plasma widget.
If there are topics you'd like to see covered in future shows, leave them in the comments.
Update: I know I mentioned this previously in blog entries (or comments?) about the video cast, but the show will also be available for viewing after the live show time. So if you can't make it, don't worry ... you can catch it at your leisure later.
Sunday, November 09, 2008
video cast update, calling all those JavaScripters
Quick update on the video cast thing: I'll be doing the first weekly KDE video cast next Saturday, the 15th, at 17:00 UTC. I'll put up the URL along with topics later in the week, and will invite you all to join us live in the irc channel (whose name I'll also announce closer to the date).
I'm excited!
Also, to all those people who responded to the call for clean-room implementations of Apple Dashboard widgets JavaScript classes: I haven't received updates on all the classes that people had said they were working on, so if you could please send me an update at your convenience so I can know whether to re-assign the class you had claimed to someone else or not. Thanks =)
I'm excited!
Also, to all those people who responded to the call for clean-room implementations of Apple Dashboard widgets JavaScript classes: I haven't received updates on all the classes that people had said they were working on, so if you could please send me an update at your convenience so I can know whether to re-assign the class you had claimed to someone else or not. Thanks =)
milestones
In "Unchained Melody" the crooner sings, "time goes by, so slowly .. and time can do so much." How true. I passed the 1100 posts mark on my blog here recently, which reminded me just how long I've been writing in it. A crazy ride it's been. The last year has been especially crazy, starting with the release of KDE 4.0 and all the fireworks around that through to the recent 4.1.3 release.
I'm looking at what will be 4.2 in a few months time and getting really, really excited about where we are going. It's not just Plasma, either, not by a long shot. For instance, KMail recently got model/view-ified when one of the Google SoC projects was merged. This was a huge step forward for getting KMail ready for Akonadi integration, but it also delivered a ton of visual and functional improvements in all the lists. The functional improvements include new threading and grouping models, message tagging, tabbed folderview (though I think it would make more sense to have tabbed message views?) and manual sorting in the folder listings. As for visuals .. well .. here's my kmail today:
This doesn't really do the new threading or header painting justice, but it gives a small idea.
Konsole's very useful find widget now appears inside the tabs, rather than outside of it, and supports session management. Amarok2 is looking really, really nice; the evolution its been through is impressive, but you really need to see it in action to get a feel for it. The animations and various interaction concepts just don't come through fully in screen shots. Okular's defaults are nicer now and the games continue to improve in look and feel.
KWin's compositing has gotten amazingly slick and smooth (at least with decent drivers; hardware doesn't need to be special, as I use it on a two year old integrated Intel mobile chipset in my laptop) and has simplified the configuration even further. The file dialog and file manager improvements in speed as well as features such as thumbnailing and what not have been consistently impressive as well.
Plasma has gotten more consistent and featureful as well. I especially like the little number beneath the arrow on grouped tasks:
The task bar now groups, does multiple lines and more. The systray allows icons to be hidden, takes care of notifications and lets us put non-tray-icons alongside the freedesktop.org ones. Visual continuity is improved, and we're tweaking the default theme (I'm personally hoping for a non-all-black panel) to make that shine even more. We have tons of new components, tooltips that are pretty and even animated (and which can be turned off globally; though no UI for that yet). New calendars and improved consistency for clocks. A better panel controller for configuration and visual drop areas for drag and drop just like 4.1 had for moving applets. Alternate interface support for KRunner, along with actions-on-matches. New applet handles, meters and other widgets. Improved scripting bindings, support for two new entire widget systems (you can see a screencast of the Google Gadgets on Plasma support here), wallpaper plugins, containment switching, extenders and .. well, just so much more than that even.
The amount of polish (ranging from big things like Kickoff's theming or how it's obviousl what the current or needing-attention windows are to small things like the new glow around the taskbar buttons that subtly fades in/out as you mouse over) and performance improvements (such as delaying wallpaper rendering of non-visible containments or the SVG data cache).
We'll all be polishing and improving many more things between here and 4.2.0's release in late January, but I'm already looking at what we have and thinking to myself, "What a wonderful world." I'm more excited about 4.2's fit and finish than I have been about any KDE release since probably 3.2, which was also a watershed release in terms of stepping up the game.
I'm looking at what will be 4.2 in a few months time and getting really, really excited about where we are going. It's not just Plasma, either, not by a long shot. For instance, KMail recently got model/view-ified when one of the Google SoC projects was merged. This was a huge step forward for getting KMail ready for Akonadi integration, but it also delivered a ton of visual and functional improvements in all the lists. The functional improvements include new threading and grouping models, message tagging, tabbed folderview (though I think it would make more sense to have tabbed message views?) and manual sorting in the folder listings. As for visuals .. well .. here's my kmail today:
This doesn't really do the new threading or header painting justice, but it gives a small idea.
Konsole's very useful find widget now appears inside the tabs, rather than outside of it, and supports session management. Amarok2 is looking really, really nice; the evolution its been through is impressive, but you really need to see it in action to get a feel for it. The animations and various interaction concepts just don't come through fully in screen shots. Okular's defaults are nicer now and the games continue to improve in look and feel.
KWin's compositing has gotten amazingly slick and smooth (at least with decent drivers; hardware doesn't need to be special, as I use it on a two year old integrated Intel mobile chipset in my laptop) and has simplified the configuration even further. The file dialog and file manager improvements in speed as well as features such as thumbnailing and what not have been consistently impressive as well.
Plasma has gotten more consistent and featureful as well. I especially like the little number beneath the arrow on grouped tasks:
The task bar now groups, does multiple lines and more. The systray allows icons to be hidden, takes care of notifications and lets us put non-tray-icons alongside the freedesktop.org ones. Visual continuity is improved, and we're tweaking the default theme (I'm personally hoping for a non-all-black panel) to make that shine even more. We have tons of new components, tooltips that are pretty and even animated (and which can be turned off globally; though no UI for that yet). New calendars and improved consistency for clocks. A better panel controller for configuration and visual drop areas for drag and drop just like 4.1 had for moving applets. Alternate interface support for KRunner, along with actions-on-matches. New applet handles, meters and other widgets. Improved scripting bindings, support for two new entire widget systems (you can see a screencast of the Google Gadgets on Plasma support here), wallpaper plugins, containment switching, extenders and .. well, just so much more than that even.
The amount of polish (ranging from big things like Kickoff's theming or how it's obviousl what the current or needing-attention windows are to small things like the new glow around the taskbar buttons that subtly fades in/out as you mouse over) and performance improvements (such as delaying wallpaper rendering of non-visible containments or the SVG data cache).
We'll all be polishing and improving many more things between here and 4.2.0's release in late January, but I'm already looking at what we have and thinking to myself, "What a wonderful world." I'm more excited about 4.2's fit and finish than I have been about any KDE release since probably 3.2, which was also a watershed release in terms of stepping up the game.
Wednesday, November 05, 2008
overcoming cynicism
Can someone who inspires us be genuine?
Can we spend a night with our nation and believe in history being made, not just being faked?
Can we spend a night with another human in silent glory without question, in truth?
Can we change what ails our society and support that which is our strength? Perhaps with an act so simple as one simple as making a mark on a piece of paper?
Can we overcome our cynicism and believe? .. and not in a God we can not see or in people we build up to heights they can never live up to .. but in each other as we are right now, tonight?
I look back upon the history of humanity and see lightening strikes of greatness. Lights that flare as beacons undeniable, exposing coastlines of what we knew and at the same time the vaster oceans of what we could only dream of.
Newton, Leibniz and calculus. Einstein and the fabric of our universe. Darwin and the concept the life struggles, and through that struggle creates life itself. Jesus and the idea that nothing is sacred save Love. Which of us will birth some yet unknown idea that others will reflect upon in the future the same way we now reflect upon the great moments in our shared past?
Tonight a great nation pledged their votes for change. Tonight they backed a voice that gives me, and many others, personal hope. That voice came from a person who I hold as being no greater than you, but yet a voice that I believe holds a clarity and belief we need so desperately in this age, indeed in all ages: A voice of hope and possibility.
We may walk through hardship or ease, we may choose to do Great things or add our own small contribution to the monument of humanity .. but we must all decide to create and build and grow, or ...
The moments of triumph lift us up; the question is what we do with that new elevation.
I go to my bed tonight asking myself that very question.
Can we spend a night with our nation and believe in history being made, not just being faked?
Can we spend a night with another human in silent glory without question, in truth?
Can we change what ails our society and support that which is our strength? Perhaps with an act so simple as one simple as making a mark on a piece of paper?
Can we overcome our cynicism and believe? .. and not in a God we can not see or in people we build up to heights they can never live up to .. but in each other as we are right now, tonight?
I look back upon the history of humanity and see lightening strikes of greatness. Lights that flare as beacons undeniable, exposing coastlines of what we knew and at the same time the vaster oceans of what we could only dream of.
Newton, Leibniz and calculus. Einstein and the fabric of our universe. Darwin and the concept the life struggles, and through that struggle creates life itself. Jesus and the idea that nothing is sacred save Love. Which of us will birth some yet unknown idea that others will reflect upon in the future the same way we now reflect upon the great moments in our shared past?
Tonight a great nation pledged their votes for change. Tonight they backed a voice that gives me, and many others, personal hope. That voice came from a person who I hold as being no greater than you, but yet a voice that I believe holds a clarity and belief we need so desperately in this age, indeed in all ages: A voice of hope and possibility.
We may walk through hardship or ease, we may choose to do Great things or add our own small contribution to the monument of humanity .. but we must all decide to create and build and grow, or ...
The moments of triumph lift us up; the question is what we do with that new elevation.
I go to my bed tonight asking myself that very question.
Monday, November 03, 2008
trunk/kdelibs/plasma/
As of today, the library behind the Plasma desktop has been moved into kdelibs.
Three years ago I just wanted a nicer panel. What a rabbit hole awaited for me to descend! Indeed Plasma was supposed to just be a replacement for kicker, but the more I looked at the problem space the more work there was to do.
The problems the Plasma team discovered, defined and destroyed together were common issues other application developers were also facing. Surprise!
So the fledgling library that was started to allow people to write Applets (nee, Plasmoids!) with some sanity morphed into a framework for making applications on top of a canvas.
We went through a lot of growing pains as our canvas (QGraphicsView) was young and we weren't sure at the start what all we'd eventually want to do with it. It seemed that every step forward we took revealed another problem in the stack below us and, for bonus points, another challenge that needed addressing in libplasma. Theming, scripting, data delivery, search, SVGs, packaging, ...
At some point the Amarokers decided to take advantage of libplasma in Amarok2. A couple other apps started having similar aspirations. Then people started wanting to do things like put Plasmoids on screensavers or mobile devices or custom hardware aimed at vertical markets. There were moments where I got the feeling it was all getting out of hand, but the genie was out of the bottle and that meant libplasma needed to be a bit more serious.
With the 4.2 release of the KDE software products we are committing to binary compatibility. To mark that event, we have moved libplasma somewhere that is rather more convenient for others to use it from: a dependency on kdebase-workspace sucks for most applications, after all. Now libplasma is to be found in the much more amenable kdelibs.
All of the desktop application stack built on top of it (the Plasma desktop shell, KRunner, etc, etc) is still in kdebase-workspace, of course.
The path forward for libplasma is:
Exciting times, and far beyond what I'd originally expected. Perhaps the most exciting thing for me, however, is that this marks the start of a period when I can focus more fully on the things we are building on top of libplasma. Such as a better panel than kicker. ;)
Three years ago I just wanted a nicer panel. What a rabbit hole awaited for me to descend! Indeed Plasma was supposed to just be a replacement for kicker, but the more I looked at the problem space the more work there was to do.
The problems the Plasma team discovered, defined and destroyed together were common issues other application developers were also facing. Surprise!
So the fledgling library that was started to allow people to write Applets (nee, Plasmoids!) with some sanity morphed into a framework for making applications on top of a canvas.
We went through a lot of growing pains as our canvas (QGraphicsView) was young and we weren't sure at the start what all we'd eventually want to do with it. It seemed that every step forward we took revealed another problem in the stack below us and, for bonus points, another challenge that needed addressing in libplasma. Theming, scripting, data delivery, search, SVGs, packaging, ...
At some point the Amarokers decided to take advantage of libplasma in Amarok2. A couple other apps started having similar aspirations. Then people started wanting to do things like put Plasmoids on screensavers or mobile devices or custom hardware aimed at vertical markets. There were moments where I got the feeling it was all getting out of hand, but the genie was out of the bottle and that meant libplasma needed to be a bit more serious.
With the 4.2 release of the KDE software products we are committing to binary compatibility. To mark that event, we have moved libplasma somewhere that is rather more convenient for others to use it from: a dependency on kdebase-workspace sucks for most applications, after all. Now libplasma is to be found in the much more amenable kdelibs.
All of the desktop application stack built on top of it (the Plasma desktop shell, KRunner, etc, etc) is still in kdebase-workspace, of course.
The path forward for libplasma is:
- to continue adding what's needed for creating ever more kick-ass canvas based applications (or canvas based areas within applications) with ever fewer lines of code
- to start authoring those woefully late high level tutorials
- to feature complete the various script engines and consider moving some of them to kdebase-runtime in 4.3 so that everyone can rely on having core scripting available in the Plasma based application
- optimize and stabilize
Exciting times, and far beyond what I'd originally expected. Perhaps the most exciting thing for me, however, is that this marks the start of a period when I can focus more fully on the things we are building on top of libplasma. Such as a better panel than kicker. ;)
Qt Creator, KDevelop
I decided to give both Qt Creator, the new IDE from Qt Software, and KDevelop from today's svn trunk/ a whirl. Now, I'm not an IDE kind of guy. It's no secret that I'm an old fart who uses vim and lots of konsole tabs to do his development. The only GUIs I use in development are tools to visualize the output of valgrind runs, a web browser for patch review and defect reports and applications to communicate with my teammates (konversation, kontact and skype). No IDE is in that mix and I like it that way.
Well, almost. I do admit that there is a lot of stuff I do manually that a proper GUI could alleviate me of. Switching between headers and implementations, for instance. Every IDE I try, though, adds more inconvenience than convenience to my life. Maybe I'm just not giving them a fair shake .. and so every so often I try them again.
With Qt Creator having been recently announced, I decided to give it a whirl. In turn, that caused me to svn up and build KDevelop, too. Here are my thoughts and findings.
Before I get on to the interesting bits about the actual IDEs themselves, however, I'd like to address the proverbial elephant in the room: why the hell is Qt Software releasing an IDE? My perspective on that, which follows, is as a spectator to it all. I've known for a couple years that this was happening, respected the privacy of those involved but wasn't actually involved in any way with any of it. Honestly, I gave it a slim chance of ever seeing the light of day at all. ;)
Well, it was started back when the future of KDevelop was, shall we say, in a dubious state. That's an important bit of context to understand. Second, it was started as a bit of a skunkworks project, a "let's see what could be possible" thing. There really was a lot less intent at the start than one might expect. ;)
Today things are a bit different: KDevelop has momentum again. It seems to be a much more open project now, as well. It still has a lot of work needed to be done.
In the end, one can't always get 100% efficiency and there will be times people work on their own thing for less than purely logical reasons. We aren't vulcans, we are humans after all. There are some significant differences between Qt Creator and KDevelop, but really .. they are duplications in my opinion. That's unfortunate, but perhaps it's as close as we'll get to efficient. I hope that the two groups will find ways to share code and what not.
What really didn't help was how it was announced. The guys working on Qt Creator are not diplomats, they are engineers. (I stole that one, verbatim, from Mattias Ettrich himself, actually.) I tried to warn them that they needed to be really, really, really clear about licensing (something they have since corrected, so kudos for that) and the relationship to KDevelop.
I was very concerned it could cause unnecessary bickering and create schisms that are unnecessary. I hope that both the KDevelop hackers and the Qt Creator hackers can get along well (so far it seems so) and that the rest of us will let them live in peace in the meantime so they can all sort out whatever needs sorting out without pressure or incitement.
Ok, the elephant is now fully worked over, let's move to useful things!
There are many things about Qt Creator that I struck me right off the bat in a positive way. I loved:
As you can see, it's all about the interface. The text editor itself was good though not mind blowing. The use of subtle animations in places was good and the subtle use of colour is something that katepart could learn from I think. I didn't like that I had to press a key combo for autocompletion; I like that to be automatic but I couldn't find a configuration option for that.
Sounds like I'm starting to complain a bit, which means I must be ready for the next bit:
It wasn't all one big rose garden, however. It's not a complete product, so there are going to be rough edges. Here are the things that cut me and left me to bleed in this pre-release:
There is only support for Perforce. No subversion, no git, no cvs ... Huh-what? Ok, historically Qt Software uses Perforce internally, but there's been a big movement towards git as well. Qt Creator doesn't even support git though, and that's a big WTF.
There is only support for qmake. I don't use qmake and have only a handful of projects on disk that use it. CMake is a bare minimum here.
There is only a plain text editor for the build files, which is crazy. I totally get the idea that it should be possible to edit the text directly and agree with the Qt Creator guys that simple GUI wizard things are not enough for real build systems. That doesn't mean that there shouldn't be some basic GUI there though that covers 90% of the use cases (allowing it to remain simple and focussed) with a "edit manually" fallback to cover the other 10% of use cases that 90% of projects will need 2% of the time. (I love faux-tistics!)
Qt Creator looks great, but it goes overboard in its aggressive "style everything!" approach. It should keep its hands off my push buttons, for instance. The buttons in Qt Creator look like ass compared to the nice Oxygen buttons, and don't even get me started on my guess as to why they themed the menu bar but not the menus themselves. It really takes the shine off an otherwise gorgeous visual approach. As important as knowing what to theme is knowing what not to.
It would also be awesome if the icons used followed the xdg spec for those so we could theme them up, but that's not a "hate" more of a "wistfulness".
Back to the hating, the keyboard controls are either completely non-obvious or just completely missing. If I have to take my hands off the keyboard or press more than 2 keys to get to things I need, the word of the day becomes "FAIL". "Ctrl+K, 'l', space, #, enter" is exactly two too many key strokes to go to a line in the document, something I do all the time. "Ctrl+G, #, enter" is so much more sensible, and it could still use the uber-slick quick open bar, with Ctrl+G automating the "Ctrl+K, 'l', space" bit.
One might think Qt Creator is a bit mouse centric, but its not. In fact, the keyboard controls are actually better than the mouse interaction as can be seen by clicking in the bookmarks and stop points bar in the text editor. Try it and you'll see what I mean. ;)
Crashes are to be expected with a product at this point, but it amazes me that there isn't any autosave-while-editing feature. That makes crashes not only frustrating but deadly: I can't afford to lose work.
The lack of creating projects based on existing sources was also frustrating. Missing things like a class browser is also a bit mystifying.
These are all "little" things compared to the work that's been done. It's nearly usable today, but not quite. If they can push hard on this project for another 6 months or so I think it could be stellar, as none of the above point to problems with the actual underlying design of things. It's just not a completed product and as such has a bunch of holes. Fair enough, I can wait.
I could also contribute, but of course the source is still locked away. I don't get that, to be honest, and will by final entry in the "hate" column. The whole "we'll show you a binary for a while first" culture is really broken. Nobody in Qt Software will be surprised to hear me say that, but I'm tired of saying it quietly internally while watching the parade continue in public.
I gave KDevelop a spin as well. What's interesting is that what I hated about Qt Creator was mostly addressed in KDevelop: it's keyboard friendly, it has autocomplete, it blends and integrates with my desktop better, it supports all the revision control systems and build frameworks I might want, it has integration with valgrind, it imports existing projects nicely. It also supports tons of languages and has all these other plugins, too!
What really shone for me, though, was the ability to click on a symbol and get a summary window that is very visually attractive but more importantly contains insanely useful information. Things like the documentation from the header file for that method, what file it is defined in, what file it is declared in and where it is used in the project! Really, really nice.
When I discovered the Outline function which does that for every method in the current file I was sold on the idea.
I also liked the "Code / Debug" drop down in the toolbar that switches the tools between those two modes. Nice touch.
The fact that the text editor has tons of features and things like vi text mode is really cool as well.
There are a few areas that KDevelop really needs improvement from a simple user's perspective, and I'm sure neither of these things are news to the developers. Since I ragged on Qt Creator, though, it's only fair I do similarly with KDevelop. Apologies in advance.
There are a number of "not complete" features in KDevelop right now, such as the class browser which seems a bit random at times: why does it only show me the Plasma classes when it loads all of KDE base, though I selected only workspace/libs/plasma when importing the project? Like Qt Creator, KDevelop for KDE4 is not a completed product, however, so this is understandable.
The user interface, however, is in a general shambles. The menu system is something that I'm forced to interact with too often, and things are scattered everywhere it seems. Simply having useful shortcuts, such as a quick open bar as Qt Creator does would eliminate a lot of this pain.
There are moments of brilliance in the UI, like the code outliner and the class browser or how the UI never blocks even when it's churning through the code and parsing it out in the background.
Applying this elegance right across the UI would make KDevelop formidable. Instead I'm left wondering why every revision control system known to mankind is listed in the context menu when it's obvious that the project is using subversion, or where I should go to create a new class (I expected this in the class browser in the form of a "new" button or in the context menu even?).
As it stands, KDevelop has a great toolset and some really interesting features, but I can't bring myself to use it because of the UI. It's sort of the opposite situation compared to Qt Creator, isn't it? =)
The other thing that needs work in KDevelop right now is speed. Many things have gotten a lot faster in the last few months, and kudos on those accomplishments to the KDevelop team. However, when I opened libplasma as a project it imported all of kdebase. This not only took a rather long time (somewhat understandable as it's a good chunk of code), it didn't give me much visual feedback (again, the whole "UI elegance" thing) and then when it was finally up opening subdirectories in the Project explorer took 2-4 seconds. So there's room for improvement here in ways that will make the user experience nicer.
Oh, and the lack of autosave-as-you-edit in katepart is just as insane an omission as it is in Qt Creator.
So what will I be using to code with this month? Vim and Konsole.
In six months it might be a different story. I might be using either Qt Creator or KDevelop; both have intense promise, and just need to show what they are capable with over the next year.
For the Qt Creator team I'd strongly suggest opening the code now rather than later and build a development community around it. The functionality holes in the app are huge and I don't think you'll be able to fill them all yourself. I know this isn't how other Qt Software tools get written, but maybe it's time for a shift there. Keep the focus on clarity and simplicity, but engage the audience to build bigger, better, faster and quicker.
For the KDevelop team, I'd strongly suggest casting an eye to the UI. It has plenty of features and seems to actually generally work. It's really time to think about how the user interacts with those things: make it dead easy to get to the most needed features, make it dead easy to navigate around the project and get rid of the UI cruft. It's a different kind of work compared to doing the crunchy yet great Declaration-Usage Chain stuff, but all your efforts put into DUChain may be for nothing if the UI doesn't speak to the user. It's a step up from where KDevelop3 was, but only a small step up so far. The outliner gives me hope, however, and it might be sensible to stop working on IDE features and force yourselves to shift to user interface.
I know that the above is not easy. If it was easy, it would already be done by this point. I know how hard it can be to expose your code and share with a global team (in the case of Qt Creator) or to step away from your main goal to focus on a temporary goal that will bring you users (in the case of KDevelop). I've faced both in the last year with Plasma (focusing on making a good traditional desktop experience causing a temporary sidelining of the 'revamp the user experience' during that cycle has been painful for me these last 5 months), and so you have my empathies.
You probably also have earned a "bitch at Plasma" card now. ;)
I am happy to see that we have so much movement on the devel tools side of things in the Qt/KDE world now though. It wasn't a happy place a couple years ago. In fact, it was a depressing grey place, but now the dawn is upon us. Let's see what full daylight looks like when Qt Creator and KDevelop make stable production releases.
Maybe I'll even say goodbye to vim at that point.
Well, almost. I do admit that there is a lot of stuff I do manually that a proper GUI could alleviate me of. Switching between headers and implementations, for instance. Every IDE I try, though, adds more inconvenience than convenience to my life. Maybe I'm just not giving them a fair shake .. and so every so often I try them again.
With Qt Creator having been recently announced, I decided to give it a whirl. In turn, that caused me to svn up and build KDevelop, too. Here are my thoughts and findings.
First, The Elephant In The Room
Before I get on to the interesting bits about the actual IDEs themselves, however, I'd like to address the proverbial elephant in the room: why the hell is Qt Software releasing an IDE? My perspective on that, which follows, is as a spectator to it all. I've known for a couple years that this was happening, respected the privacy of those involved but wasn't actually involved in any way with any of it. Honestly, I gave it a slim chance of ever seeing the light of day at all. ;)
Well, it was started back when the future of KDevelop was, shall we say, in a dubious state. That's an important bit of context to understand. Second, it was started as a bit of a skunkworks project, a "let's see what could be possible" thing. There really was a lot less intent at the start than one might expect. ;)
Today things are a bit different: KDevelop has momentum again. It seems to be a much more open project now, as well. It still has a lot of work needed to be done.
In the end, one can't always get 100% efficiency and there will be times people work on their own thing for less than purely logical reasons. We aren't vulcans, we are humans after all. There are some significant differences between Qt Creator and KDevelop, but really .. they are duplications in my opinion. That's unfortunate, but perhaps it's as close as we'll get to efficient. I hope that the two groups will find ways to share code and what not.
What really didn't help was how it was announced. The guys working on Qt Creator are not diplomats, they are engineers. (I stole that one, verbatim, from Mattias Ettrich himself, actually.) I tried to warn them that they needed to be really, really, really clear about licensing (something they have since corrected, so kudos for that) and the relationship to KDevelop.
I was very concerned it could cause unnecessary bickering and create schisms that are unnecessary. I hope that both the KDevelop hackers and the Qt Creator hackers can get along well (so far it seems so) and that the rest of us will let them live in peace in the meantime so they can all sort out whatever needs sorting out without pressure or incitement.
Ok, the elephant is now fully worked over, let's move to useful things!
Qt Creator: What I Loved
There are many things about Qt Creator that I struck me right off the bat in a positive way. I loved:
- how when you collapse a bit of code, it has a little "collapsed" marker that you can hover over to see the code that is collapsed in an overlay. Hover interfaces rock for those kinds of use cases.
- how the first thing you see when you start it up is "Get Started" if it's your first time running it or a project listing and session restore options if you've already used it for work. It's a great compromise between the insane menagerie that is the NetBeans opening page and the blank spaces of other IDEs that force you to instantly hit the menu system. Having the obvious start points front and center just waiting for you to click is perfect.
- how when a file was open, it listed all the methods in the file in the "smart bar" at the top. I don't really know what that thing at the top is called, but I'm going to call it the smart bar. It looks smart, and it works smart. .. ergo it's a smart bar. =P That same bar also shows open files in a drop down which I find much more sensible than tabs.
- the smart bar at the bottom of the window with it's quick open (typing "| Animator" to get the Plasma::Animator class is neat) and it's quick access buttons for things like open tasks.
- the side bar which gave me access to all the things I need: editing, debugging, building, help ... I never hit the menu bar except to see what was actually in there after actually using it for a while yesterday.
- the speed was impressive: things opened quickly, syntax highlighting was fast, fast, fast.
As you can see, it's all about the interface. The text editor itself was good though not mind blowing. The use of subtle animations in places was good and the subtle use of colour is something that katepart could learn from I think. I didn't like that I had to press a key combo for autocompletion; I like that to be automatic but I couldn't find a configuration option for that.
Sounds like I'm starting to complain a bit, which means I must be ready for the next bit:
Qt Creator: What I Hated
It wasn't all one big rose garden, however. It's not a complete product, so there are going to be rough edges. Here are the things that cut me and left me to bleed in this pre-release:
There is only support for Perforce. No subversion, no git, no cvs ... Huh-what? Ok, historically Qt Software uses Perforce internally, but there's been a big movement towards git as well. Qt Creator doesn't even support git though, and that's a big WTF.
There is only support for qmake. I don't use qmake and have only a handful of projects on disk that use it. CMake is a bare minimum here.
There is only a plain text editor for the build files, which is crazy. I totally get the idea that it should be possible to edit the text directly and agree with the Qt Creator guys that simple GUI wizard things are not enough for real build systems. That doesn't mean that there shouldn't be some basic GUI there though that covers 90% of the use cases (allowing it to remain simple and focussed) with a "edit manually" fallback to cover the other 10% of use cases that 90% of projects will need 2% of the time. (I love faux-tistics!)
Qt Creator looks great, but it goes overboard in its aggressive "style everything!" approach. It should keep its hands off my push buttons, for instance. The buttons in Qt Creator look like ass compared to the nice Oxygen buttons, and don't even get me started on my guess as to why they themed the menu bar but not the menus themselves. It really takes the shine off an otherwise gorgeous visual approach. As important as knowing what to theme is knowing what not to.
It would also be awesome if the icons used followed the xdg spec for those so we could theme them up, but that's not a "hate" more of a "wistfulness".
Back to the hating, the keyboard controls are either completely non-obvious or just completely missing. If I have to take my hands off the keyboard or press more than 2 keys to get to things I need, the word of the day becomes "FAIL". "Ctrl+K, 'l', space, #, enter" is exactly two too many key strokes to go to a line in the document, something I do all the time. "Ctrl+G, #, enter" is so much more sensible, and it could still use the uber-slick quick open bar, with Ctrl+G automating the "Ctrl+K, 'l', space" bit.
One might think Qt Creator is a bit mouse centric, but its not. In fact, the keyboard controls are actually better than the mouse interaction as can be seen by clicking in the bookmarks and stop points bar in the text editor. Try it and you'll see what I mean. ;)
Crashes are to be expected with a product at this point, but it amazes me that there isn't any autosave-while-editing feature. That makes crashes not only frustrating but deadly: I can't afford to lose work.
The lack of creating projects based on existing sources was also frustrating. Missing things like a class browser is also a bit mystifying.
These are all "little" things compared to the work that's been done. It's nearly usable today, but not quite. If they can push hard on this project for another 6 months or so I think it could be stellar, as none of the above point to problems with the actual underlying design of things. It's just not a completed product and as such has a bunch of holes. Fair enough, I can wait.
I could also contribute, but of course the source is still locked away. I don't get that, to be honest, and will by final entry in the "hate" column. The whole "we'll show you a binary for a while first" culture is really broken. Nobody in Qt Software will be surprised to hear me say that, but I'm tired of saying it quietly internally while watching the parade continue in public.
KDevelop: What I Loved
I gave KDevelop a spin as well. What's interesting is that what I hated about Qt Creator was mostly addressed in KDevelop: it's keyboard friendly, it has autocomplete, it blends and integrates with my desktop better, it supports all the revision control systems and build frameworks I might want, it has integration with valgrind, it imports existing projects nicely. It also supports tons of languages and has all these other plugins, too!
What really shone for me, though, was the ability to click on a symbol and get a summary window that is very visually attractive but more importantly contains insanely useful information. Things like the documentation from the header file for that method, what file it is defined in, what file it is declared in and where it is used in the project! Really, really nice.
When I discovered the Outline function which does that for every method in the current file I was sold on the idea.
I also liked the "Code / Debug" drop down in the toolbar that switches the tools between those two modes. Nice touch.
The fact that the text editor has tons of features and things like vi text mode is really cool as well.
KDevelop: What I Hated
There are a few areas that KDevelop really needs improvement from a simple user's perspective, and I'm sure neither of these things are news to the developers. Since I ragged on Qt Creator, though, it's only fair I do similarly with KDevelop. Apologies in advance.
There are a number of "not complete" features in KDevelop right now, such as the class browser which seems a bit random at times: why does it only show me the Plasma classes when it loads all of KDE base, though I selected only workspace/libs/plasma when importing the project? Like Qt Creator, KDevelop for KDE4 is not a completed product, however, so this is understandable.
The user interface, however, is in a general shambles. The menu system is something that I'm forced to interact with too often, and things are scattered everywhere it seems. Simply having useful shortcuts, such as a quick open bar as Qt Creator does would eliminate a lot of this pain.
There are moments of brilliance in the UI, like the code outliner and the class browser or how the UI never blocks even when it's churning through the code and parsing it out in the background.
Applying this elegance right across the UI would make KDevelop formidable. Instead I'm left wondering why every revision control system known to mankind is listed in the context menu when it's obvious that the project is using subversion, or where I should go to create a new class (I expected this in the class browser in the form of a "new" button or in the context menu even?).
As it stands, KDevelop has a great toolset and some really interesting features, but I can't bring myself to use it because of the UI. It's sort of the opposite situation compared to Qt Creator, isn't it? =)
The other thing that needs work in KDevelop right now is speed. Many things have gotten a lot faster in the last few months, and kudos on those accomplishments to the KDevelop team. However, when I opened libplasma as a project it imported all of kdebase. This not only took a rather long time (somewhat understandable as it's a good chunk of code), it didn't give me much visual feedback (again, the whole "UI elegance" thing) and then when it was finally up opening subdirectories in the Project explorer took 2-4 seconds. So there's room for improvement here in ways that will make the user experience nicer.
Oh, and the lack of autosave-as-you-edit in katepart is just as insane an omission as it is in Qt Creator.
Wrap Up
So what will I be using to code with this month? Vim and Konsole.
In six months it might be a different story. I might be using either Qt Creator or KDevelop; both have intense promise, and just need to show what they are capable with over the next year.
For the Qt Creator team I'd strongly suggest opening the code now rather than later and build a development community around it. The functionality holes in the app are huge and I don't think you'll be able to fill them all yourself. I know this isn't how other Qt Software tools get written, but maybe it's time for a shift there. Keep the focus on clarity and simplicity, but engage the audience to build bigger, better, faster and quicker.
For the KDevelop team, I'd strongly suggest casting an eye to the UI. It has plenty of features and seems to actually generally work. It's really time to think about how the user interacts with those things: make it dead easy to get to the most needed features, make it dead easy to navigate around the project and get rid of the UI cruft. It's a different kind of work compared to doing the crunchy yet great Declaration-Usage Chain stuff, but all your efforts put into DUChain may be for nothing if the UI doesn't speak to the user. It's a step up from where KDevelop3 was, but only a small step up so far. The outliner gives me hope, however, and it might be sensible to stop working on IDE features and force yourselves to shift to user interface.
I know that the above is not easy. If it was easy, it would already be done by this point. I know how hard it can be to expose your code and share with a global team (in the case of Qt Creator) or to step away from your main goal to focus on a temporary goal that will bring you users (in the case of KDevelop). I've faced both in the last year with Plasma (focusing on making a good traditional desktop experience causing a temporary sidelining of the 'revamp the user experience' during that cycle has been painful for me these last 5 months), and so you have my empathies.
You probably also have earned a "bitch at Plasma" card now. ;)
I am happy to see that we have so much movement on the devel tools side of things in the Qt/KDE world now though. It wasn't a happy place a couple years ago. In fact, it was a depressing grey place, but now the dawn is upon us. Let's see what full daylight looks like when Qt Creator and KDevelop make stable production releases.
Maybe I'll even say goodbye to vim at that point.
Sunday, November 02, 2008
rythmic
I'm home again, and getting up to speed on API fixlets that need doing so that we have a hope of pushing libplasma into kdelibs relatively soon. I went out for a walk with the P-man tonight (during which we got a coffee and some pizza slices =) since the weather was gorgeous and I thought it'd be nice to spend some "hanging out together" time away from the machines and four walls of home.
When we returned, I glanced at my desktop and saw this:
I had been running xrestop and forgot to stop it before leaving on our walk. Apparently it has quite the consistent and recognizable pattern to its work load. It made me think of a heart monitor, granted with a pretty odd heart on the other end of it. ;)
That graph is one of the five components in the system monitor Plasmoid that will be part of the 4.2 release. I've seen some HOWTO articles on the net recently about how you can set up other system monitoring widgets on your desktop and have marveled at the complexity of them. Back in the day all the cool kids used to use gkrellm (and I'm sure many still do) which is pretty dang easy to set up if I recall correctly, and Plasma's system monitor is just point-and-click to set up. It doesn't even have a config dialog. (Yet? ;)
When we returned, I glanced at my desktop and saw this:
I had been running xrestop and forgot to stop it before leaving on our walk. Apparently it has quite the consistent and recognizable pattern to its work load. It made me think of a heart monitor, granted with a pretty odd heart on the other end of it. ;)
That graph is one of the five components in the system monitor Plasmoid that will be part of the 4.2 release. I've seen some HOWTO articles on the net recently about how you can set up other system monitoring widgets on your desktop and have marveled at the complexity of them. Back in the day all the cool kids used to use gkrellm (and I'm sure many still do) which is pretty dang easy to set up if I recall correctly, and Plasma's system monitor is just point-and-click to set up. It doesn't even have a config dialog. (Yet? ;)
Subscribe to:
Posts (Atom)
