KDE Commit-Digest
KDE came to me on the first "proper distro" I ever installed, in its 3.2 incarnation I think (the non proper one being "Floppix" :). I've always preferred it to other environments, sticking with distributions that, at the time, were tailored with KDE in mind. Slackware and Mandrake to name those that survived on my desktop the longest. So fast-forwarding maybe about 6 years I started making the sound theme for my current Kubuntu desktop - I was just bored with Kubuntu's login sound and decided to roll up my sleeves and get it going. The outline of it was done after a few hours, and a few weeks later I decided to post it on kde-look.org. The feedback was rather good, and someone said that it would be nice if Kimper (that was the theme's original name) was the default sound theme for KDE 4... who was I to oppose, right? Then a week later Nuno Pinheiro from the Oxygen icon theme sent me an email and invited me to work a bit more on the theme without too many modifications, because according to him it already had the Oxygen "zen" aura around it. I was shown some mockups of Oxygen's graphical environment and was really blown away by the sheer quality of it, and so a few meetings later I officially started working on the theme to fulfill not only my own audiophile (hah! yeah right!) fetish, but make it a bit more universal.
The idea behind Oxygen's sound theme is really to make it coherent and to have recognizable patterns that will aid the user in awareness of what kind of event is taking place - not by sounding a distinctive and out of place sound, but by enabling the user to recognize a rhythmic pattern within the same sound set. So the sound used is always the same throughout the theme making the user feel "at home", as there are no sharp turns or unexpected or violent mood shifts... just Tao (or so I hope). So with regular usage of the system one starts to recognize that every event that exposes information is portrayed by a single note: an error is a single note followed by a chord, a question is a single note followed by a short melodical phrase and so forth... so there's a rhythmic pattern that distinguishes the sounds; as opposed to other solutions out there, that rely on making the user jump off the chair every time something happens.
The opinions on the theme outside kde-look - and now that it is an official Oxygen project - have been quite mixed. Some people bash it without a moments thought because they play it in their music player of choice and obviously fail to recognize the pattern. I've also read some criticism on the sound used as being "shallow" (what you hear is a 50/50 mix of Electric Piano and Acoustic Piano), whilst others fell in love with it and the developer reaction has been quite nice, since I ended up doing sounds for other applications within KDE in accordance to Oxygen's style (the KDE game Kollision, for example). One of the hardest bits of this whole deal has actually been dealing with the harsh criticism. I think people fail to understand that when it comes to something like artwork there is no consensus. Unlike application development, you can't implement something and not make it clash with something else... adding a feature to artwork usually means a drastic enough alteration to change the whole feel of the piece. You can't please everybody... for the exact same reason you have so many sections in a music store: every one wants to listen to something different.
However, I respect that criticism, and one of the things I'd love to do for KDE 4.1 is two other sound themes with completely different auras to them, so everyone would have 3 themes to choose from and be happy... or at least close!
My experience with the KDE community was great, from "in-house" with the Oxygen team, through to developers looking for sounds for their applications... just great. I'm looking forward to developing the current theme further, adding more distinct themes, and creating more sounds for other applications within KDE. It's been a great experience all together and truly an honor to be a part of the Oxygen team and a contributor to KDE.
Issue 92
6th January 2008 by Danny AllenThis Week...
Final commits for KDE 4.0 Final before the tagging freeze. KDE 4.0 Final tagged for release. Lots of optimisations and bugs fixed across KDE. Kickoff menu items can now be added to the Plasma desktop or panel. Improved resize and rotate for Plasma applets. Document list sorting in Kate. Various progress in KDevelop. Mailody moves towards using Akonadi for its IMAP functionality, various improvements in Akonadi. Start of a KHotNewStuff2 implementation in Kalzium for downloading molecular files. Experimental IVTV support in the Kalva video player. KGet uses more of the shared implementation of BitTorrent from KTorrent. Printing support for the DVI backend in okular. Improved text handling, support for printing multiple page sizes in a single document, and a much-anticipated Table Flake shape in KOffice (with further work on the Music Flake shape). Lots of work on colour manipulation for KOffice. Kile begins to use Kross as its scripting framework. Start of a new KDE game, KTank. GetHotNewStuff support disabled in okular, search runner disabled in Plasma for KDE 4.0. KHexEdit moved to the unmaintained module. The new Oxygen wallpapers, splashscreen, and sound theme are imported into KDE SVN for KDE 4.0.
Nuno Póvoa describes his work on the Oxygen sound theme for KDE 4.0:
In a now semi-famous and widely read piece, Aaron Seigo this week addressed certain points about the impending KDE 4.0 release. As an important clarification on the most important release of the KDE project, I have reposted it here for the record. It is long - reflecting the extended development period of KDE 4 to date - but a great summary as we move into the next phase of development:
Now that 4.0.0 is tagged and out and that bit of worry and concern is behind me for the moment, I wanted to take a moment to talk really bluntly about 4.0. In particular, I'm going to address some of the common memes in fairly random order that i see about kde 3.5 and 4.0. I'm going to speak bluntly (though not rudely =) so prepare yourself ;)
Meme 1: What is the future of 3.5?
This year, as with most years since KDE3 emerged, there have been huge deployments of KDE 3 based software. These deployments will not shift for years to come, no matter what KDE4 is. This is because large institutional deployments (government, corporate, educational, etc) typically have 3-7 year cycles (sometimes even longer) between major changes. Patches and security fixes? Sure. Major revamps? No. This alone ensures that KDE3 will remain supported for years. Why? Because there are users. That is how the open source dev model works: where there are users, there are developers; as one declines so does the other. The developers tend to be a step ahead of the users for software that is progressive, but you'll also find that they have a foot in the here and now too (as well as the past, often).
KDE3 is still open in our svn so that bug fixes, security fixes, etc. can continue to be made. KDE 3.5.x is a rather solid desktop system and really doesn't need a huge amount of work given what it is today; the work to move it to the next level is what we refer to as KDE4, of course. This means that the efforts needed to put into it aren't huge to keep it viable. However, efforts that do go into it are welcome.
While the core KDE team will continue to concentrate our work on KDE4 since that is the long term direction of things, it is fully expected that our partners (which include some KDE core team members as employees/members) will continue supporting and even developing on KDE3 issues. The central project will also be around to lend a helping hand with advice and what not; I did that for a person the week before I left for holidays in December, actually, so it's not wild hypothesis but solid theory.
For those familiar with the open source method, the above probably sounds .. well .. obvious. That's because it is .. for those familiar with the open source method. We will find in this blog entry that many of the concerns people raise come from not acknowledging how Free(dom) software is created via the open source method.
Meme 2: KDE 4.0 isn't what a business would do
I've read exactly this statement with those literal words, but I've also read and heard what are essentially the same things put slightly differently. Well, not to play Captain Obvious too much here, but: KDE is not in the business of proprietary software. There are two parts to that statement:
KDE is not a business: we are not selling a product to the mass market. We are a development team creating the resource which can be sold to the mass market. This is an important distinction since we go through an R&D process that is very open, something that a business would have a hard time doing. We also don't pay volunteers per hour, commit or line of code. There are many things, you see, that we don't do that a business does, and vice versa. The fact that people are getting confused on this point shows how well we've done presenting KDE to the world, but we're not a business and we're not about to start pretending to be one to satisfy chin-waggers at the expense of what works for us.
... and that's a salient point: By asking KDE to behave like a proprietary company these people are asking KDE to abandon what has worked for us all these years. They are asking us to abandon our identity, to cease doing what resulted in the Free software desktop going from non-existent in the mid-90s to parity in just over 10 years. Remembering that we started 15 years (and multi-billions of dollars) behind our competition that's a pretty impressive success story.
At the same time, KDE works with business. We have relationships with companies at many levels, technical and otherwise. In order to provide good guidance to our partners we've been pretty blunt about what 4.0 is. That is because while KDE itself isn't a business, we have a large business ecosystem around us. We are a good business partner, even if we ourselves aren't a business. I know, this is rather paradigm shifting for a lot of people out there, but that's what makes it fun and enjoyable for so many of us.
KDE is not a proprietary software product: this is another obvious statement, but it's one people seem to forget. While there is proprietary software that gets written using KDE technology, KDE itself is not and never will be proprietary.
In the open source method you release early, you release often. By doing so, a progression is presented that people can follow with fairly blunt (often overly pessimistic) guidance along with it, e.g.: "foobar v 0.0.1: will eat your children". In theory you can't do that with proprietary software due to the distribution mechanism and economic repercussions (though many companies do anyways), but with open source it is exactly what one must do to get the production wheels turning.
KDE 4.0.0 is our "will eat your children" release of KDE4, not the next release of KDE 3.5. The fact that many already use it daily for their desktop (including myself) shows that it really won't eat your children, but it is part of that early stage in the release system of KDE4. It's the "0.0" release. The amount of new software in KDE4 is remarkable and we're going the open route with that. Which brings us to the next meme:
Meme 3: Just keep releasing alphas until it's ready
Ah, the "until it's ready" idea. Some would say 3.5 isn't ready; software never really is from a perfectionist's standpoint. It's so complex and full of ever springing promise that one can never reach that point of perfection; usually we are just happy with "better than good enough" and call it a day at that point.
KDE 4.0 isn't yet "better than good enough"; so why don't we just release more betas? When one perpetually releases alphas/betas a few things happen: people don't test it aggressively enough, third party developers don't get involved, core developers continue doing blue sky development rather than focusing on release qualities.
Between the RC's and the tagging of 4.0.0 the number of reports from testing skyrocketed. This is great, and shows that when I assert "people don't test when it's alpha or even beta" I'm absolutely correct. This is not about tricking people either: people seem to forget that the open source method is based on participation not consumption. So testers look for a cue to start testing; that is their form of participation. "alpha" and even "beta" is often not enough of a cue, especially today when so many of our testing users are not nearly as technically skilled with the compiler, debuggers, etc as the typical Free software user was 10 years ago.
The KDE4 libraries are ready for application development, as testified to by the quality KDE4 apps that exist today. However, third party application developers tend to be a conservative lot, and rightly so. They wait for user base migration, they wait for stability in the APIs, etc. They want to know when to start working with the new awesomeness, and for most of them that isn't "alpha" or "beta". The libraries crossed that stage in quality and reliability many months ago and so it is only fair to mark them as such.
Finally, the amazing maturation at all levels of KDE 4.0 software that has happened since the last beta shows just how focusing developers off of blue sky development and onto release quality code is important. The delta speaks for itself.
Meme 4: KDE doesn't do time based releases
When I hear this statement, I know I'm either dealing with someone who has been around the community for less than 2 years or has a long term memory problem. KDE has traditionally done time based, not feature based, releases: the project would set a target date, people would create a list of expected features they can do in that time, features that didn't make the target date would get punted to the next release.
In my time with the project we have done 2 feature based releases: both for major overhauls of the entire system. The first one resulted in the pedigree that would become KDE 3.5. The second one is KDE 4.0.
In that same time period we did 8 time based major releases (2.1, 2.2, 3.0, 3.1, 3.2, 3.3, 3.4, 3.5) and countless time based minor releases (8 for 3.5 alone). In each of these releases a target was set and in the overwhelming majority of these cases that target date was hit.
With 4.0 behind us and marching towards 4.1, we'll be back to these time based releases.
Meme 5: What's the quality of KDE 4.0?
KDE 4.0 rocks in a number of ways. Whether one looks at the new frameworks (solid, phonon, akonadi et al) or the revamped existing ones (kconfig getting multiple back end support, the UI-less kdecore), or examines the apps like okular or kdeedu or the games or dolphin or ksnapshot or konsole (ok, I won't list every app) or many of the new workspace features like composite and widgets or the new artwork or ... you get the picture. There's a lot that is just amazing.
What leaves people wondering about quality is that there is a disparity between our stated end goals and 4.0. This is, to be blunt, due to a lack of experience on their part: most people have never been involved in the creation of something great. We're involved in making something great that will end up spanning a decade of effort and be used for even longer than that. To be able to accomplish such a thing one requires the ability to see beyond today and into the uncertain future. They also need to be able to adjust and shift that vision as things evolve (ergo the shift from tenor to strigi/nepomuk, even though the end result is essentially the same ideas). It is simply not possible, without extreme luck similar to winning the lottery, to create something great without that vision. This is not my idea, this is the result of pretty much every bit of research and practical analysis from the business operations world.
More on the concept of vision
To re-affirm: our stated goals for KDE4 remain and they haven't gone anywhere. In fact, KDE 4.0 is the first proof that this is not only vision or, worse, vapour: we're putting it into action. However, long term vision is not met in a short term effort. Vision of the end is what directs immediate efforts into mid-term and eventually long-term successes. We will get there, and probably beyond what we currently imagine, with the releases that will follow. Each stop along the way will rock harder, and none of them will suck. Importantly: nont of it would be possible without the vision.
So it's ironic that some would see the vision we are committed to as reflecting on us in a bad way, since it's what is enabling us to deliver a great product not just today but in the future. Companies usually keep this vision internal and you never really get to see it from the outside. Sure, the ghosts of the vision get communicated eventually through marketing slogans (if they do their job right, anyways =), executive communications, AGMs, etc. but generally it's internalized.
KDE is an open project, however, so we can't talk about our vision without it getting "out there". There is simply no way for us to "keep our light hidden beneath a basket". So while it's ironic, it's not an unexpected consequence: most of our audience is simply used to being on the outside. They are not used to freedom, they are not used to openness, they are not used to being privy to the internal world of others.
For better or worse, there is no way we can shield them from being able to see our vision. As a project we need to talk about it with each other a lot: openly, loudly, even argumentatively at times. So everyone gets to see it, and some mistake the vision creation and maintenance process for marketing effort or spin; they are unrelated. What's funny is that community news sites will actually pick up the evolution of our vision as news events; it's undeniable that people find it interesting, which is pretty cool.
So to achieve what we want to, I've come to realize that I'll take it on the chin, so to speak, from some people who aren't able (yet?) to internalize what this process is all about. I can't in good conscience suggest we divert in response to this particular set of feedback, though, as it would cripple the project in the long term.
Many companies in Europe and North America have been criticized by the business management community for a couple decades now of not investing enough in mid-term (let alone long-term) projects. They have trouble doing so due because they allow themselves to be led by the nose by the financial and consumer markets copuled with vision-lacking internal assignment of resources. Yes, you're reading that right: listening to the short term consumeristic demand of the populace has been a major component of the march towards much of the stagnation and crappy products and services we get to deal with today. Ignoring the short term is foolish, but not investing in the mid-term is equally so.
I don't expect the populace to suddenly get long-term vision; I do expect serious organizations to stop setting their agendas by the flawed clock of the short term thinking that (inevitably?) dominates large societies of people.
To bring it into high-relief: KDE3 is our current product line for production, and KDE4 is our mid-term production line. For there to be any KDE worthy of succeeding KDE 3.5, we needed a mid-term project. No short-term project would cut it. We're at the beginning of where we can bring KDE4 into "current produce line" condition, which is to say that KDE4 is that transition period from mid-term to short-term project. That's exciting, and one more reason 4.0 rocks.
Epilogue
To close I'd like to recognize that KDE as a project is not perfect; we are made of fallible humans engaged in an amazingly complex process. All the same, the people involved are pretty amazing and competent. We're on a good path right now as a result of those people. If you find this process hard to understand that, try to adjust your assumptions and deeply internalize the concepts of the open source method since that is our guiding light. In spite of some of you finding it hard to understand this process, we won't betray you by switching to an inferior plan just because it fits your assumptions better. Even those who are most concerned today will thank us further on down the road.
Ok, enough about that. I've said what needs to be said and won't say more about it from here on out. I have a huge backlog of blog topics to cover that are more interesting and positive in nature. I'll do my best to keep them shorter than this one ... but no promises there ;)
Meme 1: What is the future of 3.5?
This year, as with most years since KDE3 emerged, there have been huge deployments of KDE 3 based software. These deployments will not shift for years to come, no matter what KDE4 is. This is because large institutional deployments (government, corporate, educational, etc) typically have 3-7 year cycles (sometimes even longer) between major changes. Patches and security fixes? Sure. Major revamps? No. This alone ensures that KDE3 will remain supported for years. Why? Because there are users. That is how the open source dev model works: where there are users, there are developers; as one declines so does the other. The developers tend to be a step ahead of the users for software that is progressive, but you'll also find that they have a foot in the here and now too (as well as the past, often).
KDE3 is still open in our svn so that bug fixes, security fixes, etc. can continue to be made. KDE 3.5.x is a rather solid desktop system and really doesn't need a huge amount of work given what it is today; the work to move it to the next level is what we refer to as KDE4, of course. This means that the efforts needed to put into it aren't huge to keep it viable. However, efforts that do go into it are welcome.
While the core KDE team will continue to concentrate our work on KDE4 since that is the long term direction of things, it is fully expected that our partners (which include some KDE core team members as employees/members) will continue supporting and even developing on KDE3 issues. The central project will also be around to lend a helping hand with advice and what not; I did that for a person the week before I left for holidays in December, actually, so it's not wild hypothesis but solid theory.
For those familiar with the open source method, the above probably sounds .. well .. obvious. That's because it is .. for those familiar with the open source method. We will find in this blog entry that many of the concerns people raise come from not acknowledging how Free(dom) software is created via the open source method.
Meme 2: KDE 4.0 isn't what a business would do
I've read exactly this statement with those literal words, but I've also read and heard what are essentially the same things put slightly differently. Well, not to play Captain Obvious too much here, but: KDE is not in the business of proprietary software. There are two parts to that statement:
KDE is not a business: we are not selling a product to the mass market. We are a development team creating the resource which can be sold to the mass market. This is an important distinction since we go through an R&D process that is very open, something that a business would have a hard time doing. We also don't pay volunteers per hour, commit or line of code. There are many things, you see, that we don't do that a business does, and vice versa. The fact that people are getting confused on this point shows how well we've done presenting KDE to the world, but we're not a business and we're not about to start pretending to be one to satisfy chin-waggers at the expense of what works for us.
... and that's a salient point: By asking KDE to behave like a proprietary company these people are asking KDE to abandon what has worked for us all these years. They are asking us to abandon our identity, to cease doing what resulted in the Free software desktop going from non-existent in the mid-90s to parity in just over 10 years. Remembering that we started 15 years (and multi-billions of dollars) behind our competition that's a pretty impressive success story.
At the same time, KDE works with business. We have relationships with companies at many levels, technical and otherwise. In order to provide good guidance to our partners we've been pretty blunt about what 4.0 is. That is because while KDE itself isn't a business, we have a large business ecosystem around us. We are a good business partner, even if we ourselves aren't a business. I know, this is rather paradigm shifting for a lot of people out there, but that's what makes it fun and enjoyable for so many of us.
KDE is not a proprietary software product: this is another obvious statement, but it's one people seem to forget. While there is proprietary software that gets written using KDE technology, KDE itself is not and never will be proprietary.
In the open source method you release early, you release often. By doing so, a progression is presented that people can follow with fairly blunt (often overly pessimistic) guidance along with it, e.g.: "foobar v 0.0.1: will eat your children". In theory you can't do that with proprietary software due to the distribution mechanism and economic repercussions (though many companies do anyways), but with open source it is exactly what one must do to get the production wheels turning.
KDE 4.0.0 is our "will eat your children" release of KDE4, not the next release of KDE 3.5. The fact that many already use it daily for their desktop (including myself) shows that it really won't eat your children, but it is part of that early stage in the release system of KDE4. It's the "0.0" release. The amount of new software in KDE4 is remarkable and we're going the open route with that. Which brings us to the next meme:
Meme 3: Just keep releasing alphas until it's ready
Ah, the "until it's ready" idea. Some would say 3.5 isn't ready; software never really is from a perfectionist's standpoint. It's so complex and full of ever springing promise that one can never reach that point of perfection; usually we are just happy with "better than good enough" and call it a day at that point.
KDE 4.0 isn't yet "better than good enough"; so why don't we just release more betas? When one perpetually releases alphas/betas a few things happen: people don't test it aggressively enough, third party developers don't get involved, core developers continue doing blue sky development rather than focusing on release qualities.
Between the RC's and the tagging of 4.0.0 the number of reports from testing skyrocketed. This is great, and shows that when I assert "people don't test when it's alpha or even beta" I'm absolutely correct. This is not about tricking people either: people seem to forget that the open source method is based on participation not consumption. So testers look for a cue to start testing; that is their form of participation. "alpha" and even "beta" is often not enough of a cue, especially today when so many of our testing users are not nearly as technically skilled with the compiler, debuggers, etc as the typical Free software user was 10 years ago.
The KDE4 libraries are ready for application development, as testified to by the quality KDE4 apps that exist today. However, third party application developers tend to be a conservative lot, and rightly so. They wait for user base migration, they wait for stability in the APIs, etc. They want to know when to start working with the new awesomeness, and for most of them that isn't "alpha" or "beta". The libraries crossed that stage in quality and reliability many months ago and so it is only fair to mark them as such.
Finally, the amazing maturation at all levels of KDE 4.0 software that has happened since the last beta shows just how focusing developers off of blue sky development and onto release quality code is important. The delta speaks for itself.
Meme 4: KDE doesn't do time based releases
When I hear this statement, I know I'm either dealing with someone who has been around the community for less than 2 years or has a long term memory problem. KDE has traditionally done time based, not feature based, releases: the project would set a target date, people would create a list of expected features they can do in that time, features that didn't make the target date would get punted to the next release.
In my time with the project we have done 2 feature based releases: both for major overhauls of the entire system. The first one resulted in the pedigree that would become KDE 3.5. The second one is KDE 4.0.
In that same time period we did 8 time based major releases (2.1, 2.2, 3.0, 3.1, 3.2, 3.3, 3.4, 3.5) and countless time based minor releases (8 for 3.5 alone). In each of these releases a target was set and in the overwhelming majority of these cases that target date was hit.
With 4.0 behind us and marching towards 4.1, we'll be back to these time based releases.
Meme 5: What's the quality of KDE 4.0?
KDE 4.0 rocks in a number of ways. Whether one looks at the new frameworks (solid, phonon, akonadi et al) or the revamped existing ones (kconfig getting multiple back end support, the UI-less kdecore), or examines the apps like okular or kdeedu or the games or dolphin or ksnapshot or konsole (ok, I won't list every app) or many of the new workspace features like composite and widgets or the new artwork or ... you get the picture. There's a lot that is just amazing.
What leaves people wondering about quality is that there is a disparity between our stated end goals and 4.0. This is, to be blunt, due to a lack of experience on their part: most people have never been involved in the creation of something great. We're involved in making something great that will end up spanning a decade of effort and be used for even longer than that. To be able to accomplish such a thing one requires the ability to see beyond today and into the uncertain future. They also need to be able to adjust and shift that vision as things evolve (ergo the shift from tenor to strigi/nepomuk, even though the end result is essentially the same ideas). It is simply not possible, without extreme luck similar to winning the lottery, to create something great without that vision. This is not my idea, this is the result of pretty much every bit of research and practical analysis from the business operations world.
More on the concept of vision
To re-affirm: our stated goals for KDE4 remain and they haven't gone anywhere. In fact, KDE 4.0 is the first proof that this is not only vision or, worse, vapour: we're putting it into action. However, long term vision is not met in a short term effort. Vision of the end is what directs immediate efforts into mid-term and eventually long-term successes. We will get there, and probably beyond what we currently imagine, with the releases that will follow. Each stop along the way will rock harder, and none of them will suck. Importantly: nont of it would be possible without the vision.
So it's ironic that some would see the vision we are committed to as reflecting on us in a bad way, since it's what is enabling us to deliver a great product not just today but in the future. Companies usually keep this vision internal and you never really get to see it from the outside. Sure, the ghosts of the vision get communicated eventually through marketing slogans (if they do their job right, anyways =), executive communications, AGMs, etc. but generally it's internalized.
KDE is an open project, however, so we can't talk about our vision without it getting "out there". There is simply no way for us to "keep our light hidden beneath a basket". So while it's ironic, it's not an unexpected consequence: most of our audience is simply used to being on the outside. They are not used to freedom, they are not used to openness, they are not used to being privy to the internal world of others.
For better or worse, there is no way we can shield them from being able to see our vision. As a project we need to talk about it with each other a lot: openly, loudly, even argumentatively at times. So everyone gets to see it, and some mistake the vision creation and maintenance process for marketing effort or spin; they are unrelated. What's funny is that community news sites will actually pick up the evolution of our vision as news events; it's undeniable that people find it interesting, which is pretty cool.
So to achieve what we want to, I've come to realize that I'll take it on the chin, so to speak, from some people who aren't able (yet?) to internalize what this process is all about. I can't in good conscience suggest we divert in response to this particular set of feedback, though, as it would cripple the project in the long term.
Many companies in Europe and North America have been criticized by the business management community for a couple decades now of not investing enough in mid-term (let alone long-term) projects. They have trouble doing so due because they allow themselves to be led by the nose by the financial and consumer markets copuled with vision-lacking internal assignment of resources. Yes, you're reading that right: listening to the short term consumeristic demand of the populace has been a major component of the march towards much of the stagnation and crappy products and services we get to deal with today. Ignoring the short term is foolish, but not investing in the mid-term is equally so.
I don't expect the populace to suddenly get long-term vision; I do expect serious organizations to stop setting their agendas by the flawed clock of the short term thinking that (inevitably?) dominates large societies of people.
To bring it into high-relief: KDE3 is our current product line for production, and KDE4 is our mid-term production line. For there to be any KDE worthy of succeeding KDE 3.5, we needed a mid-term project. No short-term project would cut it. We're at the beginning of where we can bring KDE4 into "current produce line" condition, which is to say that KDE4 is that transition period from mid-term to short-term project. That's exciting, and one more reason 4.0 rocks.
Epilogue
To close I'd like to recognize that KDE as a project is not perfect; we are made of fallible humans engaged in an amazingly complex process. All the same, the people involved are pretty amazing and competent. We're on a good path right now as a result of those people. If you find this process hard to understand that, try to adjust your assumptions and deeply internalize the concepts of the open source method since that is our guiding light. In spite of some of you finding it hard to understand this process, we won't betray you by switching to an inferior plan just because it fits your assumptions better. Even those who are most concerned today will thank us further on down the road.
Ok, enough about that. I've said what needs to be said and won't say more about it from here on out. I have a huge backlog of blog topics to cover that are more interesting and positive in nature. I'll do my best to keep them shorter than this one ... but no promises there ;)
The last week included the final days of KDE 4.0 development before the total tagging freeze on Friday, January 4th. As expected, the lull in development of the week before was smashed this week, with 3307 commits (646 more than last week, which wasn't even an exceptionally slow week!), and more importantly, I found the commits this week to be more interesting: there are more than double the number of selected commits in this issue than in the last.
By the time the next issue of the Digest is released, KDE 4.0 Final will have been officially released to the world (January 11th is the expected release date). Though many people within the KDE project would not have expected such a marathon development effort back in 2005, when KDE 4 was only in the imaginations of developers, it is what it is - and everyone I know in the KDE project is proud of our collective acheivements. The future is now, and it looks brighter than ever.
Statistics
| Commits | 3307 by 251 developers, 7517 lines modified, 2477 new files |
| Open Bugs | 15349 |
| Open Wishes | 13401 |
| Bugs Opened | 266 in the last 7 days |
| Bugs Closed | 233 in the last 7 days |
Commit Summary
| Module | Commits |
| /trunk/l10n-kde4 |
1078
|
| /trunk/KDE |
1067
|
| /trunk/koffice |
224
|
| /trunk/extragear |
180
|
| /trunk/playground |
159
|
| /branches/KDE |
107
|
| /trunk/www |
101
|
| /branches/work |
64
|
| /branches/extragear |
63
|
| /trunk/l10n-kde3 |
59
|
| Lines | Developer | Commits |
|
180
|
Sébastien Renard |
113
|
|
430
|
Jakob Petsovits |
103
|
|
261
|
Pino Toscano |
91
|
|
205
|
Laurent Montel |
89
|
|
86
|
Mauricio Piacentini |
60
|
|
129
|
Marta Rybczyńska |
59
|
|
137
|
Urs Wolfer |
55
|
|
144
|
Luciano Montanaro |
51
|
|
136
|
Gilles Caulier |
51
|
|
136
|
David Faure |
51
|
Internationalization (i18n) Status
| Language | Percentage Complete |
| Swedish (sv) |
100%
|
| Portuguese (pt) |
100%
|
| Greek (el) |
99.9%
|
| Japanese (ja) |
94.85%
|
| Estonian (et) |
91.97%
|
| German (de) |
90.44%
|
| Polish (pl) |
89.77%
|
| Spanish (es) |
89.69%
|
| Dutch (nl) |
88.82%
|
| French (fr) |
87.21%
|
Bug Killers and Buzz
| Person | Bugs Closed |
| Robert Knight |
30
|
| Thomas McGuire |
16
|
| Aaron J. Seigo |
15
|
| Luboš Luňák |
14
|
| Leonardo Finetti |
13
|
| Pino Toscano |
12
|
| Christian Esken |
10
|
| Urs Wolfer |
9
|
| Thomas Friedrichsmeier |
9
|
| Gilles Caulier |
8
|
| Program | Buzz |
| Plasma |
6450
|
| Amarok |
5790
|
| KMail |
3125
|
| K3B |
3060
|
| Kopete |
2935
|
| Solid |
2029
|
| SuperKaramba |
1962
|
| Kate |
1895
|
| KDevelop |
1815
|
| Phonon |
1144
|
| Person | Buzz |
| Tobias Hunger |
5000
|
| Allen Winter |
2460
|
| David Faure |
2205
|
| Stephan Kulow |
2145
|
| Jonathan Riddell |
1142
|
| Torsten Rahn |
1068
|
| Jason Harris |
1047
|
| Laurent Montel |
1008
|
| Bram Schoenmakers |
978
|
| Stephan Binner |
925
|
Commit Countries
Commit Demographics
Sex
Age
Contents
| Bug Fixes | Features | Optimization | Security | Other | |
|---|---|---|---|---|---|
Accessibility | |||||
Development Tools | [] | [] | [] | ||
Educational | [] | [] | [] | [] | |
Graphics | [] | [] | |||
KDE Base | [] | [] | [] | [] | |
KDE-PIM | [] | [] | [] | ||
Office | [] | [] | |||
Konqueror | |||||
Multimedia | [] | [] | |||
Networking Tools | [] | [] | [] | ||
User Interface | [] | [] | |||
Utilities | [] | [] | |||
Games | [] | [] | [] | ||
Other | [] |
There are 185 selections this week
Bug Fixes
Development Tools
David Nolden committed changes in /trunk/KDE/kdevplatform/shell/project.cpp:
Canonicalize the paths of opened project files.
This makes code-completion work in projects that have symlinks in there path. File-urls seem always to be canonical.
Diffs: 1 Revision 757343
Educational
Inge Wallin committed changes in /trunk/KDE/kdeedu/marble:
Anne-Marie Mahfouf committed changes in /trunk/KDE/kdeedu/kbruch/src:
KDE Base
Charles Samuels committed changes in /trunk/KDE/kdelibs/khtml/rendering/render_table.cpp:
don't crash when selecting text across a table of Right-to-left text.
You can reproduce this by just selecting the page on <a href="http://he.wikipedia.org">http://he.wikipedia.org</a>;
Diffs: 1 Revision 754546
Germain Garand committed changes in /trunk/KDE/kdelibs/khtml:
.Cope with set{Vertical,Horizontal}ScrollBarPolicy not being virtual anymore in Qt 4. Too bad we actually thought we reimplemented them.
How viciously stealth such a bug can be is beyond description ;(
major bug 153036.
Urs Wolfer committed changes in /trunk/KDE/kdebase/workspace/ksmserver/shutdowndlg.cpp:
I am pretty sure background fading has never worked in KDE 4 when composite has been disabled...
This should fix it. Also, make the fading animations on fast computers a bit slower...
Diffs: 1 Revision 754848
Charles Samuels committed changes in /trunk/KDE/kdelibs/khtml/rendering:
Allow padding of form elements in the case of border-box, which causes the form element widget to get bigger but its active region to stay the same size.
This is sometimes used to put little icons on lineedits.
In the case of the content-box model, the padding goes around the form element, as it is today (also the default in non-quirky mode).
There's still a strange bug with how the scrollbar on scrollable widgets doesn't have any hover effects and it has the "text input" cursor. But that's not a regression and is tolerable, so we decided to accept it until we have a chance to clean up render_replaced.
Reviewed repeatedly by Germain.
Diffs: 1, 2, 3, 4 Revision 755231
Robert Knight committed changes in /trunk/KDE/kdebase/apps/konsole/src/TerminalDisplay.cpp:
Fix bug where bold fonts applied to the terminal were drawn as regular fonts. Take the TerminalDisplay widget's font weight and underline state into consideration when deciding whether to render a particular piece of text as bold or underline.
Diffs: 1 Revision 755882
Robert Knight committed changes in /trunk/KDE/kdebase/apps/konsole/src:
Fix bug where search result highlights in the terminal display did not move when the display was scrolled. When the search bar is active, update the filters and the view whenever it is scrolled or the output otherwise changes.
This has a perceptible (but in future fixable) performance impact when scrolling with the search bar active.
Diffs: 1, 2, 3 Revision 756104
Rivo Laks committed changes in /trunk/KDE/kdebase/workspace/kwin/kwinbindings.cpp:
Make reverse cycling through windows work (ctrl+shift+tab)
Diffs: 1 Revision 756603
Robert Knight committed changes in /trunk/KDE/kdelibs/kio/misc/kwalletd/kwalletd.cpp:
Add a window title to the KWallet first-run wizard. The string 'KDE Wallet Service' (already used elsewhere) is used instead of 'KDE Wallet Wizard' because of the string freeze
Diffs: 1 Revision 756609
Germain Garand committed changes in /trunk/KDE/kdelibs/kdeui/widgets:
fix the "Lock/Unlock Toolbars" feature so that its state is remembered accross application restart.
also fix a bug in KToolBar where the Lock/Unlock toggling in the toolbar contextual menu would go out of sync from one toolbar to the other.
Robert Knight committed changes in /trunk/KDE/kdebase/apps/konsole/src:
Fix 'Open Folder in Tabs' action on bookmark menu.
Diffs: 1, 2, 3, 4 Revision 756949
Germain Garand committed changes in /trunk/KDE/kdebase/apps/konqueror/src:
disable kcombobox's internal clear icon when it's already present in the location toolbar as a tool button.
reviewed by Michael Pyne
Thomas Georgiou committed changes in /trunk/KDE/kdebase/workspace/plasma/desktoptheme/widgets/panel-background.svg:
Make plasma not crash on screen resolutions 1680x1050. ASEIGO!! WHERE ARE YOU!!!
Diffs: 1 Revision 757075
Jakob Petsovits committed changes in /trunk/KDE/kdebase/apps/dolphin/src:
Kevin Ottens committed changes in /branches/KDE/4.0/kdelibs/kdeui:
Reverting commit 757034 which was completely preventing to configure any global shortcut. This issue will obviously require more investigation...
OK'd by Tom Albers.
We probably want that hotfix in the 4.0.0 tag. Otherwise we're shipping a desktop where we can't configure the desktop related (kwin, krunner, plasma) shortcuts and any other global shortcuts.
Dirk, any chance to get that in the release?
Diffs: 1, 2 Revision 757402
John Tapsell committed changes in /branches/KDE/4.0/kdebase/workspace/ksysguard/ksysguardd/Linux/diskstat.c:
Be smarter about adding/removing mount point monitors
KDE-PIM
Jason vanRijn Kasper committed changes in /trunk/KDE/kdepim/kpilot:
* Forward-porting rev 754992 from 3.5 branch:
* Fixing bug reported by Pablo Yepes on kdepim-users mailing list. We did severe goofiness with middle names... The Palm can't handle them, so we blindly tacked firstname + " " + lastname and stuck it into the Palm's firstname field. The problem is that whenever a copy from palm->pc is done, the kludged first name is transferred to kabc ("firstname middle").
And, it's compounded by every change in either direction. It's an ugly hack and I've removed it. The only way to work around it would be to add an additional check for !firstname.endsWith(abEntry.additionalName()), but that's even sillier. Stop the insanity!
Diffs: 1, 2, 3 Revision 754993
Networking Tools
Javier Goday committed changes in /trunk/KDE/kdenetwork/kget/plasma/applet:
Jan Schäfer committed changes in /branches/KDE/3.5/kdenetwork/filesharing/advanced/kcm_sambaconf:
Fixed the widgets of the following samba options:
case sensitive, strict locking, msdfs proxy
The wrong widgets resulted in wrong default values, which in turn resulted in wrongly generated settings in the smb.conf file.
Cláudio da Silveira Pinheiro committed changes in /trunk/KDE/kdenetwork/kopete:
Fixes problem when initializing devices (namedly the green screen in uvc webcams).
Some debug info rewording (doesn't affect i18n or l10n)
Diffs: 1, 2, 3 Revision 755895
Games
Mauricio Piacentini committed changes in /trunk/KDE/kdegames/kmahjongg/boardwidget.cpp:
Do not draw board if game is paused, no matter the source of the repaint request. Fixes bug where the board will appear in paused games after a change in the configured tileset.
Features
Development Tools
Andreas Pakulat committed changes in /trunk/KDE/kdevelop/buildtools/managers/cmake:
Add a simple debug visitor for the Ast, it simply prints all ast nodes with their member variables out to the debug area
Diffs: 1, 2, 3, 4 Revision 754925
Anders Lund committed changes in /trunk/KDE/kdesdk/kate:
Hamish Rodda committed changes in /trunk/KDE/kdevelop/plugins/valgrind:
Working, at last - for memcheck, that is. I ported to QXmlStreamReader and that allowed me to feed the XML in as it was received (contrast to the old QXmlSimpleReader, which threw up end of file errors and the like).
I guess it will need a compatability mode for non-xml producing tools
Also the app output still goes to /dev/limbo, not sure why...
Educational
Carsten Niehaus committed changes in /trunk/KDE/kdeedu/kalzium/data/iconsets/school:
Frederik Gladhorn committed changes in /branches/work/kdeedu_parley/libkdeedu/keduvocdocument:
Enable the readers including kvtml-1 also in code and finish porting it to a works somewhat state.
Reading subwordtypes is still not working because they are not created correctly in the init section of the compability class.
Remove last references to usage stuff (no one will miss it).
Some cleanup of the horrible horrible kvtml-1 reader code.
I will have to drop the kvtml-1 writer. Too much effort and too many things that cannot be saved in the old format.
Frederik Gladhorn committed changes in /trunk/KDE/kdeedu/kalzium/src:
Start a KHotNewStuff2 implementation.
The new molecule files are saved to the home dir for now.
(.kde/share/apps/kalzium/data/molecules)
Diffs: 1, 2, 3, 4 Revision 757646
Frederik Gladhorn committed changes in /trunk/KDE/kdeedu:
Redo of the lib. Merge of the 4.1 branch to trunk.
This is a rather big change, which affects the apps using libkdeedu.
I guess there are quite a few bugs left. So far I know the destructor of either expression or translation sometimes seems to double delete. Need to look into that.
Start an experimental new practice app that is independent of the main app. Still hardly anything implemented there.
Parley: New main window gui using dock windows. The edit entry dialog does no longer exist. It is much nicer to edit vocabulary now.
Ported KHangMan, KAnagram, KWordQuiz and Parley
Notes:
- Containers: There are two subclasses for KEduVocContainer.
KEduVocLesson and KEduVocWordType. This is very benificial as from now on, I can use the same models/views for both in parley. Leitner boxes are also easy to realize subclassing the containers.
-The KEduVocDocument class was huge and contained some functions specific to expression handling. This redundand api has been removed.
Instead the document now contains one root lesson (KEduVocDocument::lesson()) to manage all entries. This lesson can contain entries directly as well as child lessons. This makes it easy to access all vocabulary entries by using doc->lesson()->entriesRecursive() which collects all entries including those from sublessons.
- Lessons and word types are now able to contain child lessons/word types to an arbitrary depth.
- Entries can be in multiple lessons.
- Expression->translation() now returns a pointer. This is more consistent and avoids some reference trouble. In general now everything is a pointer (containers also).
- KWordQuiz now saves the size hints per document in the kconfig. This could also be used for cell heights.
- KWordQuiz only edits entries in the top level lesson. I'll change it to use all entries in the document.
- Statistics in Parley are disabled for now, needs to be rewritten.
- Usages have been removed completely.
- Comparison forms do no longer have a proper class but only two strings.
Eventually it should be considered making them a class to support male/female again. The base form should always be the adjective/adverb itself.
I hope everything works, but I must have missed something. Bug me.
Graphics
Gilles Caulier committed changes in /branches/extragear/kde3/graphics/digikam:
digiKam from KDE3 branch: important changes here : add capability to display count of items in all Folder View.
The number of items contained in virtual or physical albums is now displayed on the right of album name.
If a tree branch is collapsed, parents album sum-up the number of items from all undisplayed children albums.
Count of items is performed in background by digiKam KIO-Slaves.
A new option from Setup/Album dialog page can toggle on/off this feature.
Screenshot of digiKam in action using this new feature can be seen at this url:
<a href="http://bugs.kde.org/attachment.cgi?id=22233&action=view">http://bugs.kde.org/attachment.cgi?id=22233&action=view</a>;
Folder view witch supports this feature are:
- Physical Albums from left side bar.
- Virtual Date Albums (calendar) from left side bar.
- Virtual Tags Albums from left side bar.
- Virtual Tags Albums from Captions & Tags right side bar tab.
- Virtual Tags Albums Filter from right side bar.
Note: for performance reasons, Search folder view do not support count of items. Search queries on digiKam database can take a while and slow down digiKam reactivity. See B.K.O 96388 story for details...
Marcel Wiesweg committed changes in /trunk/extragear/graphics/digikam/libs/database:
Use DBus to dispatch change notifications about the database from slaves (and from other running instances).
The Changeset objects are serialized as DBus custom types and emitted with identifiers of the sending process and the affected database.
Slaves emit signals with their object implementing the org.digikam.DatabaseChangesetRelay interface.
"Masters" emit signals with a different object implementing the interface, meant for peer masters, and receive signals from both.
Changesets are received and dispatched like local signals.
Diffs: 1, 2 Revision 754686
Gilles Caulier committed changes in /branches/extragear/kde3/graphics/digikam/digikam:
digiKam from KDE3 branch : starting to introduce new TimeLine tool. Not yet suitable.
Diffs: 1, 2, 3, 4 Revision 754728
Pino Toscano committed changes in /trunk/KDE/kdegraphics/okular/generators/dvi:
Aurélien Gâteau committed changes in /trunk/KDE/kdegraphics/gwenview/part:
Added support for printing to KPart.
Diffs: 1, 2, 3, 4 Revision 756103
Pino Toscano committed changes in /trunk/KDE/kdegraphics/okular:
Start adding a configuration to toggle anti-aliasing for both text and graphics.
Let the Document propagate these settings to the backends, if they query for them.
Diffs: 1, 2 Revision 757647
Marcel Wiesweg committed changes in /trunk/extragear/graphics/digikam/libs/database:
Add methods to read to structures from the database, similar to the PhotoInfoContainer for DMetadata.
The information is read by ImageScanner, this is because this class knows the dirty details of how to read information into the db, so it is the best place to know how to interpret them.
The API to retrieve the containers of course is added to ImageInfo
KDE Base
Luka Renko committed changes in /trunk/KDE/kdebase/workspace/plasma/applets/battery:
Add configuration option to show multiple batteries as individual icons (or rather use one icon (less space) with cumulative state)
Diffs: 1, 2, 3 Revision 754825
Tobias Koenig committed changes in /trunk/KDE/kdebase/workspace/plasmas/kickoff:
Implemented the functionality of adding kickoff menu items to the plasma desktop or the panel.
Diffs: 1, 2, 3 Revision 755546
Ryan P. Bitanga committed changes in /trunk/KDE/kdebase/workspace/libs/taskmanager:
Restore composite support to libtaskmanager
Diffs: 1, 2, 3, 4 Revision 755688
Luboš Luňák committed changes in /trunk/KDE/kdebase/workspace/kwin:
Jakob Petsovits committed changes in /trunk/KDE/kdelibs/cmake/modules/KDE4Macros.cmake:
Add missing icon contexts to the kde4_install_icons() macro.
In case you didn't know it (I didn't as of a few minutes ago):
You can use the exact icon context names in the filenames of your installed icons. If you ever wondered where the "app" in ox22-app-mykdeapplication.png came from: that's just KDE 3 compatibility. Using the real name of the context, "apps", works just as well: ox22-apps-mykdeapplication.png
(This also works with "actions", "status", "places" and whatever icon contexts the icon naming specification defines.)
Diffs: 1 Revision 756013
Vlad Codrea committed changes in /trunk/playground/libs/kiofuse:
Chani Armitage committed changes in /trunk/extragear/plasma:
twitter improvements, cleanup and comments
Diffs: 1, 2, 3, 4 Revision 756327
Luboš Luňák committed changes in /trunk/KDE/kdebase/workspace/kwin/effects:
Alex Merry committed changes in /trunk/playground/base/plasma/engines/nowplaying:
Aaron J. Seigo committed changes in /trunk/KDE/kdebase/workspace/libs/plasma/widgets:
allow setting the background of icon on/off ... a little sad about this, but no time to do something else atm
Diffs: 1, 2, 3 Revision 756868
Riccardo Iaconelli committed changes in /trunk/KDE/kdebase/workspace/wallpapers:
Urs Wolfer committed changes in /trunk/KDE/kdebase/workspace/wallpapers:
Lukas Appelhans committed changes in /trunk/KDE/kdebase/workspace/wallpapers/Colorado_Farm:
Urs Wolfer committed changes in /trunk/KDE/kdebase/workspace/wallpapers:
Lukas Appelhans committed changes in /trunk/KDE/kdebase/workspace/wallpapers/Code_Poets_Dream:
Lukas Appelhans committed changes in /trunk/KDE/kdebase/workspace/wallpapers/Ladybuggin:
Urs Wolfer committed changes in /trunk/KDE/kdebase/workspace/wallpapers:
Harri Porten committed changes in /trunk/KDE/kdelibs:
ugly but makes khtml use Qt Unicode support without restricting licensing of apps using libkjs. Todo for later release: pick up more advanced impls in JSC for Qt 4.3.
Diffs: 1, 2 Revision 757021
Brad Hards committed changes in /trunk/playground/libs/kcabinet:
OK, now it really works with Cabinet files that are spread over more than one block (i.e. >32K in size).
The missing part came from a hint from Mark Adler, who advised:
Someone else was emailing me about this recently. They found out that each subsequent block uses the previous 32K block as a dictionary. You can use inflateSetDictionary() to set the dictionary for the next block before decompressing.
Also, update the unit test. I wasn't reading the khexedit display correctly.
Diffs: 1, 2 Revision 757103
Brad Hards committed changes in /trunk/playground/libs/kcabinet/tests:
Add a new test case, based on a file produced by lcab (<a href="http://coding.wooyayhoopla.be/lcab/">http://coding.wooyayhoopla.be/lcab/</a>;)
That test file has a couple of things I'm not yet handling correctly, such as uncompressed files that span more than one CFDATA block, and a file that is in a subdirectory.
Diffs: 1, 2, 3 Revision 757511
Alex Merry committed changes in /trunk/KDE/kdebase/workspace/libs/plasma:
Allow free resizing (without maintaining aspect ratio) by holding down CTRL.
This should probably be documented somewhere. Plasma should probably have docs.
Diffs: 1, 2 Revision 757567
Alex Merry committed changes in /trunk/KDE/kdebase/workspace/libs/plasma:
Improve the resize/rotate interface:
We now have a separate resize button. The rotate button just rotates.
The resize button scaled with fixed aspect ratio by default, or freely with CTRL.
It's trivial to change it so it resizes freely by default (or to change the access key) if we want.
Diffs: 1, 2 Revision 757843
KDE-PIM
Volker Krause committed changes in /trunk/KDE/kdepim/akonadi:
Frode M. Døving committed changes in /trunk/playground/pim/mailody/src:
Tom Albers committed changes in /trunk/playground/pim/mailody:
Tom Albers committed changes in /trunk/playground/pim/mailody:
Volker Krause committed changes in /trunk/KDE/kdepim/akonadi:
Volker Krause committed changes in /trunk/KDE/kdepim/akonadi/resources/nntp:
Office
Sascha Pfau committed changes in /trunk/koffice/kspread/functions/statistical.cpp:
added a first draft of GROWTH function.
since this is surely my last commit this year i wish you all a happy new year (in advance) and hope all the best koffice/kde4 and the rest of OSS.
Diffs: 1 Revision 755194
Emanuele Tamponi committed changes in /trunk/koffice/krita/plugins/painterlyframework:
Changed the infrastructure. Now both half and float are supported (half still to load in the registry, but it should work flawlessly) and a variable number of wavelengths (just for testing purposes, while looking for the best number). Tests work.
Johannes Simon committed changes in /trunk/koffice/kchart/shape:
More work on the GUI design of the chart tool
Diffs: 1, 2 Revision 755445
Jan Hambrecht committed changes in /trunk/koffice:
Michel Ludwig committed changes in /trunk/extragear/office/kile/src:
Thomas Zander committed changes in /trunk/koffice:
Allow printing to have a different pagesize for each page.
Diffs: 1, 2 Revision 755910
Boudewijn Rempt committed changes in /trunk/koffice/plugins/tableshape:
Cyrille Berger Skott committed changes in /trunk/koffice/krita/image:
Inge Wallin committed changes in /trunk/koffice/plugins/tableshape:
* Make compile again.
* Add a structure for loading ODF tables.
There is very much to do still.
Diffs: 1, 2 Revision 756250
Marijn Kruisselbrink committed changes in /trunk/koffice/plugins/musicshape:
start implementing a greatly improved music justification algorithm. Not everything that worked before works again, but it should definately be an improvement.
Diffs: 1, 2, 3, 4 Revision 756681
Marijn Kruisselbrink committed changes in /trunk/koffice/plugins/musicshape:
introduce (currently not yet really used) beatline property. this should make it possible to improve music justification even further
Diffs: 1, 2, 3, 4 Revision 756682
Marijn Kruisselbrink committed changes in /trunk/koffice/plugins/musicshape:
Cyrille Berger Skott committed changes in /trunk/koffice:
Boudewijn Rempt committed changes in /trunk/koffice/plugins/tableshape:
Boudewijn Rempt committed changes in /trunk/koffice/plugins:
Multimedia
Christoph Pfister committed changes in /branches/work/kaffeine4/kaffeine/src/dvb:
Andreas Silberstorff committed changes in /trunk/playground/multimedia/kalva/src:
Christoph Pfister committed changes in /branches/work/kaffeine4/kaffeine/src/dvb:
start implementation for loading / storing channel files
Diffs: 1, 2, 3, 4 Revision 757354
Networking Tools
Lukas Appelhans committed changes in /trunk/KDE/kdenetwork/kget/transfer-plugins/bittorrent:
Utilities
Friedrich W. H. Kossebau committed changes in /trunk/playground/utils/okteta/program/oktetakakao/controllers:
Friedrich W. H. Kossebau committed changes in /trunk/playground/utils/okteta/program/oktetakakao/controllers:
David Jarvie committed changes in /branches/KDE/3.5/kdeutils/kmilo/generic:
Use KMix master device to adjust volume and mute. It uses a newly committed addition to KMix's DCOP interface which allows the master device to be determined.
Fixes commit 624936 which broke things completely for laptops which don't use device 0 as the master.
This patch was contributed by Kelvie Wong.
David Faure committed changes in /trunk/playground/utils/charm/trunk/Charm:
Added RMB / Rename Task, so that double-clicking a task (in the name column) can start the timer, like in karm.
(renaming a task is a very very rare operation, so we don't need in-place renaming for that)
Diffs: 1, 2, 3 Revision 756484
David Faure committed changes in /trunk/playground/utils/charm/trunk:
Show total hours for today and for this week in the statusbar.
Diffs: 1, 2, 3 Revision 756534
Spiros Georgaras committed changes in /trunk/playground/utils/gwenrename:
David Faure committed changes in /trunk/playground/utils/charm/trunk/Charm/Reports:
Games
Michał Bartecki committed changes in /trunk/KDE/kdegames/ktuberling/pics:
Added Egypt theme for KTuberling
Diffs: 1, 2, 3 Revision 757815
Optimization
Educational
Jasem Mutlaq committed changes in /trunk/KDE/kdeedu/kstars/kstars:
The INDI network backend was migrated to fully use Qt, this along with changes in the INDI parser led to orders of magnitudes improvement in processing and constructing on the fly devices. Binary BLOBs gained the most advantage, loading an average FITs file from the CCD now takes 20% of what is used to take.
It is now possible to start multiple devices managed by one INDI server vs the one-device-one-server behavior before. This model has also resulted in unifying server and local devices with remote devices and that in turn greatly simplified the code. Now that this is the 4.1 branch, there is quite a bit of refactoring to improve consistency.
KDE Base
Aurélien Gâteau committed changes in /trunk/KDE/kdebase/apps/konqueror/settings/filetypes:
Just-in-time loading of item icons. Makes the module start much faster.
Diffs: 1, 2 Revision 756236
Robert Knight committed changes in /trunk/KDE/kdebase/apps/konsole/src/Filter.cpp:
Fix a performance problem with the email address matching filter. The email address regular expression was very general and could match very long pieces of text which were not actually email addresses.
Adding word boundary markers improves this significantly.
See the python xample code here for a test case: <a href="http://bugzilla.gnome.org/show_bug.cgi?id=350015">http://bugzilla.gnome.org/show_bug.cgi?id=350015</a>;
Diffs: 1 Revision 756554
Germain Garand committed changes in /trunk/KDE/kdelibs/khtml:
rework CSS3 opacity, for correctness and workable speed.
* Try hard to minimize the painting region.
* Blend layers atomically after off-screen rendering.
* Rework the PaintBuffer so that it can provide multiple buffers.
* Each transparent object must define a new stacking context so that their rendering sub-tree appears as atomic to ancestors, as wanted by CSS3.
Urs Wolfer committed changes in /trunk/KDE/kdebase/workspace/wallpapers:
Aaron J. Seigo committed changes in /trunk/KDE/kdebase/workspace/plasma/applets/kickoff/ui:
holy optimizations. don't go through the list of items twice, don't cache the indexes in a temporary list, don't call a method that checks the validity of the index and then returns an index from the model 1000s of time per paintEvent.
Diffs: 1, 2 Revision 757500
John Tapsell committed changes in /branches/KDE/4.0/kdebase/workspace/ksysguard/ksysguardd/ksysguardd.c:
Do not wakeup every second to check whether new disks have been added.
User Interface
Urs Wolfer committed changes in /trunk/KDE/kdebase/runtime/pics/oxygen/scalable/actions:
Optimize PNG files again.
Last optimization has been done almost two years ago. There a lot of new files in trunk (e.g all Oxygen stuff).
It's not the correct time to do that again (before the release).
This run saves again around 10MB of diskspace without any restrictions.
Urs Wolfer committed changes in /trunk/KDE/kdebase/runtime/pics/oxygen/scalable/actions:
Re-compress svgz files with:
find . -name "*.svgz" -exec advdef -z -4 '{}' \;
That saves around 6MB in trunk without any restrictions.
Also correct the svn mimetype for all svgz files which had a wrong one (which is thy reason why my fist commit failed...) with:
svn propset svn:mime-type 'application/octet-stream'
Urs Wolfer committed changes in /trunk/KDE/kdebase/runtime/pics/oxygen/scalable/actions:
Other
Development Tools
Dirk Mueller committed changes in /branches/KDE/4.0/kdevplatform:
kdevplatform is not released with KDE 4.0
Diffs: 1 Revision 757196
Educational
Torsten Rahn committed changes in /trunk/KDE/kdeedu/marble/src/lib:
- Beautify version number a bit more ;-)
- Bumping up the maximum zoom position of the slider. Once the data is in place that should allow a maximum zoom down to about 100m/pixel.
Diffs: 1, 2, 3 Revision 757089
Torsten Rahn committed changes in /trunk/KDE/kdeedu/marble/TODO:
4.0.1 TODO
Diffs: 1 Revision 757186
Inge Wallin committed changes in /trunk/KDE/kdeedu/marble/TODO:
Work in progress for TODOs for 4.1
Diffs: 1 Revision 757451
Graphics
Emanuele Tamponi committed changes in /trunk/playground/graphics/tamponi/painterlyframework/utilities/src/ipg:
Change the profile generation. Do not use different abscissas: final results (read here: mixing results) are by far better using always the same ones.
Add a script that created the default illuminants that are loaded with krita.
Diffs: 1, 2, 3, 4 Revision 755403
Emanuele Tamponi committed changes in /trunk/playground/graphics/tamponi/painterlyframework/utilities/src/ipg:
Finally, I decided to use both the "good mix" profile and the "good" profile. This means that while "good mix" provides better mixing capabilities, it's not sure that it will converge for every color, so it's better suited to be use with KisKSLCColorSpace.
The "good" profile always assure to converge into a reasonable reflectance spectrum, so it will work with both KSLC and KSQP. makedefault.* script are provided to generate the the default profile that are loaded with Krita.
Eike Hein committed changes in /trunk/KDE/kdegraphics/okular/ui:
Draw the page view message popup borders anti-aliased. Gets rid of my #1 Okular annoyance (yes, I'm petty like that).
Diffs: 1, 2 Revision 756098
Pino Toscano committed changes in /trunk/KDE/kdegraphics/okular/part.cpp:
disable the GHNS implementation, as not really ready, yet (hoping it's not too late)
Diffs: 1 Revision 757059
Pino Toscano committed changes in /trunk/KDE/kdegraphics/okular/generators/spectre:
Get rid of our custom anti-aliasing options and use the Document settings.
Also react correctly when they change, and a PS document is open.
Diffs: 1, 2, 3, 4 Revision 757659
KDE Base
Urs Wolfer committed changes in /trunk/KDE/kdebase/workspace:
Update artwork for logout dialog:
New Oxygen design
The sourcecode has no new features. I have only changed coordinates, colors and such things.
Due to render problems in Qt, we use a 'pre'-rendered svg image (exported as png and imported again into the svg).
The real source svg is also included: shutdowndialog.source.svg
I have also moved the button svgs into the main theme svg (with a different object id).
This dialog needs some more love after feature freeze is over:
* do not hardcode fonts and colors
* improve strings
* probably change buttons layout
* ...
For informations of the moon image used, see the CREDITS file (photo released under a Creative Commons license).
I think this file should be enough; if not, please tell me.
Thanks a lot Pinheiro for the great work!
Riccardo Iaconelli committed changes in /trunk/KDE/kdebase/workspace/ksplash/ksplashx/themes/default:
Jeremy Paul Whiting committed changes in /trunk/KDE/kdelibs/knewstuff/knewstuff2/core/coreengine.cpp:
default to automationOn automation policy, comment out extra unneeded code to load entries again based on automation policy, cache feeds with the feedname instead of the three question marks that were in there, cache entries in the componentnamed subfolder they belong to
Caching is now almost functional, except that cached entries are added to the feed and their equal internet entries are also added to the same feed currently... I'll try to find a BC way around that tomorrow hopefully.
Diffs: 1 Revision 755327
Aaron J. Seigo committed changes in /trunk/KDE/kdebase/workspace/libs/plasma/corona.cpp:
pager after the tasks... more .. "natural" feeling.
Diffs: 1 Revision 755519
Aaron J. Seigo committed changes in /trunk/KDE/kdebase/workspace/libs/plasma/phase.cpp:
QGraphicsItem::update isn't virtual, but we have overridden it in Plasma::Widget to provide paint caching; this broke element animations completely so hack around this. this hack can be removed in 4.1 as noted in the FIXME
Diffs: 1 Revision 755556
Shawn Starr committed changes in /trunk/KDE/kdebase/workspace/plasma/dataengines/weather/ions:
Update accreditation strings. This should satisfy legal requirements for atrributing data use. Explicitly note these strings as non i18n translatable
Diffs: 1, 2, 3 Revision 755736
Laurent Montel committed changes in /trunk/playground/base/plasma/applets:
Jason Stubbs committed changes in /trunk/KDE/kdebase/workspace/plasma/plasma/plasmaapp.cpp:
Dynamically set the pixmap cache size to the greater of 1.1 times the screen resolution and 1% of physical system memory. This should be enough to carry over until there's many SVG based applets available for people to run and overload their systems with. ;)
Luboš Luňák committed changes in /trunk/KDE/kdebase/workspace/kwin:
Don't apply DimInactive effect to override-redirect windows. Things like popups should be short-lived and mostly for the active window anyway.
Possibly could be revisited in the future when support for window grouping for unmanaged windows gets implemented too.
Oswald Buddenhagen committed changes in /trunk/KDE/kdebase/workspace/kdm/kfrontend/themer/parse.cpp:
mess with my coding style and die.
Diffs: 1 Revision 756202
Will Stephenson committed changes in /trunk/KDE/kdebase/workspace:
Add new Display systemsettings category to group the display settings. Recycling kcontrol's Display i18n, so shouldn't hurt too much. Change semi-ok'ed by Thomas Reitelbach on kde-i18n-doc
Diffs: 1, 2, 3, 4 Revision 756204
Aaron J. Seigo committed changes in /trunk/KDE/kdebase/workspace/plasma/desktoptheme:
new panel and dialog backgrounds, but QSvgRenderer is misreporting the size of the elements by one px each! i have no idea why and have banged my head against this one for hours now. *sob*
maybe zack can find something wrong here; the svgviewer example in qt doesnt render it properly either (there's an extra line in between the grouped elements even at 100% zoom); zack: if you dont' have time energy or care to look at this don't worry, it's just a long ball to you as i'm baffled atm.
Diffs: 1, 2 Revision 756290
Will Stephenson committed changes in /trunk/KDE/kdebase/workspace/kcontrol/kxkb:
Rearrange widgets so you can see 2 active layouts at default systemsettings size. There is still too much going on in this widget though but a fix would break string freeze
Diffs: 1, 2 Revision 756386
Jason Stubbs committed changes in /trunk/KDE/kdebase/workspace/libs/plasma:
Speed up the toolbox animations a bit. Arbitrary values, but 250ms still looks smooth here whereas 200ms (what I really wanted) doesn't. Nothing else appears to use Phase::moveItem() at the moment so am changing it directly.
The duration change in ToolBox is so that the moveItem() animation and customAnimation match up exactly.
Diffs: 1, 2 Revision 756456
Aaron J. Seigo committed changes in /trunk/KDE/kdebase/workspace/plasma/desktoptheme:
it occurred to me that by making border stretchable we could avoid the dotted border problem.
it does lead to a slight odd "center highlight" effect on the top (again due to QSvgRenderer getting the size of this element wrong) but it looks way better; this svg will still suck for panels on the top, left or right because you'll just get a black border...
but then since when was artwork in plasma ever something anyone actually paid any concern over. =(
Diffs: 1, 2 Revision 756552
Aaron J. Seigo committed changes in /trunk/KDE/kdebase/workspace/plasma/applets/icon/icon.cpp:
arbitrary upper limits are probably not a good idea; just don't make them so big if you won't want them that big. as for cpu usage, even HUUUGE icons on my 1.8Ghz machine don't even make plasma cough.
i'm sure with complex enough svg icons and a slow enough processor it would have a rendering impact but, again, just don't make them so frigging huge then.
Riccardo Iaconelli committed changes in /trunk/KDE/kdebase/runtime/knotify/sounds:
Luboš Luňák committed changes in /trunk/KDE/kdebase/workspace/kwin/effects:
Enable TrackMouse by default and change the activation to Shift+Meta.
Diffs: 1, 2 Revision 756762
Luboš Luňák committed changes in /trunk/KDE/kdebase/workspace/kwin/effects:
Luboš Luňák committed changes in /trunk/KDE/kdebase/workspace/kwin:
Aaron J. Seigo committed changes in /trunk/KDE/kdebase/workspace/plasma/runners/CMakeLists.txt:
remove the search runner for 4.0 since it seems to be the major cause of vastly bad pausing and other such problems for people in krunner
Diffs: 1 Revision 756809
Riccardo Iaconelli committed changes in /trunk/KDE/kdebase/workspace:
Bernhard Beschow committed changes in /trunk/KDE/kdebase/apps/konqueror/src:
Robert Knight committed changes in /trunk/KDE/kdebase/apps/konsole/src/MainWindow.cpp:
Add a TODO about implementing support for 'Open Folder in Tabs' with SSH bookmarks.
Diffs: 1 Revision 756953
Aaron J. Seigo committed changes in /trunk/KDE/kdebase/workspace/plasma/desktoptheme/widgets/panel-background.svg:
this is lame, lame, lame and then extra sugar lame on top. but QSvgRenderer has some *serious* issues when it resizes svg's; rounding errors get magnified to the point that they become these monstrously huge innacurracies =(
i can't do anything better for 4.0, but plan on working with TT on these issues for 4.1
Diffs: 1 Revision 756983
Germain Garand committed changes in /trunk/KDE/kdebase/apps/konqueror/src/konqmainwindow.cpp:
set konq combobox's default font to be the more sane Global font so we don't hurt our users eyes by default.
reviewed by Michael Pyne
Rafael Fernández López committed changes in /trunk/KDE/kdelibs:
This field should have never been translated. It began to be translated really late, and it was breaking KPluginSelector. This field is internal and never is shown to the user.
Plasma will need to use an extra field for using internationalized categories. Thanks to Bille, aacid, annma and everyone involved.
David Faure committed changes in /trunk/KDE/kdebase/workspace/wallpapers:
Remove outdated CREDITS file (all the wallpapers have been replaced), added LGPL-3 license as requested by ruphy.
Diffs: 1, 2 Revision 757171
Jakob Petsovits committed changes in /trunk/KDE:
I removed that "network" sucker icon two times already, but it likes to go the way of the undead. Having this one was one of the few icon showstopper issues (potentially impeding icon theme interoperability) and no matter how frozen the Oxygen theme is now, this icon needs to go.
Diffs: 1, 2, 3 Revision 757229
Robert Knight committed changes in /branches/KDE/4.0/kdebase/apps/konsole:
Add a summary of the major changes from KDE 3.5 to KDE 4.0. Add a list of known issues in KDE 4.0.0
Diffs: 1, 2 Revision 757540
Robert Knight committed changes in /trunk/KDE/kdebase/apps/konsole/desktop/tips:
Remove the tips file as Konsole no longer has a tips feature. Some of these hints are still relevant to Konsole and will find their way into the documentation. Others are obsolete.
Diffs: 1 Revision 757775
Robert Knight committed changes in /trunk/KDE/kdebase/apps/konsole/user-doc:
Move out of date documentation into historic/. I am not removing it from the repository completely because the content may still be of interest to some people. The remaining README files in this directory are still mostly relevant and correct.
Peter Penz committed changes in /trunk/KDE/kdelibs/kio/kio/previewjob.cpp:
Increase default preview size from 1 MB to 5 MB. TODO: it would be nice if PreviewJob would provide a static getter method for accessing the default size, so that applications like Dolphin - which allow to change the size - know the initial value.
Aaron J. Seigo committed changes in /trunk/KDE/kdebase/workspace/libs/plasma/widgets/tooltip.cpp:
* 150ms delay for already shown tooltips, just as we did with kicker, to prevent overwhelming lower end cpus (or network connections, for that matter)
* 500ms delay for new tooltips up from 300ms which worked rather nicely in kicker as well
(trying to learn from kicker, not forget it ;)
Diffs: 1 Revision 757827
KDE-PIM
Tom Albers committed changes in /trunk/playground/pim/mailody:
Mailody prepares for a rewrite based on the akonadi backend. Because kdepim will not be released and we do not wat to depend on kdepim, we include a copy of akonadi via a svn external.
Akonadi comes with some dependencies, like maildir and some files of libkdepim. This commit should deal with all that.
Allen Winter committed changes in /trunk/KDE/kdepim/korganizer:
by default, put the views toolbar on the right side of the app.
there are simply too many views now to go along the top.
of course, users can move this toolbar if they like.
hope this doesn't break the HIG.
Diffs: 1, 2 Revision 754957
Volker Krause committed changes in /trunk/KDE/kdepim/akonadi/server:
- disable the MySQL/Embedded plugin for now, it's currently not used and causes linking problems on Debian-based 64bit systems
- don't hardcode the path to mysqld
Diffs: 1, 2 Revision 756500
Office
Inge Wallin committed changes in /trunk/koffice/kchart:
Some project management: Make TODO even more up-to-date
Diffs: 1, 2 Revision 754906
Emanuele Tamponi committed changes in /trunk/koffice/krita/plugins/painterlyframework:
Almost definitively remove sRGB <-> RGB conversions because they're not useful in terms of visualizations and give bad mixing performance. Use the latest profile as default since it mixes veeeeery well. Don't compile anymore KisKSLinearColorSpace and remove it from the tests. Probably other fixes I don't remember.
Emanuele Tamponi committed changes in /trunk/koffice/krita/plugins/painterlyframework:
Now, in theory, you can even use quint16 and quint8 as channel type for the colorspace, but it gives very bad conversions (they're not large enough to store all the values).
Diffs: 1, 2, 3 Revision 755289
Emanuele Tamponi committed changes in /trunk/koffice/krita/plugins/painterlyframework:
Definitively, QP is not the better way to achieve good conversions from RGB because it needs to be *too* precise, loosing other performances (it's slow, for example, and gives not perfect mixing capabilities).
Anyway, it's good enough to work with 6 (six!) wavelengths.
Last note: I noticed that compositing may not work perfectly (and it's not intended to).
Jarosław Staniek committed changes in /trunk/koffice/kexi/core/kexiaboutdata.cpp:
Kexi about data
* Sharan Rao, welcome on board!
* the authors list reordered by last contribution date
Diffs: 1 Revision 755538
Emanuele Tamponi committed changes in /trunk/koffice/krita/plugins/painterlyframework/channel_converter.h:
A complete understanding and evaluating of this colorspace would take probably another year, because it depends on a set of parameters and equations that I've "invented" without studying their consequences and behavior.
It would be interesting in future work to study a bit what happens to the colorspace when you change the equations and paramethers while keeping the basic conditions.
First try (and last, for now): change the blackening function from
Rb = B_2 * R^2 + B_1 * R + B_0
to
Rb = B_2 / R + B_1 * R + B_0
the mixing capabilities are pretty much the same but I can see a wider spectrum of greens
Diffs: 1 Revision 756215
Boudewijn Rempt committed changes in /trunk/koffice/plugins/textshape:
I may have started the text shape, but there are about 12 lines that I can be blamed for left, most of them empty, so remove my copyright line.
Diffs: 1, 2, 3 Revision 757268
Boudewijn Rempt committed changes in /trunk/koffice/plugins/tableshape/DESIGN.txt:
Added some design notes
Diffs: 1 Revision 757356
Emanuele Tamponi committed changes in /trunk/koffice/krita/plugins/painterlyframework:
Various changes. Most important:
- now the color space loading code is much cleaner
- the tests have been rewritted in order to do some checks and they works great
- the mixing test has been disabled (completely removed) because I need to rewrite it as it will be the base upon which I'll draw all the graphs I'll need in future works.
Multimedia
Nikolaj Hald Nielsen committed changes in /trunk/extragear/multimedia/amarok/src/playlistbrowser:
This has got to rate among the top hacks of the year.... Make the PodcastCategoryDelegate's resize when they are selected so that additional info can be displayed.
Qt does not handle this use case very gracefully as the sizeHint function is not even called in many cases unless you kick the view rather hard.
Also, the option.state is never selected in sizeHint for some reason...
Diffs: 1, 2, 3, 4 Revision 754844
Jakob Petsovits committed changes in /trunk/KDE/kdemultimedia/kscd/docking.cpp:
Don't know if I'll make friends with that one, but kscd should use its app icon for docking like all the other nice apps do.
It doesn't do playback visualization or any fancy stuff, so there's no additional value that gets lost when switching back to the original kscd icon. (And the previous dock icon was just a simple audio CD anyways.)
Diffs: 1 Revision 756213
Koos Vriezen committed changes in /trunk/extragear/multimedia/kmplayer/src:
Remove the playlist resolving also changing the on status of the play button
Select input on the embedded windows and children to get in fullscreen a chance to get out of it by hovering over the bottom of the video.
Also the key press of 'f' is working. Needs a bit more thinking what to do with flash, now in a khtml page, moving the mouse too easily triggers the controlbar popup up (not that this is very funny, and hey this is an extra gear :).
Fix issue that flash and phonon would often disappear when going to fullscreen.
Networking Tools
Urs Wolfer committed changes in /trunk/KDE/kdenetwork/kget/main.cpp:
Bump version number to 2.0 for the KDE 4.0 release!
First final release of the rewritten KGet :)
Diffs: 1 Revision 755121
Tejas Dinkar committed changes in /trunk/playground/network/kopete/protocols/bonjour:
Tejas Dinkar committed changes in /trunk/playground/network/kopete/protocols/bonjour:
Urs Wolfer committed changes in /branches/work/soc-krdc:
soc-krdc branch is not required anymore
Diffs: 1 Revision 756717
Tom Albers committed changes in /trunk/KDE/kdenetwork:
lanbrowsing is not ready for release and the maintainer has asked for removal to the unmaintained area. The functionality has been replaced by zeroconf if I understand correctly.
Diffs: 1, 2, 3, 4 Revision 756781
Eike Hein committed changes in /trunk/KDE/kdenetwork/krdc/floatingtoolbar.cpp:
Make KRDC's floating toolbar identical to Okular's slightly improved version again: Alpha-blended contour instead of 1-bit mask, properly pixel-aligned border painting.
Diffs: 1 Revision 757417
Urs Wolfer committed changes in /trunk/KDE/kdenetwork:
Enable KGet Torrent plugin when BTCore (KTorrent) can be found on system. We need to think about that: probably we will copy a snapshot from the ktorrent lib to KGet later?
Diffs: 1, 2, 3 Revision 757609
Joris Guisson committed changes in /trunk/extragear/network/ktorrent/ktorrent:
Removed system tray icon speedbars options from config dialog, seeing that the speedbars are not yet ported, and they are not going to be for 3.0
Diffs: 1, 2 Revision 757709
User Interface
Jakob Petsovits committed changes in /trunk/KDE/kdebase/runtime/pics/oxygen:
Matthew Woehlke committed changes in /trunk/KDE/kdebase/runtime/kstyles/oxygen/oxygen.cpp:
stronger, color-safe coloring for inactive tabs
Diffs: 1 Revision 756078
Matthew Woehlke committed changes in /trunk/KDE/kdeartwork/ColorSchemes/Chrome.colors:
bring back chrome, changed quite a bit (since pinheiro wasn't going for the "softer selection" for oxygen, we'll do that but in chrome instead)
Diffs: 1 Revision 756275
Robert Knight committed changes in /trunk/KDE/kdebase/runtime/kstyles/oxygen:
Improvements to the appearance of flat group boxes as discussed on kde-core-devel. Use a bold, left aligned label with indented contents.
Diffs: 1, 2 Revision 756577
Nuno Fernades Pinheiro committed changes in /trunk/KDE/kdebase/runtime/pics/oxygen:
Jakob Petsovits committed changes in /trunk/KDE/kdebase/runtime/pics/oxygen:
Jakob Petsovits committed changes in /trunk/KDE/kdebase/runtime/pics/oxygen:
ruphy said they wouldn't kill me, he also says he can't commit it for some technical reasons, plus the transform-move icon is used in several places because it has been promised. (And would be missing otherwise.)
Committing the new icon, transform-move, on ruphy's behalf.
Forgive me for breaking the tagging freeze.
Utilities
Friedrich W. H. Kossebau committed changes in /:
Moving KHexEdit to the Off, as dicussed with the release team.
Is only halfways ported to KDE4 (compiles at least) and has no active maintainer.
Let's hope Okteta is ready for KDE 4.1 to close the gap this is leaving.
Kept the Okteta libs and parts in the subdirectories core, gui and parts, as they are maintained and used.
Jakob Petsovits committed changes in /trunk/KDE:
Games
Mauricio Piacentini committed changes in /trunk/KDE/kdegames/kolf:
Fix garbage in intro screen, put new Kolf SVG banner.
Diffs: 1, 2, 3 Revision 755701
Gueudelot Olivier committed changes in /trunk/playground/games/ktankeditor:
Albert Astals Cid committed changes in /trunk/playground/games/ktank:
somehow my instructions where not good enough to achieve a dir called ktank and have ktankeditor inside, i suck
Diffs: 1, 2, 3 Revision 757809
Other
Matt Rogers committed changes in /trunk/bugs/3.0:
Port the component report to bugzilla 3.0 and templatize it.
Diffs: 1, 2, 3 Revision 755187
Albert Astals Cid committed changes in /trunk/kde-common/release/language_list:
removing languages that do not meet the 100% essentials to be in the KDE4 releease
<a href="http://l10n.kde.org/stats/gui/trunk-kde4/essential.php">http://l10n.kde.org/stats/gui/trunk-kde4/essential.php</a>;
Diffs: 1 Revision 755531
Albert Astals Cid committed changes in /trunk/kde-common/makemessages:
today we won't process trunk/l10n-kde4 so that we ensure we don't get new kde 4.1 messages into kde 4.0 translations, thanks coolo for the tip
Diffs: 1 Revision 757271
Riccardo Iaconelli committed changes in /trunk/playground/artwork/Oxygen/release-event:
Release event shirt, take one
Diffs: 1, 2, 3 Revision 757283
