the best christmas present that i got this year (ok, besides getting to spend it quietly with family) was being able to be offline for a number of days and, when i came back to find that plasma development had continued on with patches being reviewed, discussed, merged and committed. i have a lot more work to do to make the full plasma vision completely transparent and owned by as many others in the project as possible, but it's vastly relieving to know that the bus count for plasma is quantifiably higher than one. =)
thanks to everyone on the plasma team for a relatively guilt free 5 days of christmas.
Friday, December 28, 2007
back to the grind
i head back home tomorrow morning. it's been a great and relaxing few days with family. i'm looking forward to being back with the cats and my own bed again, all the same. i have a ton of stuff to integrate into plasma before the 4th, so it'll be back to the grind from saturday on. i caught up with email on the plasma list this evening so will be able to dive right in.
i also managed to get some much needed reading done over the last few days.
i may be a bit blog silent until the new year, but in january we'll have a lot of news to share and cover. it'll also be when we start setting up the train set for KDE 4.1.
i also managed to get some much needed reading done over the last few days.
i may be a bit blog silent until the new year, but in january we'll have a lot of news to share and cover. it'll also be when we start setting up the train set for KDE 4.1.
Friday, December 21, 2007
aseigo.away();
p. and i have been running around all day getting ready to leave tomorrow for the family holiday trip. he took part in an assembly at school this morning where his class sang and played music on flutes, after which we spent the rest of the afternoon shopping, organizing, cleaning, etc.
i'll have my laptop with me on the trip but will be in very spotty communication (if at all) with the rest of the world until i return on the 28th. so if you can't get a hold of me, you'll know why. =)
i'll have my laptop with me on the trip but will be in very spotty communication (if at all) with the rest of the world until i return on the 28th. so if you can't get a hold of me, you'll know why. =)
Thursday, December 20, 2007
Dear Glyn Moody
Dear Glyn Moody:
I found how you trotted out an age old and long since dealt with issue, namely the licensing of Qt1, as a way to discuss what you consider to be "the growing tensions between the KDE and GNOME camps" to be tasteless and ironic. If you want to help mend fences (we need all the hands we can get), the last thing to do is drag long-since dealt with issues that have been irrelevant for years back to the surface.
A cynic might think you were trying to deflect the issues that have arisen around OOXML and the negative attention it has resulted in for GNOME by kicking the someone else's dead horses. Personally, I think you were just being a bit clumsy while trying to make the point that everyone falters now and again and that nobody gains from conflict within our shared house. I think your intentions were good but unfortunately the road to hell, as they say, is paved with good intentions.
We in the free software world have been mending the schisms that came about due to events that predate the turn of the century through hard, sustained effort. The efforts have come from people on all sides of all projects. freedesktop.org has become a ever stronger rallying point, as have initiatives such as the Linux Foundations desktop architect's group and greater participation in shared technologies such HAL/DBUS to name just one of many, many success stories. The fact that more and more GNOME and KDE community members spend time with each other at conferences and communicate regularly shows how far we've come. Today we blog on each other's planet's, hang out on each other's irc channels and regularly attend each other's conferences; the lines between "ours and theirs" are blurring more and more because of this. That's a healthy thing, and something we're achieving without destroying the state of coopetition or the various projects' identities.
I've personally enjoyed building relationships with people such as Dave Neary (we've often talked about foundation related stuff), John Palmieri and many others. Hanging with Ben Otte at aKademy and having some really interesting conversations with him was one of the highlights of the event for me. I regularly deal with companies that are "Gtk+ shops" and know many people who work with one set of tools at work, another at home, etc. Nobody bats an eye at this anymore, and I'm not unique in this experience, either.
So, with respect, if you feel there are "growing tensions between the KDE and GNOME camps" I can only point out that this may be your perception but it is certainly not the reality of things. Unfortunately, when you decide to needlessly dredge up the dead past, you endanger the process of schism healing you say you want to see happen. It would be sad that if by mistaking the world to be divided you actually helped make it so.
It should be pointed out to you that KDE's statement on ODF was not a jab at GNOME or any other free software people. Juxtaposing our position with that of GNOME's was the work of media pundits and concerned individuals such as Richard Stallman; it was something we had no part, let alone say, in. In fact, we specifically discussed amongst ourselves how the last thing we wanted to create was an "us vs them" thing. This can be hard when the media swirls about trying to invent sensationalistic headlines at every turn.
So why did KDE say anything at all? We felt it necessary to make it clear where we stood on a matter that was getting increased attention. Not only were we being asked where we stood on the issues more and more, we feel very strongly about free and open standards. This is something that KDE and GNOME both have in common, I might add. As such, we felt it necessary to clearly, and we hoped without controversy, state our position on open standards and free software. Other free software projects will have their own positions, most of which (hopefully all, actually) will be complimentary with ours. All the same, we have no bone of contention with what you or others decide to do. We recognize that each has the right to take their own stands, and that we can only own what we do ourselves. In fact, we learned the hard way many years ago just how painful it can be when that grace is not afforded to you and people decide to make a public issue of growing pains and stumbling blocks one unwittingly lays at their own feet.
Let me close by saying that I think it is sad and unfortunate that so much has been made of the OOXML vis-a-vis the GNOME Foundation story. I wish people would let it die. I agree with you on this point: this meme does no service to the free software desktop world. I personally believe it has been blown out of proportion, represented too often in the worst possible light and, largely through communications mismanagement, become one hell of a mountain-that-should-have-been-a-molehill. I'm very sorry that the GNOME project is having to go through this. I also know that in a year or two's time this will be an inconsequential blip of a footnote in their history.
In the meantime, let's try and not pile further insult onto the injury or attempt to fix it by dragging others down in the process.
Sincerely,
Aaron Seigo, fellow free software desktop hacker.
I found how you trotted out an age old and long since dealt with issue, namely the licensing of Qt1, as a way to discuss what you consider to be "the growing tensions between the KDE and GNOME camps" to be tasteless and ironic. If you want to help mend fences (we need all the hands we can get), the last thing to do is drag long-since dealt with issues that have been irrelevant for years back to the surface.
A cynic might think you were trying to deflect the issues that have arisen around OOXML and the negative attention it has resulted in for GNOME by kicking the someone else's dead horses. Personally, I think you were just being a bit clumsy while trying to make the point that everyone falters now and again and that nobody gains from conflict within our shared house. I think your intentions were good but unfortunately the road to hell, as they say, is paved with good intentions.
We in the free software world have been mending the schisms that came about due to events that predate the turn of the century through hard, sustained effort. The efforts have come from people on all sides of all projects. freedesktop.org has become a ever stronger rallying point, as have initiatives such as the Linux Foundations desktop architect's group and greater participation in shared technologies such HAL/DBUS to name just one of many, many success stories. The fact that more and more GNOME and KDE community members spend time with each other at conferences and communicate regularly shows how far we've come. Today we blog on each other's planet's, hang out on each other's irc channels and regularly attend each other's conferences; the lines between "ours and theirs" are blurring more and more because of this. That's a healthy thing, and something we're achieving without destroying the state of coopetition or the various projects' identities.
I've personally enjoyed building relationships with people such as Dave Neary (we've often talked about foundation related stuff), John Palmieri and many others. Hanging with Ben Otte at aKademy and having some really interesting conversations with him was one of the highlights of the event for me. I regularly deal with companies that are "Gtk+ shops" and know many people who work with one set of tools at work, another at home, etc. Nobody bats an eye at this anymore, and I'm not unique in this experience, either.
So, with respect, if you feel there are "growing tensions between the KDE and GNOME camps" I can only point out that this may be your perception but it is certainly not the reality of things. Unfortunately, when you decide to needlessly dredge up the dead past, you endanger the process of schism healing you say you want to see happen. It would be sad that if by mistaking the world to be divided you actually helped make it so.
It should be pointed out to you that KDE's statement on ODF was not a jab at GNOME or any other free software people. Juxtaposing our position with that of GNOME's was the work of media pundits and concerned individuals such as Richard Stallman; it was something we had no part, let alone say, in. In fact, we specifically discussed amongst ourselves how the last thing we wanted to create was an "us vs them" thing. This can be hard when the media swirls about trying to invent sensationalistic headlines at every turn.
So why did KDE say anything at all? We felt it necessary to make it clear where we stood on a matter that was getting increased attention. Not only were we being asked where we stood on the issues more and more, we feel very strongly about free and open standards. This is something that KDE and GNOME both have in common, I might add. As such, we felt it necessary to clearly, and we hoped without controversy, state our position on open standards and free software. Other free software projects will have their own positions, most of which (hopefully all, actually) will be complimentary with ours. All the same, we have no bone of contention with what you or others decide to do. We recognize that each has the right to take their own stands, and that we can only own what we do ourselves. In fact, we learned the hard way many years ago just how painful it can be when that grace is not afforded to you and people decide to make a public issue of growing pains and stumbling blocks one unwittingly lays at their own feet.
Let me close by saying that I think it is sad and unfortunate that so much has been made of the OOXML vis-a-vis the GNOME Foundation story. I wish people would let it die. I agree with you on this point: this meme does no service to the free software desktop world. I personally believe it has been blown out of proportion, represented too often in the worst possible light and, largely through communications mismanagement, become one hell of a mountain-that-should-have-been-a-molehill. I'm very sorry that the GNOME project is having to go through this. I also know that in a year or two's time this will be an inconsequential blip of a footnote in their history.
In the meantime, let's try and not pile further insult onto the injury or attempt to fix it by dragging others down in the process.
Sincerely,
Aaron Seigo, fellow free software desktop hacker.
kde for your business
Matt Hartley recommends KDE for you business. pretty cool! i think Matt was generally even handed in his coverage, giving examples of the strengths and challenges of both kde and gnome. it seems Matt has real world experience as a technology service provider in supporting linux desktops with both kde and gnome.
i do think he overstated the "single group controls Qt" thing, especially with the FreeQt Foundation and recent strides towards greater openness, but it does help highlight what is still probably the #1 thing we need to work on as far as both public perception as well as actual practices goes. personally, i'm committed to helping continue to open up all our worlds more and more; the balance to that being that we shouldn't endanger what's worked well for us in the process. that's why these things take time and a lot of thought and effort.
it was also interesting to see issues raised such as sparse developer documentation, attention to interface guidelines and specific application weaknesses mentioned that we are working hard to address in the kde4 series (via techbase, our new human user guidlines or H.U.G. *insert laughter* and efforts like akonadi, respectively) ... if we're working on the points people on the outside are identifying as weak points, we're probably doing a decent job of staying in touch with reality. that said, it makes me wonder what people haven't noticed yet that we aren't working on?
as an added bonus, at least for me, Matt linked to the 3.2 release announcement bits. i remember putting that stuff together for the release (i can't remember who else helped with that? danimo? hm... if it was you, remind me because i'd like to keep these bits of history straight =)
i remember thinking at the time that kde was so amazingly terrific; if only we weren't doing such a great job of hiding that fact from everyone else. ;) being the over-sharing communicator that i tend to be, i figured that would be easy to fix with enough clear and inspiring communication, right? ... right?! how could people not feel the love we feel for our work if we just told them about it. at the time, i was secretly unhappy about the content of kde's press releases. they were accurate but ... dry. they also rarely squared off effectively on hot button issues.
i figured the only way to earn the right to criticize things was to help improve them; then i'd just be pissing on my own failures, right? ;) so while everyone else (or so it seemed) was having fun at kastle (the last non-akademy world conference), i was back home in calgary (still having never met any of the other kde developers in person!) writing an announcement for 3.2beta1. highlights of that experience: coolo telling me he thought it was good (the teacher's pet in me coming out there, perhaps?) and seeing the bugs/wishes numbers bit start to appear all over place (including in SUSE marketing materials ;).
this was how i embarked upon the path to helping out with kde's public communication and promotion efforts: writing a couple of articles in my spare time. what a wild ride it's been since ... and i still get to write code, too! =)
so seeing Matt link to the 3.2 materials made me smile with fond recollections. it shows just how long lasting the effects of such efforts are: long after the 3.2 release has come and gone, the communication around it continues to motivate people to use its successors. it also shows how far we've come as our communications platform has matured considerably since then. *ahem* (reading some parts of the 3.2 stuff i wrote makes me cringe a bit =)
if you had told me back then that we'd have a functioning marketing working group with a vibrant promo community (emphasis on community) and people writing really cool and effective articles about kde who weren't necessarily even developers but were doing so because they were so jacked about the project ... or that we'd have an official release event that involved a couple days of presentations, a press event and what not or such a cool 10th year anniversary with similar accoutrements ... well ok, i probably would've believed you because i've always had faith in this community being able to do anything it puts its collective mind to, but it would've seemed a long, long, loooong way off. more than just the few years time (not to mention the remarkably tiny, as in "essentially does not exist", budget) it has taken.
so to everyone who has contributed, great and small, to kde's communications efforts who have put together commit digests, "this week in svn"s, feature articles in trade magazines, user and developer books and, yes, even those dry press releases of old: these are the bricks we laid together to build this bridge between what we are making (kde) and the world that needs to find it (even if they don't always know it yet ;)
to those who continue to help out and those yet to come: i can't wait to see what you come up with in the future that will make me cringe a little inside when i look back at what we're doing today. your little article today could be the next snowball that launches an avalanche.
i'll close with a bit more from Matt's article:
nice.
to be fair, i feel compelled to say to all the other free software desktop projects out there that range from kernel to user space and back: it couldn't be done without all your efforts as well. rock on, people, because in the years to come the world is going to take noticing that we're not only keeping the pace, but that we're actually setting it.
i do think he overstated the "single group controls Qt" thing, especially with the FreeQt Foundation and recent strides towards greater openness, but it does help highlight what is still probably the #1 thing we need to work on as far as both public perception as well as actual practices goes. personally, i'm committed to helping continue to open up all our worlds more and more; the balance to that being that we shouldn't endanger what's worked well for us in the process. that's why these things take time and a lot of thought and effort.
it was also interesting to see issues raised such as sparse developer documentation, attention to interface guidelines and specific application weaknesses mentioned that we are working hard to address in the kde4 series (via techbase, our new human user guidlines or H.U.G. *insert laughter* and efforts like akonadi, respectively) ... if we're working on the points people on the outside are identifying as weak points, we're probably doing a decent job of staying in touch with reality. that said, it makes me wonder what people haven't noticed yet that we aren't working on?
as an added bonus, at least for me, Matt linked to the 3.2 release announcement bits. i remember putting that stuff together for the release (i can't remember who else helped with that? danimo? hm... if it was you, remind me because i'd like to keep these bits of history straight =)
i remember thinking at the time that kde was so amazingly terrific; if only we weren't doing such a great job of hiding that fact from everyone else. ;) being the over-sharing communicator that i tend to be, i figured that would be easy to fix with enough clear and inspiring communication, right? ... right?! how could people not feel the love we feel for our work if we just told them about it. at the time, i was secretly unhappy about the content of kde's press releases. they were accurate but ... dry. they also rarely squared off effectively on hot button issues.
i figured the only way to earn the right to criticize things was to help improve them; then i'd just be pissing on my own failures, right? ;) so while everyone else (or so it seemed) was having fun at kastle (the last non-akademy world conference), i was back home in calgary (still having never met any of the other kde developers in person!) writing an announcement for 3.2beta1. highlights of that experience: coolo telling me he thought it was good (the teacher's pet in me coming out there, perhaps?) and seeing the bugs/wishes numbers bit start to appear all over place (including in SUSE marketing materials ;).
this was how i embarked upon the path to helping out with kde's public communication and promotion efforts: writing a couple of articles in my spare time. what a wild ride it's been since ... and i still get to write code, too! =)
so seeing Matt link to the 3.2 materials made me smile with fond recollections. it shows just how long lasting the effects of such efforts are: long after the 3.2 release has come and gone, the communication around it continues to motivate people to use its successors. it also shows how far we've come as our communications platform has matured considerably since then. *ahem* (reading some parts of the 3.2 stuff i wrote makes me cringe a bit =)
if you had told me back then that we'd have a functioning marketing working group with a vibrant promo community (emphasis on community) and people writing really cool and effective articles about kde who weren't necessarily even developers but were doing so because they were so jacked about the project ... or that we'd have an official release event that involved a couple days of presentations, a press event and what not or such a cool 10th year anniversary with similar accoutrements ... well ok, i probably would've believed you because i've always had faith in this community being able to do anything it puts its collective mind to, but it would've seemed a long, long, loooong way off. more than just the few years time (not to mention the remarkably tiny, as in "essentially does not exist", budget) it has taken.
so to everyone who has contributed, great and small, to kde's communications efforts who have put together commit digests, "this week in svn"s, feature articles in trade magazines, user and developer books and, yes, even those dry press releases of old: these are the bricks we laid together to build this bridge between what we are making (kde) and the world that needs to find it (even if they don't always know it yet ;)
to those who continue to help out and those yet to come: i can't wait to see what you come up with in the future that will make me cringe a little inside when i look back at what we're doing today. your little article today could be the next snowball that launches an avalanche.
i'll close with a bit more from Matt's article:
"Tie this in with the fact that KDE is allowing the Linux platform to keep pace with competing platforms like Windows and OS X ..."
nice.
to be fair, i feel compelled to say to all the other free software desktop projects out there that range from kernel to user space and back: it couldn't be done without all your efforts as well. rock on, people, because in the years to come the world is going to take noticing that we're not only keeping the pace, but that we're actually setting it.
Wednesday, December 19, 2007
sometimes it's the little things
the media is ever on the look-out for the Big Story(tm), so it's easy to miss the little ones as they don't often blast brightly through the aether. i was glad that some of the community news sites carried this story about 48 new kde-on-linux users in vietnam. made me smile. that's 48 more youth being introduced to the wonders of free software. maybe not huge in the big scheme of things, but i can't help but think two things: repeated tens of thousands of times over these "little deployments" mean everything, and who knows what these young people will go on to do with their lives? maybe something great, maybe something with free software. you never know which seeds will sprout into the tallest trees, so every one counts.
spent the day today optimizing and bug fixing in plasma. no big features to comment on or exciting will-change-your-world-forever type things ... but again: it's often the little things that help make the differences.
i've also noticed that there are more and more plasma related patches being posted for review. it's great to see more and more people joining the plasmafication gang. i've gone over at least 4 new patch sets just today, and even the smallest of improvements are improvements and they all add up. see, the theme keeps recurring ;)
spent the day today optimizing and bug fixing in plasma. no big features to comment on or exciting will-change-your-world-forever type things ... but again: it's often the little things that help make the differences.
i've also noticed that there are more and more plasma related patches being posted for review. it's great to see more and more people joining the plasmafication gang. i've gone over at least 4 new patch sets just today, and even the smallest of improvements are improvements and they all add up. see, the theme keeps recurring ;)
Tuesday, December 18, 2007
umeet presentation
in about two hours, at 18:00 UTC, i'll be presenting on kde4 at the seventh umeet online conference which is put on every year by uninet. it's held in spanish, portuguese and english and covers an interesting array of topics. this is my third (i think?) year visiting it as a speaker. unlike other conferences which involve me dealing with airplanes, luggage and hotels this one is just an hour or so out of my day sitting in front of a warm computer.
my presentation will be in #linux on irc.uninet.edu and will mostly be question and answer this year, i think. i decided that since there seems to be a lot of interest around kde4, that we'll try an "open floor" format for today's presentation.
my presentation will be in #linux on irc.uninet.edu and will mostly be question and answer this year, i think. i decided that since there seems to be a lot of interest around kde4, that we'll try an "open floor" format for today's presentation.
that which we call life
we have a most amazing ability: we look upon the world around us and we can see things that aren't there ... yet. we can imagine absent things so clearly that we are able to manifest them in the world outside our minds. we apply effort to dreams and turn them into something the rest of existence can experience.
the idea of the "creative process" is usually married with the idea of "art", but all of life, well lived, is that process of creation. to see the loaf of bread that does not exist yet, but will once we mix the wet and dry ingredients just right ... to see the dance in the leaves that fall from autumn trees set to music that persists only in our mind ... to make something with our hands, our words, our eyes ... this is that which we call life.
i know that there are those who choose (hopefully unknowingly) to skip over this trail of opportunity, and that there are also those whose world is who torn that this human experience is out of reach ... but for the vast, overwhelming majority of us: it's there as often as we wish it to be. what more do we want to make life meaningful?
i saw and heard something tonight that made me remember just how breathtaking the results can be when people with talent put immense effort into something. it made me remember all the small day-to-day things that are also, if on a more humble and maybe even mundane scale, what makes life "human".
this wonderful combination of dreams we hold in our awake mind and the energy we have that pours out from our bodies is all the gift we ever need to give to ourselves, each other, our (in the broadest sense of "our") children.
we're coming to the, admittedly artificial "end" of the calendar year and i (along with others in the northern hemi) are witnessing the raw embrace of the lull season (winter). soon days will start getting longer again (none to soon, as far as i'm concerned), we'll start using a new number for the year part of dates and that is when my thoughts turn most clearly to the near and distant future of the life-is-art process.
i wonder what things i will stumble upon in the next year, and which things will stumble upon me. i hope that every one of you reading this will experience a moment of contentment in your accomplishment, an "a-ha!" moment of new achievement and the comfort of seeing the recognition of your brilliance, no matter how humbly wrought or magnificently staged, in the eyes of another. i hope you can be those eyes for someone else, as well.
so when it has come time for me to write my "new years resolutions" they, at least this year, are easy to come by: be the eyes of genuine appreciation for someone else; be unafraid to apply great effort to at least one imagining that outpaces my previous ideas; to cherish that which we call life.
i know that i'm a couple weeks early with this sort of topic, but we don't always get to choose when an idea hits us; and when it does, it's time to run with it. =)
the idea of the "creative process" is usually married with the idea of "art", but all of life, well lived, is that process of creation. to see the loaf of bread that does not exist yet, but will once we mix the wet and dry ingredients just right ... to see the dance in the leaves that fall from autumn trees set to music that persists only in our mind ... to make something with our hands, our words, our eyes ... this is that which we call life.
i know that there are those who choose (hopefully unknowingly) to skip over this trail of opportunity, and that there are also those whose world is who torn that this human experience is out of reach ... but for the vast, overwhelming majority of us: it's there as often as we wish it to be. what more do we want to make life meaningful?
i saw and heard something tonight that made me remember just how breathtaking the results can be when people with talent put immense effort into something. it made me remember all the small day-to-day things that are also, if on a more humble and maybe even mundane scale, what makes life "human".
this wonderful combination of dreams we hold in our awake mind and the energy we have that pours out from our bodies is all the gift we ever need to give to ourselves, each other, our (in the broadest sense of "our") children.
we're coming to the, admittedly artificial "end" of the calendar year and i (along with others in the northern hemi) are witnessing the raw embrace of the lull season (winter). soon days will start getting longer again (none to soon, as far as i'm concerned), we'll start using a new number for the year part of dates and that is when my thoughts turn most clearly to the near and distant future of the life-is-art process.
i wonder what things i will stumble upon in the next year, and which things will stumble upon me. i hope that every one of you reading this will experience a moment of contentment in your accomplishment, an "a-ha!" moment of new achievement and the comfort of seeing the recognition of your brilliance, no matter how humbly wrought or magnificently staged, in the eyes of another. i hope you can be those eyes for someone else, as well.
so when it has come time for me to write my "new years resolutions" they, at least this year, are easy to come by: be the eyes of genuine appreciation for someone else; be unafraid to apply great effort to at least one imagining that outpaces my previous ideas; to cherish that which we call life.
i know that i'm a couple weeks early with this sort of topic, but we don't always get to choose when an idea hits us; and when it does, it's time to run with it. =)
Thursday, December 13, 2007
trolltech, phonon and open processes
hot of the presses, here and here: Trolltech has released three new Phonon backends, bringing support for Phonon to all the various operating systems supported by KDE4 and Qt4.
so now in addition to the xine backend on Linux/UNIX, we have gstreamer support (3,598 LOC). for Windows there is a DirectShow 9 backend (3,805 LOC), and for MacOS X there's a QuickTime 7 backend (4,490 LOC).
while great news on its own, there is more to this than "just" the release of three significant new backends for phonon.
this means significant amounts of funded development for Phonon as Trolltech developers will be maintaining these backends as well as contributing to the core Phonon library. Trolltech's motivation? they will be offering Phonon as a component in their commercial Qt offerings starting with Qt 4.4.
as if that wasn't cool enough, Trolltech has put the backends they have written into kdebase where they will be developed and maintained in the open with the rest of the KDE project.
on top of that, the plugins are released under the LGPL license.
as a final flourish, Trolltech's marketing department and KDE's communications team worked together to write up press releases and coordinate the timing of the public announcements.
open repositories, open development, marketing colaboration and licensing aligned with the given situation.
this is a significant step forward in what has been an ongoing process of improving the community interaction at Trolltech, adding to past strides such as Trolltech Labs, community blogging (both on labs as well as planet kde), a public task tracker, an open git repository for QtWebkit, official Qt liasons for KDE on kde-core-devel, organizing and funding open source development meetings and conferences ...
it also demonstrates how the KDE umbrella provides common working ground for a wide variety of participants by providing equitable ways for everyone to work hand-in-hand as partners. it can be tricky at times to balance the needs, motivations and energies of volunteers, researchers and corporate entities alike in a wide-open project, but we are gathering more and more experience on how to successfully accomplish just that.
and with the help of Phonon we'll be able to watch it all go down in technicolour brilliance with thundering surround sound. ;)
so now in addition to the xine backend on Linux/UNIX, we have gstreamer support (3,598 LOC). for Windows there is a DirectShow 9 backend (3,805 LOC), and for MacOS X there's a QuickTime 7 backend (4,490 LOC).
while great news on its own, there is more to this than "just" the release of three significant new backends for phonon.
this means significant amounts of funded development for Phonon as Trolltech developers will be maintaining these backends as well as contributing to the core Phonon library. Trolltech's motivation? they will be offering Phonon as a component in their commercial Qt offerings starting with Qt 4.4.
as if that wasn't cool enough, Trolltech has put the backends they have written into kdebase where they will be developed and maintained in the open with the rest of the KDE project.
on top of that, the plugins are released under the LGPL license.
as a final flourish, Trolltech's marketing department and KDE's communications team worked together to write up press releases and coordinate the timing of the public announcements.
open repositories, open development, marketing colaboration and licensing aligned with the given situation.
this is a significant step forward in what has been an ongoing process of improving the community interaction at Trolltech, adding to past strides such as Trolltech Labs, community blogging (both on labs as well as planet kde), a public task tracker, an open git repository for QtWebkit, official Qt liasons for KDE on kde-core-devel, organizing and funding open source development meetings and conferences ...
it also demonstrates how the KDE umbrella provides common working ground for a wide variety of participants by providing equitable ways for everyone to work hand-in-hand as partners. it can be tricky at times to balance the needs, motivations and energies of volunteers, researchers and corporate entities alike in a wide-open project, but we are gathering more and more experience on how to successfully accomplish just that.
and with the help of Phonon we'll be able to watch it all go down in technicolour brilliance with thundering surround sound. ;)
Wednesday, December 12, 2007
birthing plasmoids
what happens when a plasmoid gets created?
backing up a bit: what is a plasmoid in the first place? it's a native plasma applet. since we also support superkaramba themes and in 4.1 will have MacOS dashboard widget support (the code is there, we're just waiting on a release of webkit which will happen in the first part of '08), we needed a way to disambiguate between these guest widgets and plasma widgets which use the plasma framework fully. superkaramba themes in kde4 can straddle that fence somewhat, and i'd not be surprised to see other widget types be supported in the future either.
ok, so that's a plasmoid. now, what happens when we create one? here's the general play-by-play as seen by an applet written in c++:
creation: the constructor is called. this is when a reasonable default size should be set with setSize. it is still in a bit of a limbo situation at this point, however. it doesn't have an associated containment nor has its configuration been set up yet. so other than setting some basic flags and a default initial size, nothing else should be done here.
basic configuration: now some basic configuration data is read and applied for the plasmoid: geometry, location, containment. the plasmoid itself doesn't actually do anything here, as this is automatic.
initialization: the init() method is now called and the applet can now read any special configuration data unique to the applet and set up resources such as SVGs that are necessary for proper operation and display. configuration dialogs and other on demand pieces should probably not be created here, as that will only slow down start up.
it is important to remember that any applet may appear 0, 1 or more times in the same or different containments. to accomodate this, there is both a per-instance configuration object (fetched via the config() method) as well one that is shared by all instances of the same kind of applet (accessed via the globalConfig() method).
via kconfig's nested groups, plasmoids can create as many config groups as needed or desired. example code might look like:
the choice of colors above is probably not the greatest as an example, actually, since Plasma::Theme provides access to a KColorScheme which matches and compliments the plasma svg theme in use.
backing up a bit: what is a plasmoid in the first place? it's a native plasma applet. since we also support superkaramba themes and in 4.1 will have MacOS dashboard widget support (the code is there, we're just waiting on a release of webkit which will happen in the first part of '08), we needed a way to disambiguate between these guest widgets and plasma widgets which use the plasma framework fully. superkaramba themes in kde4 can straddle that fence somewhat, and i'd not be surprised to see other widget types be supported in the future either.
ok, so that's a plasmoid. now, what happens when we create one? here's the general play-by-play as seen by an applet written in c++:
creation: the constructor is called. this is when a reasonable default size should be set with setSize. it is still in a bit of a limbo situation at this point, however. it doesn't have an associated containment nor has its configuration been set up yet. so other than setting some basic flags and a default initial size, nothing else should be done here.
basic configuration: now some basic configuration data is read and applied for the plasmoid: geometry, location, containment. the plasmoid itself doesn't actually do anything here, as this is automatic.
initialization: the init() method is now called and the applet can now read any special configuration data unique to the applet and set up resources such as SVGs that are necessary for proper operation and display. configuration dialogs and other on demand pieces should probably not be created here, as that will only slow down start up.
it is important to remember that any applet may appear 0, 1 or more times in the same or different containments. to accomodate this, there is both a per-instance configuration object (fetched via the config() method) as well one that is shared by all instances of the same kind of applet (accessed via the globalConfig() method).
via kconfig's nested groups, plasmoids can create as many config groups as needed or desired. example code might look like:
KConfigGroup cg = config();
KConfigGroup colors(&cg, "Colors");the choice of colors above is probably not the greatest as an example, actually, since Plasma::Theme provides access to a KColorScheme which matches and compliments the plasma svg theme in use.
out-thinking words
riddels often rely on subtle word meanings to throw off the puzzle solver, just as jokes often use puns or other word tricks to elicit laughter.
the way we think through a subject can be shaped quite a bit by the words that we use or that are used to describe the initial problem. it takes requires creative effort to overcome the prejudices words can silently put in our minds.
so when we started looking at a replacement for the kmenu, one of the first things i did was stop calling it a 'menu'. because if we ask "what should a new applications menu look like?" we carry over all those prejudices from past experiences with what a menu should be, how it should be presented and what it should contain.
instead i kept refering to this design challenge as the "application launcher interface", or ALI for short. (TLAs are all the rage, dontcha know? ;)
we now have a port of kde3's kickoff, originally developed by SUSE developers, and it doesn't look a whole lot like a menu. i do get questions why it doesn't get drawn more like a "real" menu; this is understandable given the biases we have all developed from using traditional desktop interfaces for so long. but kickoff is not a menu. it's something else. it, like other user interface elements, has things in common with menus, but strictly speaking it isn't one itself.
even more interesting to me, however, are projects like lancelot and raptor which deviate even more from traditional menu concepts than kickoff does.
i don't know how much of this experimenting is due to being free of the word "menu", but i do know that we really didn't see much of this kind of stuff when asking about replacements for the "k menu". i couldn't help but wonder idly today on my way home after lunch if we'd be in the same place had we stuck with traditional or known terminology.
we still have a traditional menu available in plasma, but the other options that are emerging are much more exciting, both visually and use wise.
the way we think through a subject can be shaped quite a bit by the words that we use or that are used to describe the initial problem. it takes requires creative effort to overcome the prejudices words can silently put in our minds.
so when we started looking at a replacement for the kmenu, one of the first things i did was stop calling it a 'menu'. because if we ask "what should a new applications menu look like?" we carry over all those prejudices from past experiences with what a menu should be, how it should be presented and what it should contain.
instead i kept refering to this design challenge as the "application launcher interface", or ALI for short. (TLAs are all the rage, dontcha know? ;)
we now have a port of kde3's kickoff, originally developed by SUSE developers, and it doesn't look a whole lot like a menu. i do get questions why it doesn't get drawn more like a "real" menu; this is understandable given the biases we have all developed from using traditional desktop interfaces for so long. but kickoff is not a menu. it's something else. it, like other user interface elements, has things in common with menus, but strictly speaking it isn't one itself.
even more interesting to me, however, are projects like lancelot and raptor which deviate even more from traditional menu concepts than kickoff does.
i don't know how much of this experimenting is due to being free of the word "menu", but i do know that we really didn't see much of this kind of stuff when asking about replacements for the "k menu". i couldn't help but wonder idly today on my way home after lunch if we'd be in the same place had we stuck with traditional or known terminology.
we still have a traditional menu available in plasma, but the other options that are emerging are much more exciting, both visually and use wise.
Monday, December 10, 2007
good news on a monday? bring it on!
first, bille reports that even with full debug and all the pretty bells and whistles turned on kde4 runs rather well already on a 1GHz system with 256MB of RAM. what will happen when we optimize things even further in future releases? new technology, better (and more) features ... while keeping the same or smaller footprint. are we finally nearing the end of the era when each successive release of desktop software requires more horsepower? well, at least in the free software world; seems people like Microsoft are still having a hard time figuring this trick out, what with nary a mention of Vista on low end devices like the eee pc; it's always XP-on-$DEVICE noise.
meanwhile, over on it wire Sam Varghese has these nice words for the koffice developers and their position statement on ooxml:
more plasmoid hackers continue to show up in my inbox, and many of the bugs being reported on b.k.o against plasma are actually already fixed which means we're edging ahead of the curve.
there is softly fluttering snow on a not-too-cold day outside, and lots of sunshine.
it's such a smoothly going day that i might never have guessed it was monday had the calendar not said so ;)
meanwhile, over on it wire Sam Varghese has these nice words for the koffice developers and their position statement on ooxml:
".. in a world of weasel words, it is refreshing to see that a group can enunciate a principled stand so clearly and with no ambiguity at all."
more plasmoid hackers continue to show up in my inbox, and many of the bugs being reported on b.k.o against plasma are actually already fixed which means we're edging ahead of the curve.
there is softly fluttering snow on a not-too-cold day outside, and lots of sunshine.
it's such a smoothly going day that i might never have guessed it was monday had the calendar not said so ;)
weekends are supposed to be relaxing, right?
at the end of a long weekend at the end of an even longer week, it strikes me that i need to make next weekend a relaxing one so as provide some punctuation to the pace of things. this weekend was awesome though, no mistake about that.
fixed stuff in the pager (mostly performance and sizing behaviours), reviewed a bunch of patches, did some performance reviews and bug hunting, caught up on some kde4 marketing and communications stuff, went to a move with p., finished christmas shopping, wrapped gifts, cleaned house, went to an irish restaurant with p and his aunt to listen to some traditional irish music (played by people with real irish accents, no less =) ... as well as the usual miscellany. pretty much non-stop go-go. i wouldn't trade a moment of it, though i could use an extra sunday tomorrow ;)
for the wrapping gifts part, i try and do something a bit more interesting than simply buying brightly coloured paper to wrap stuff up in. i don't always succeed, but on occasion i do. this year i've wrapped the holiday gifts in tibetan prayer flags. turned out a bit better than i'd expected and it's definitely on the different side. whee. =)
fixed stuff in the pager (mostly performance and sizing behaviours), reviewed a bunch of patches, did some performance reviews and bug hunting, caught up on some kde4 marketing and communications stuff, went to a move with p., finished christmas shopping, wrapped gifts, cleaned house, went to an irish restaurant with p and his aunt to listen to some traditional irish music (played by people with real irish accents, no less =) ... as well as the usual miscellany. pretty much non-stop go-go. i wouldn't trade a moment of it, though i could use an extra sunday tomorrow ;)
for the wrapping gifts part, i try and do something a bit more interesting than simply buying brightly coloured paper to wrap stuff up in. i don't always succeed, but on occasion i do. this year i've wrapped the holiday gifts in tibetan prayer flags. turned out a bit better than i'd expected and it's definitely on the different side. whee. =)
Saturday, December 08, 2007
a busy day doing apparently nothing
today was busy. but it seems i got nothing "real" done. phone calls, emails, prep work for 4.x and some time spent with the p-man. but very little code. blarg. i'm not sure if it's exactly healthy to measure my life in terms of lines of code, but there you go.
we've got a nasty bug in plasma that's showing itself with intel chipsets and the new xrandr which allows for hot plug monitors. essentially the driver lies to us and says that the newly plugged monitor and the existing one (e.g. the built in lcd on the laptop) are both at (0, 0). so plasma happily puts two desktops there, which leads to neat overlapping desktops. and by neat i meant "what a horrid bug".
i wrote to Keith Packard about it and his reply was essentially that it's up to me to find some way to work around it because he can't guarantee the position or order of monitors at runtime, though i find it hard to believe that even the driver itself doesn't know at *some* point, especially ones both are actually advertised as displaying content. apparently Keith and friends consider this interesting behaviour "par for the course" and expected. i'm disappointed, and i'm not the only one given what i've heard from others working on other projects who are dealing with this same issue. so much for sane software, right? not sure how i'm going to hack around this.
i filed a bug against gtk+ and their argb problems. the gtk+ people have said that they don't accept that the code in plasma is "valid" even though it works with every other toolkit out there. nothing like sluffing off your crashers with "well, you shouldn't do that anyways!" in any case, frederikh came up with a small patch for x.org that could prevent this being a problem for anyone, which is probably an even nicer approach since it fixes things lower in the stack rather having to rely on the good sense of the larger number of people writing code higher up.
good news, however: i got email from nvidia today (hi Ignacio!) letting me know that the argb bug has been fixed. the next driver release will contain the fix, and they'll be letting me know when that comes out so i can help point people with these issues to it.
interesting that the open source projects are less responsive when dealing with on this matter.
in other news, i'm supposed to be doing an interview over skype with the linux action show boys any minute now to talk about the rc1 debacle and kde4 in general ... i've settled back with a glass of wolf blass '04 unwooded chardonay and some cheese and crackers to get in the mood. p is asleep and the house is quiet and warm and clean.
i hope all of you have an excellent weekend. =)
we've got a nasty bug in plasma that's showing itself with intel chipsets and the new xrandr which allows for hot plug monitors. essentially the driver lies to us and says that the newly plugged monitor and the existing one (e.g. the built in lcd on the laptop) are both at (0, 0). so plasma happily puts two desktops there, which leads to neat overlapping desktops. and by neat i meant "what a horrid bug".
i wrote to Keith Packard about it and his reply was essentially that it's up to me to find some way to work around it because he can't guarantee the position or order of monitors at runtime, though i find it hard to believe that even the driver itself doesn't know at *some* point, especially ones both are actually advertised as displaying content. apparently Keith and friends consider this interesting behaviour "par for the course" and expected. i'm disappointed, and i'm not the only one given what i've heard from others working on other projects who are dealing with this same issue. so much for sane software, right? not sure how i'm going to hack around this.
i filed a bug against gtk+ and their argb problems. the gtk+ people have said that they don't accept that the code in plasma is "valid" even though it works with every other toolkit out there. nothing like sluffing off your crashers with "well, you shouldn't do that anyways!" in any case, frederikh came up with a small patch for x.org that could prevent this being a problem for anyone, which is probably an even nicer approach since it fixes things lower in the stack rather having to rely on the good sense of the larger number of people writing code higher up.
good news, however: i got email from nvidia today (hi Ignacio!) letting me know that the argb bug has been fixed. the next driver release will contain the fix, and they'll be letting me know when that comes out so i can help point people with these issues to it.
interesting that the open source projects are less responsive when dealing with on this matter.
in other news, i'm supposed to be doing an interview over skype with the linux action show boys any minute now to talk about the rc1 debacle and kde4 in general ... i've settled back with a glass of wolf blass '04 unwooded chardonay and some cheese and crackers to get in the mood. p is asleep and the house is quiet and warm and clean.
i hope all of you have an excellent weekend. =)
Friday, December 07, 2007
notes on some common plasma observations
Christian noted a few things on his blog entry on kde4 about plasma that i wanted to reply to, but comments are disabled on that blog posting apparently. so i'll just respond to them here instead, since i assume others are likely interested in the answers too =)
periodic saving will be implemented, though possibly after 4.0, depending on how a few other items go. i don't want to repeat the mess we had in kicker where applets would sync() various different files (2 or more per applet in some cases) on every possible change. that's not nice on the disk.
we now share one config file per corona, so this opens the possibility of one global sync(). what's missing is a way for applets to tell plasma that they would like a sync to be done. unfortunately the KConfig classes provide no notification on local change nor do they even provide a way to tell if the config is dirty (that's part of the private API only). so we need to provide a way for plasma plugins of various ilk to request a config saving. then plasma can schedule one (probably with a short delay in case several requests are made in a short timeframe, something that is fairly typical in various situations).
as for crashes, please send backtraces of such events. =)
known issue; the rotation is saved but the restore code is broken currently. my bad.
will be addressed soon.
it has nothing to do with acceleration or not and everything to do with the fact that QGraphicsView's clipping implementation is currently quite simplistic to the point of naivety. this causes massive amounts of unnecessary repainting when clipping objects (among other things, such as some interesting event propagation issues). fortunately Andreas knows all about these issues and is working on them. by kde 4.1 we should have a better behaved clipping implementation, if not sooner.
if you don't have shaders, and the applet uses shaders, there's not much that can be done except rewrite the applet to not use shaders. Plasma::GlApplet does not require shaders itself, but some applets, such as the bluemarble 3d globe (no relation to marble, the kde4 mapping widget, btw) do. so you can use OpenGL applets on your system .. just not the ones requiring more advanced hardware and/or drivers.
hope that clears a few things up.
"[Plasma] works quite well already, although it crashes from time to time and then my plasmoid settings are not saved."
periodic saving will be implemented, though possibly after 4.0, depending on how a few other items go. i don't want to repeat the mess we had in kicker where applets would sync() various different files (2 or more per applet in some cases) on every possible change. that's not nice on the disk.
we now share one config file per corona, so this opens the possibility of one global sync(). what's missing is a way for applets to tell plasma that they would like a sync to be done. unfortunately the KConfig classes provide no notification on local change nor do they even provide a way to tell if the config is dirty (that's part of the private API only). so we need to provide a way for plasma plugins of various ilk to request a config saving. then plasma can schedule one (probably with a short delay in case several requests are made in a short timeframe, something that is fairly typical in various situations).
as for crashes, please send backtraces of such events. =)
"If I log out and log back in plasmoids lose there rotation setting."
known issue; the rotation is saved but the restore code is broken currently. my bad.
"The panel is not configurable yet and I have problems removing applets therefore."
will be addressed soon.
"KNewsticker, which is actually in extragear stresses my CPU quite much here, since the animation seems to be completely done (I can remember the same issue with the KDE3 applet) without graphics acceleration.
it has nothing to do with acceleration or not and everything to do with the fact that QGraphicsView's clipping implementation is currently quite simplistic to the point of naivety. this causes massive amounts of unnecessary repainting when clipping objects (among other things, such as some interesting event propagation issues). fortunately Andreas knows all about these issues and is working on them. by kde 4.1 we should have a better behaved clipping implementation, if not sooner.
"I am also a bit confused since plasmoids claim that OpenGL shaders are not supported here. It is right that Intel chipsets (at least <965) have no hardware accelerated shaders, but I can at least render stuff, e.g. Google Maps, Nexuiz, VDrift here, even if they perform badly. So in my opinion that should be configurable, since small OpenGL animations would work.
if you don't have shaders, and the applet uses shaders, there's not much that can be done except rewrite the applet to not use shaders. Plasma::GlApplet does not require shaders itself, but some applets, such as the bluemarble 3d globe (no relation to marble, the kde4 mapping widget, btw) do. so you can use OpenGL applets on your system .. just not the ones requiring more advanced hardware and/or drivers.
hope that clears a few things up.
glasses for p.
took p. to the optometrist today since he had been complaining that his left eyes was blury. the end result is that he's getting glasses, pretty strong ones at that. apparently he has refractive amblyopia, though it was very well masked since both eyes look completely normal and healthy and he's been compensating rather perfectly with his right eye. but a thorough checking showed it up today and now he's getting glasses. he'll never have perfect vision in his left eye, but they expect it to get pretty good and that as an adult he could have it corrected with laser surgery should he so choose.
thankfully he's got a great face for glasses and the frames he picked out look awesome on him =)
thankfully he's got a great face for glasses and the frames he picked out look awesome on him =)
Thursday, December 06, 2007
free speech and good citizenship
Mark, i'm not sure from reading your blog entry on free speech if this is what you were getting at, but it was vague enough that i want to address it anyways: i never said people should be silent. rather, i asked people to share their concerns in a way that is useful. that is a very different request from "try[ing to] force people not to say certain things".
in a project such as kde there is no point in leveling complaints in a way that will not lead to resolution of those issues. doubly so when you use your free speech to harm, harass and belittle others for no other reason than to harm harass and belittle. just as with any act of violence, violence spoken should be met with resistance. (if you don't believe that there is such a thing as violence spoken, read up on the issue of verbal and emotional abuse.)
you say that the "best way to confront idiotic or bigotted (sic) views is through public debate where they can be reasoned with rather than ignored", but this completely ignores the effect such idiotic an bigoted eruptions have on the health of the community. i have no issue with someone finding something to complain about; i do have issue with someone bringing it to the project in a non-constructive manner. the cost to the project of having no social contract in play when it comes to such discourse is simply too high to bear.
i do completely agree with you on the matter of free speech being something to be protected even when we don't agree with the content of it, however there is the related topic of the responsibility that one needs to exercise when engaging in free speech out of respect for both the right itself as well as for others. when someone does not exercise that responsibility, it is completely my right to not listen to them and even to remove them from my personal areas.
this community of ours is a shared personal area. it is a choice to participate in a free software project, not a right nor something you are predisposed to at birth. therefore your right, as well as mine, to engage in free speech must be respected as a general principle in life, but it need not be allowed to infringe on the health and well-being of the project.
to put in practical terms: there is a good reason we flag things as off-topic on mailing lists, and even have lists that are moderated.
in a project such as kde there is no point in leveling complaints in a way that will not lead to resolution of those issues. doubly so when you use your free speech to harm, harass and belittle others for no other reason than to harm harass and belittle. just as with any act of violence, violence spoken should be met with resistance. (if you don't believe that there is such a thing as violence spoken, read up on the issue of verbal and emotional abuse.)
you say that the "best way to confront idiotic or bigotted (sic) views is through public debate where they can be reasoned with rather than ignored", but this completely ignores the effect such idiotic an bigoted eruptions have on the health of the community. i have no issue with someone finding something to complain about; i do have issue with someone bringing it to the project in a non-constructive manner. the cost to the project of having no social contract in play when it comes to such discourse is simply too high to bear.
i do completely agree with you on the matter of free speech being something to be protected even when we don't agree with the content of it, however there is the related topic of the responsibility that one needs to exercise when engaging in free speech out of respect for both the right itself as well as for others. when someone does not exercise that responsibility, it is completely my right to not listen to them and even to remove them from my personal areas.
this community of ours is a shared personal area. it is a choice to participate in a free software project, not a right nor something you are predisposed to at birth. therefore your right, as well as mine, to engage in free speech must be respected as a general principle in life, but it need not be allowed to infringe on the health and well-being of the project.
to put in practical terms: there is a good reason we flag things as off-topic on mailing lists, and even have lists that are moderated.
rocKstar of the day
today Sebastian Sauer rocked the plasma by finishing off the simple classic k-menu style app launcher. it uses the same core code as kickoff, but presents the results as a simple menu. that's how you complain in the free software world: with bug reports, feedback and ultimately patches.
Sebastian: i owe you a pint next time we meet up =)
Sebastian: i owe you a pint next time we meet up =)
Wednesday, December 05, 2007
argb updates
a quick update on the argb hell i'm living in. it seems that the scrolling bug is only visible with the proprietary nvidia drivers. awesome.
anyways, zack came up with this patch for those affected in the meantime. update: turns out the patch provenance and discovery of the nvidia relatedness of the problem goes back to frederikh
apparently it has to do with tiles used during rendering pointing to invalidated surfaces after dma flushes. so qt is doing the right thing apparently, but the driver gets in the way. this makes it doubtful the patch will go into qt itself as it's slower. if this is indeed an nvidia problem (which we can only guess at, but that's a good guess based on the fact that it only seems to happen with those drivers) they need to fix their stuff. if it were open source, maybe we could help them, but its not and so we're screwed until the boys at nvidia Do The Right Thing(tm) on our behalf. score one for proprietary code.
i've also filed a bug report against gtk for the systray problem. in conversation with one of the plasma devs, a gtk dev referred to this problem as a "feature request". i hope that was just a misinterpretation of the issue and that the gtk team doesn't view crash inducing bugs as feature requests; i'm sure they don't =) in any case, they are set to do a release in early january from what i understand, so with some luck this could even be fixed in time for kde 4.0.
anyways, zack came up with this patch for those affected in the meantime. update: turns out the patch provenance and discovery of the nvidia relatedness of the problem goes back to frederikh
apparently it has to do with tiles used during rendering pointing to invalidated surfaces after dma flushes. so qt is doing the right thing apparently, but the driver gets in the way. this makes it doubtful the patch will go into qt itself as it's slower. if this is indeed an nvidia problem (which we can only guess at, but that's a good guess based on the fact that it only seems to happen with those drivers) they need to fix their stuff. if it were open source, maybe we could help them, but its not and so we're screwed until the boys at nvidia Do The Right Thing(tm) on our behalf. score one for proprietary code.
i've also filed a bug report against gtk for the systray problem. in conversation with one of the plasma devs, a gtk dev referred to this problem as a "feature request". i hope that was just a misinterpretation of the issue and that the gtk team doesn't view crash inducing bugs as feature requests; i'm sure they don't =) in any case, they are set to do a release in early january from what i understand, so with some luck this could even be fixed in time for kde 4.0.
(updated: i just fixed the links in this entry; i keep forgetting that kblogger does rich text so typing the link tags manually isn't what i should be doing. all this new-fangled technology, i swear ;))
new years!
got tickets today to a new years party at the university of calgary campus where Alexis On Fire will be playing as the headliners. yay! new years with co-eds! ;)
argb visuals
x.org can do some pretty cool things these days. everyone knows all about compositing window managers, like kwin 4 and compiz, to name two.
but the fun isn't relegated to the window managers! you can set an argb (alpha, red, green, blue) visual for your application and play with translucency, shaped windows and what not to produce some rather nice visual effects.
plasma has a history of pushing the boundaries of the technologies it uses. this happens because the plasma team looks around, sees what is possible and we imagine what that could be .... and then we write the code to make it happen.
unfortunately in the case of making it happen with argb visuals, it seems that nobody other than window managers are using these things. how do i know? because none of the toolkits actually frigging work properly with them.
Qt has visible painting bugs in scrollable widgets when there is an argb visual.
Gtk+ apps crash when the system tray icon is placed in an app using an argb visual since it apparently can't deal with having the background set with XSetWindowBackgroundPixmap on an XEmbed client window in that particular case. unfortunately, to make the icons work at all properly in an argb window we need to do exactly that.
(i, or someone like me, needs to file a bug against gtk about this. i only tracked this down last night and confirmed the cause, which is why i haven't yet.)
but plasma only really shines with argb visuals: translucent panels, a see-through dashboard, etc.
so now i'm conflicted.
do i release plasma in all its shining glory and show the toolkits to be buggy when it comes to handling argb visuals?
or do i retreat, like probably every other serious app that may have gone before me, and make plasma look less hot (excuse the pun ;) but work properly?
i'm leaning towards "show up the toolkits" for two reasons: a) i really don't like the idea of hobbling our app because of other people's bugs, b) if nobody uses argb visuals, i fear that the toolkit projects will never prioritize the necessary fixes.
it's fun being at the edge of the technology, but they do call it the "bleeding" edge for a reason. well, that's sort of ignoring the fact that we've had argb support in x.org for a while now.
but the fun isn't relegated to the window managers! you can set an argb (alpha, red, green, blue) visual for your application and play with translucency, shaped windows and what not to produce some rather nice visual effects.
plasma has a history of pushing the boundaries of the technologies it uses. this happens because the plasma team looks around, sees what is possible and we imagine what that could be .... and then we write the code to make it happen.
unfortunately in the case of making it happen with argb visuals, it seems that nobody other than window managers are using these things. how do i know? because none of the toolkits actually frigging work properly with them.
Qt has visible painting bugs in scrollable widgets when there is an argb visual.
Gtk+ apps crash when the system tray icon is placed in an app using an argb visual since it apparently can't deal with having the background set with XSetWindowBackgroundPixmap on an XEmbed client window in that particular case. unfortunately, to make the icons work at all properly in an argb window we need to do exactly that.
(i, or someone like me, needs to file a bug against gtk about this. i only tracked this down last night and confirmed the cause, which is why i haven't yet.)
but plasma only really shines with argb visuals: translucent panels, a see-through dashboard, etc.
so now i'm conflicted.
do i release plasma in all its shining glory and show the toolkits to be buggy when it comes to handling argb visuals?
or do i retreat, like probably every other serious app that may have gone before me, and make plasma look less hot (excuse the pun ;) but work properly?
i'm leaning towards "show up the toolkits" for two reasons: a) i really don't like the idea of hobbling our app because of other people's bugs, b) if nobody uses argb visuals, i fear that the toolkit projects will never prioritize the necessary fixes.
it's fun being at the edge of the technology, but they do call it the "bleeding" edge for a reason. well, that's sort of ignoring the fact that we've had argb support in x.org for a while now.
tagging freeze
today we are in a tagging freeze so Dirk can tag up another pre-release that will go out next week. i spent the day today addressing various little bugs that have come up for commit after the freeze lifts. so nothing exciting or particularly interesting, but the kind of stuff that needs to get done.
we got our flight bookings for the family holidays in florida, so now i'm booked for 5 days in the sun at the end of the month in addition to the mountainview release event and linux.conf.au in january. busy couple of months ahead; i wouldn't be able to do it had friends and family not stepped up to help out with things here in calgary, particularly the p-man.
we got our flight bookings for the family holidays in florida, so now i'm booked for 5 days in the sun at the end of the month in addition to the mountainview release event and linux.conf.au in january. busy couple of months ahead; i wouldn't be able to do it had friends and family not stepped up to help out with things here in calgary, particularly the p-man.
Tuesday, December 04, 2007
kblogger ... works!
got an email today from one of the kblogger devs saying that the gdata backed works. this is a test entry i'm writing using kblogger from svn, and so far things look good.
for an app that's still in playground and rather new, i'm pretty impressed with the current state of affairs. it even imported the media (mostly pictures) i've used in previous entries. neat.
getting the blog ID out of blogger.com was a bit of a pain, though. had to hunt around the blogger interface for it, finally noticed it in some of the link urls on the dashboard pages while mousing over them.
other than that, it's been a pretty slick experience thus far. i'm not sure i'm a big fan of the progress dialogs, but then i hate popups in general. however, that's a small price to pay if this means i don't have to deal with a web browser to blog anymore.
colour me happy.
i can't wait to see what this app becomes when kde 4.1 rolls around.
(p.s. i just noticed that there is a kicker applet called kblogger. they don't seem to be related ... though the applet kblogger's webpage uses the same (generic) kde blogging icon =)
for an app that's still in playground and rather new, i'm pretty impressed with the current state of affairs. it even imported the media (mostly pictures) i've used in previous entries. neat.
getting the blog ID out of blogger.com was a bit of a pain, though. had to hunt around the blogger interface for it, finally noticed it in some of the link urls on the dashboard pages while mousing over them.
other than that, it's been a pretty slick experience thus far. i'm not sure i'm a big fan of the progress dialogs, but then i hate popups in general. however, that's a small price to pay if this means i don't have to deal with a web browser to blog anymore.
colour me happy.
i can't wait to see what this app becomes when kde 4.1 rolls around.
(p.s. i just noticed that there is a kicker applet called kblogger. they don't seem to be related ... though the applet kblogger's webpage uses the same (generic) kde blogging icon =)
Monday, December 03, 2007
plasma, patches and parallelism
i have three emails open and waiting for me in the morning, each with a patch set that i have to look over, possibly debug, hopefully give the thumbs up to. for bigger patches the review process can often take a few iterations; i'm constantly afraid people will run away due to having to deal with someone who can be a bit anal about things at times. really, i just want to see decent design and make sure that we cover as many of the issues as well as possible. this results in a slightly slower development pace at times, but hopefully it increases the overall speed of development as we don't have to constantly re-do things over and over. in fact, it's been the patch sets that i've said, "yeah, sure, just throw it in i'll look at it later" that have caused plasma the most grief. so to all the other plasma hackers out there: thanks for sticking through the review process. if it's any consolation, you not only keep me busy, you often push my abilities (such as being to keep up with N conversations at once, or deal with things as disparate as threading, geometry and packaging issues). which i actually enjoy =)
the Package* classes just recently went through a small refactoring to make them more real-world usable. due to the house cleaning frenzy today i didn't get to a screencast (or much hacking for that matter), though i really want to do one on the package stuff so people can see how cool it is even now. thanks go to Paolo Capriotti for doing the majority of the grunt work there.
krunner is now multithreaded. after a couple weeks of kicking around design issues and patches with me on the plasma-devel list, Ryan Bitanga committed the full kit and kaboodle today. the difference in responsiveness is remarkable. unfortunately, if you really try hard and abuse the line edit in krunner you can run out of available threads due to runners lagging behind. this is because instead of trying to make runners interuptable, we let them run even if the user has moved on. so if you are especially devilish you can stack up enough runners that you have to wait a few seconds for them all to return (there's a 4 thread maximum, making for a long queue). the upside to this approach was a small number of locks needed in the code and keeping it very simple to write runners. in fact, when writing a runner you hardly notice there's anything thread like going on at all. pretty neat. we will be implementing optional abort support in runners that have nasty running times as well as tweaking the start-the-match-process algorithm a bit to improve this last point, even though you really pretty much need to be trying to trigger this behaviour. still, good apps should work well in as many situations as possible. i'm just stoked to see threading in krunner.
there's also a patch set on the list for threading svg rendering that i need to look at.
i also put out a call asking for what is ready to be pulled over from playground. the way things work in plasma generally is that new development on plugins (of which there are 6 types now, each for a different sort of thing =) or major new additions that don't substantially build on existing code happen in playground. this way anyone can work on anything they want without having to have "working" code or even do something that anyone else thinks it productive. it's amazing just how much working code for useful things comes out of there, though. ;) the plasma team's job then becomes to pull the good stuff from playground into extragear or kdebase. this isn't completely dissimilar to how one might work with a decentralized system, except it's within the capabilities (or limitations, depending how you see it =) of a centralized system like svn.
it looks like there are a handful of new applets, runners and engines that will be crossing over into extragear soon. post 4.0, we'll be doing regular releases of the stuff in extragear. so while the kdebase things will likely follow the more docile kdelibs-driven release schedule, we'll get much more often plasma refreshes out of extragear. i still want to release [lib]plasma packages for testers on a more agressive basis as well, but we'll see how that pans out before 4.1.
the downside to this development system is that i will at some point become a bottleneck to the process, at least if plasma gets anywhere near the scope i want it to. before that happens, i'm aware that there will be need for others in the project who are well versed enough in the concepts and code that they can take on these things as well. i think we're getting close to that point with a couple of people already, though until 4.0 is out and i have time to write more documentation about the design, purpose and implementation seen within plasma that process is somewhat hampered.
another downside is that indeed some people can't hack the less free-for-all mentality, especially for libplasma. however, there are so many people that continue to contribute quality stuff to plasma on a regular, repeat basis that it's evidently not that bad.
still, i am open to feedback from those involved as to how to make things better. (besides, "use git" .. yes, i'm looking at you Ruphy ;)
the Package* classes just recently went through a small refactoring to make them more real-world usable. due to the house cleaning frenzy today i didn't get to a screencast (or much hacking for that matter), though i really want to do one on the package stuff so people can see how cool it is even now. thanks go to Paolo Capriotti for doing the majority of the grunt work there.
krunner is now multithreaded. after a couple weeks of kicking around design issues and patches with me on the plasma-devel list, Ryan Bitanga committed the full kit and kaboodle today. the difference in responsiveness is remarkable. unfortunately, if you really try hard and abuse the line edit in krunner you can run out of available threads due to runners lagging behind. this is because instead of trying to make runners interuptable, we let them run even if the user has moved on. so if you are especially devilish you can stack up enough runners that you have to wait a few seconds for them all to return (there's a 4 thread maximum, making for a long queue). the upside to this approach was a small number of locks needed in the code and keeping it very simple to write runners. in fact, when writing a runner you hardly notice there's anything thread like going on at all. pretty neat. we will be implementing optional abort support in runners that have nasty running times as well as tweaking the start-the-match-process algorithm a bit to improve this last point, even though you really pretty much need to be trying to trigger this behaviour. still, good apps should work well in as many situations as possible. i'm just stoked to see threading in krunner.
there's also a patch set on the list for threading svg rendering that i need to look at.
i also put out a call asking for what is ready to be pulled over from playground. the way things work in plasma generally is that new development on plugins (of which there are 6 types now, each for a different sort of thing =) or major new additions that don't substantially build on existing code happen in playground. this way anyone can work on anything they want without having to have "working" code or even do something that anyone else thinks it productive. it's amazing just how much working code for useful things comes out of there, though. ;) the plasma team's job then becomes to pull the good stuff from playground into extragear or kdebase. this isn't completely dissimilar to how one might work with a decentralized system, except it's within the capabilities (or limitations, depending how you see it =) of a centralized system like svn.
it looks like there are a handful of new applets, runners and engines that will be crossing over into extragear soon. post 4.0, we'll be doing regular releases of the stuff in extragear. so while the kdebase things will likely follow the more docile kdelibs-driven release schedule, we'll get much more often plasma refreshes out of extragear. i still want to release [lib]plasma packages for testers on a more agressive basis as well, but we'll see how that pans out before 4.1.
the downside to this development system is that i will at some point become a bottleneck to the process, at least if plasma gets anywhere near the scope i want it to. before that happens, i'm aware that there will be need for others in the project who are well versed enough in the concepts and code that they can take on these things as well. i think we're getting close to that point with a couple of people already, though until 4.0 is out and i have time to write more documentation about the design, purpose and implementation seen within plasma that process is somewhat hampered.
another downside is that indeed some people can't hack the less free-for-all mentality, especially for libplasma. however, there are so many people that continue to contribute quality stuff to plasma on a regular, repeat basis that it's evidently not that bad.
still, i am open to feedback from those involved as to how to make things better. (besides, "use git" .. yes, i'm looking at you Ruphy ;)
KIO::file_move(house.contents(), "/dev/null");
p's mom brought over a bunch of his stuff that had been at her house; so now we had enough stuff for two houses. it didn't help that she didn't sort through any of the stuff and half of the things she brought over were junk or things he'd outgrown.
now, i live in a small house. this is purposeful for a few reasons, one of which is it keeps my material belongings down simply due to the amount of space i have. or rather, don't have. so the place had begun to look a bit like a warehouse this past week due to the sudden influx of things.
it also hadn't helped that during the last couple weeks m. was still here i put in as many hours as i could(n't) spare working on kde4. this meant that the state of the kitchen isn't what it should've been and the living room / home office had become ... chaotic.
today we went about fixing that.
we spent from late morning until late afternoon organizing, sorting, moving, stowing and getting rid of all sorts of things. not only did we manage to sort through p's various amusements and get them down to a reasonable number, we pulled all the books off the bookshelves in the various rooms and consolidated them onto the two bookshelves in the living room. i got rid of the stereo i no longer use (though didn't have time to also find a new home for the speakers), cleaned the kitchen and tidied the master bedroom for good measure. the difference in the house in remarkable.
we'll have to do this again next weekend to finish that last 10% that takes the other 50% of the time to complete, at which point the house should be back to fully restored order so that when i next have a guest over she doesn't look around and say, "i want to clean your house for you." meh.
now, i live in a small house. this is purposeful for a few reasons, one of which is it keeps my material belongings down simply due to the amount of space i have. or rather, don't have. so the place had begun to look a bit like a warehouse this past week due to the sudden influx of things.
it also hadn't helped that during the last couple weeks m. was still here i put in as many hours as i could(n't) spare working on kde4. this meant that the state of the kitchen isn't what it should've been and the living room / home office had become ... chaotic.
today we went about fixing that.
we spent from late morning until late afternoon organizing, sorting, moving, stowing and getting rid of all sorts of things. not only did we manage to sort through p's various amusements and get them down to a reasonable number, we pulled all the books off the bookshelves in the various rooms and consolidated them onto the two bookshelves in the living room. i got rid of the stereo i no longer use (though didn't have time to also find a new home for the speakers), cleaned the kitchen and tidied the master bedroom for good measure. the difference in the house in remarkable.
we'll have to do this again next weekend to finish that last 10% that takes the other 50% of the time to complete, at which point the house should be back to fully restored order so that when i next have a guest over she doesn't look around and say, "i want to clean your house for you." meh.
Sunday, December 02, 2007
today, besides fixing a crasher in plasma on exit and making KConfig delete groups recursively, p. and i mostly hung out. we went out for brunch together, watched a movie, did some (much needed) house work.
i also noticed that the oxygen window decorations now have a visible border around them so that they no longer get lost in the soup. the visual difference between active/inative window borders and menus are still up for grabs, but the window border improvement takes care of one of the major oxygen showstoppers. i saw people working on the issue on irc the other day, and apparently the work has been integrated. yippee, oxycoders!
i also got some new toys to play with today. one is a qt4 irc client and the other one is what i'm using to write this blog entry.
the qt4 irc client is called quassel. i met the dev team when i was in munich last, which is how i found out about this bad boy. what's so cool about quassel? well, besides being done in qt4, it uses a client/server model. think "screen for gui apps", in particular irc in this case. the quassel client connects tothe quassel server to display and interact with the session; once the client disconnects, however, the server maintains the connection and continues sitting there on irc. next time you fire up your quassel client (there's a desktop one and apparently a phone one, too) it picks up exactly where you were. no long will i need to choose between an always-on irc connection and a graphical client. neat.
the project is still young, and i hope the devs open the repo and do a first alpha release soon. release early and often, right? =) seeing as its usable already, it's just a matter of time.
the other toy i got today was kblogger. it's been in playground for a bit so i figured i'd try it out. after a couple of patches to fix compilation and a crash on configuration on first run, it is up and running. i'm using it to compose this entry, actually.
it has a nice little wysiwyg editor (though the yellow background is a bit overpowering; no more so than a post-it note, though, i suppose) and uses libkblog for the blog stuff. it also uses libkipi to help with images you upload. i've found the media support isn't perfect yet (just got a crash with it) but it is in playground for a reason i suppose ;)
it supports multiple blogs and a handfull of different blog targets already. offline blogging will be ultra handy as i can putter away on the blogs during downtime and then sync when i get to a net connection. will be nice for travel. pretty neat stuff all around. i'll have to keep my eye on this app. =)
hmm.. apparently it only supports blogger v1 right now. that sort of sucks for me. or rather, it means i must resist the urge for a late night hacking session to investigate adding blogger v2 support ;) so while i used kblogger to create the entry and what not, i was forced to retreat back to a web browser to do the actual upload. meh. obligatory screenshot:
i also noticed that the oxygen window decorations now have a visible border around them so that they no longer get lost in the soup. the visual difference between active/inative window borders and menus are still up for grabs, but the window border improvement takes care of one of the major oxygen showstoppers. i saw people working on the issue on irc the other day, and apparently the work has been integrated. yippee, oxycoders!
i also got some new toys to play with today. one is a qt4 irc client and the other one is what i'm using to write this blog entry.
the qt4 irc client is called quassel. i met the dev team when i was in munich last, which is how i found out about this bad boy. what's so cool about quassel? well, besides being done in qt4, it uses a client/server model. think "screen for gui apps", in particular irc in this case. the quassel client connects tothe quassel server to display and interact with the session; once the client disconnects, however, the server maintains the connection and continues sitting there on irc. next time you fire up your quassel client (there's a desktop one and apparently a phone one, too) it picks up exactly where you were. no long will i need to choose between an always-on irc connection and a graphical client. neat.
the project is still young, and i hope the devs open the repo and do a first alpha release soon. release early and often, right? =) seeing as its usable already, it's just a matter of time.
the other toy i got today was kblogger. it's been in playground for a bit so i figured i'd try it out. after a couple of patches to fix compilation and a crash on configuration on first run, it is up and running. i'm using it to compose this entry, actually.
it has a nice little wysiwyg editor (though the yellow background is a bit overpowering; no more so than a post-it note, though, i suppose) and uses libkblog for the blog stuff. it also uses libkipi to help with images you upload. i've found the media support isn't perfect yet (just got a crash with it) but it is in playground for a reason i suppose ;)
it supports multiple blogs and a handfull of different blog targets already. offline blogging will be ultra handy as i can putter away on the blogs during downtime and then sync when i get to a net connection. will be nice for travel. pretty neat stuff all around. i'll have to keep my eye on this app. =)
hmm.. apparently it only supports blogger v1 right now. that sort of sucks for me. or rather, it means i must resist the urge for a late night hacking session to investigate adding blogger v2 support ;) so while i used kblogger to create the entry and what not, i was forced to retreat back to a web browser to do the actual upload. meh. obligatory screenshot:
Saturday, December 01, 2007
webkit opens up more
Maciej Stachowiak, posting from his apple email address, wrote to the kfm-devel mailing list today about the webkit project and the next steps they have taken towards a more fully open and community appropriate set of processes. quote:
he announced two new policy sets for webkit aimed to help address these issues: the committer and reviewer policy and the webkit goals statement.
Maciej then said:
this is exactly the sort of steps Apple needs to continue to make to help bridge the unfortunate divide that had grown from years of doing things in a way that actively discouraged community involvement. i'm sure that some kde devs will still have open issues with the process even with these new steps, but it is important for us to recognize these steps as they happen and encourage Apple, and the other business interests around webkit, to a better and more truly open strategy.
also, if you missed it, tronical recently blogged about the recent progress in the QtWebKit efforts. the interesting bit there is that Trolltech is using a public git repository at code.staikos.net (that's one of George "pmax" Staikos' systems) so that all contributors can have push access to the source repo.
what's interesting is that despite this being a project that has paid developers working on it from inside Trolltech and despite QtWebKit being something that will be shipping with Qt starting in 4.4, they are developing in a third-party hosted repository that is publicly open.
so it is indeed possible for process to improve. it takes engagement and a lot of patience, maybe a little bit of silly optimism as well ;) but it is doable.
we can expect more of these sorts of announcements (though unrelated to webkit stuff) in the comming weeks as well, so stay tuned all you party people. =)
"Many KHTML developers have raised concerns about project governance,
potentially conflicting goals, and the appearance that WebKit is
driven purely by Apple's corporate agenda."
he announced two new policy sets for webkit aimed to help address these issues: the committer and reviewer policy and the webkit goals statement.
Maciej then said:
"I don't know if this addresses all KHTML and KDE contributor concerns
about the possibility of a full re-merge with WebKit. But I hope these
moves will make a good starting point for additional discussion. I am
open to additional discussion about ways to enable closer collaboration."
this is exactly the sort of steps Apple needs to continue to make to help bridge the unfortunate divide that had grown from years of doing things in a way that actively discouraged community involvement. i'm sure that some kde devs will still have open issues with the process even with these new steps, but it is important for us to recognize these steps as they happen and encourage Apple, and the other business interests around webkit, to a better and more truly open strategy.
also, if you missed it, tronical recently blogged about the recent progress in the QtWebKit efforts. the interesting bit there is that Trolltech is using a public git repository at code.staikos.net (that's one of George "pmax" Staikos' systems) so that all contributors can have push access to the source repo.
what's interesting is that despite this being a project that has paid developers working on it from inside Trolltech and despite QtWebKit being something that will be shipping with Qt starting in 4.4, they are developing in a third-party hosted repository that is publicly open.
so it is indeed possible for process to improve. it takes engagement and a lot of patience, maybe a little bit of silly optimism as well ;) but it is doable.
we can expect more of these sorts of announcements (though unrelated to webkit stuff) in the comming weeks as well, so stay tuned all you party people. =)
my heros this week
i've been filtering all the plasma related commits into a folder for a while now so i can pay extra attention to them. something that i really noticed this week was just how many commits come from the translators. they put in so much effort to help ensure that free software is available to so many people in this world. to all of you translators out there: you rock. =)
toma: i agree with you that the release team is working better than most of us could have expected. it's pretty amazing how easily that transition was made, and you're right that it gave kde4 development the kick in the ass it needed. i also agree that it can be even better than it already is. how? like you, toma, i don't have magic answers. but i think that there are signs that we are already finding ways to do things better just by .. well .. doing them and discussing the issues on that list. release team: you rock too..
i also wanted to throw out a "have a great time" to the kde edu people who are having a meeting in paris. wish i could be there, can't wait to see what'll come out of it.
toma: i agree with you that the release team is working better than most of us could have expected. it's pretty amazing how easily that transition was made, and you're right that it gave kde4 development the kick in the ass it needed. i also agree that it can be even better than it already is. how? like you, toma, i don't have magic answers. but i think that there are signs that we are already finding ways to do things better just by .. well .. doing them and discussing the issues on that list. release team: you rock too..
i also wanted to throw out a "have a great time" to the kde edu people who are having a meeting in paris. wish i could be there, can't wait to see what'll come out of it.
Subscribe to:
Posts (Atom)
