While the world is still recovering from the work on KDE 4.0.0, we are ready to announce the release of KDE 4.0.1, the first bug fix update of the KDE 4.0 desktop. KDE 4.0.1 contains numerous bugfixes such as stability improvements, performance improvements and, as in every point release, updated translations for most components. Lots of work has been put into shared components making the life of most applications easier. Particularly striking is also the high number of bugfixes in KHTML. Have a look at the change log for a more detailed, if maybe not 100% complete list of improvements. KDE 4.0.1 is already translated into 48 languages with more coming soon.
The KDE 4.0 branch receives regular updates, including bugfixes in trunk/ which are backported to the KDE 4.0 branch and more will appear in our monthly bugfix updates. For those following the development more closely, a shift towards the development tree that is to become KDE 4.1 this summer can be noticed. KDE 4.1 will be based on Qt 4.4 with all its performance and functionality improvements. KDE 4.0.2, with even more of the above goodness, will be released in early March. While KDE 4.0 is still rather young, we hope to be able to address even more issues people encounter while getting used to KDE 4, so make sure to keep your KDE up to date.
For those among us that prefer the more stable and proven KDE 3.5 branch, KDE 3.5.9 will be available later this month (planned for February, 19th) with an updated KDE-PIM from the enterprise branch and of course lots of other improvements.
Comments
Does anyone know how to simply remove the zoom thingy up in the corner? It's REALLY useless when you are using Compiz-Fusion with KDE4, so it's more or less just annoying now. I don't know what config file to butcher to get it off my screen.
I think we need to get the most creative people on here to make some
USER GENERATED VIDEOS showing off the functionality of Plasma/Plasmoids, etc.
Like not just the basics, some off the wall cutting edge stuff. Make it fun to watch too.
People learn visually, and by doing.
I think this is the success of Apple's products. Rather than include a boring instruction manual, all the features are showed off at the keynote and through various Youtube and similar videos.
I think this would help create more buzz about KDE 4.0 too. Too many people think KDE 4.0 is a static big (screen real-estate wasting) task-bar at the bottom and a few "icons." We need to change that perception. Eye-candy (visual wow factor!!) is what sells people to Linux/KDE. Compiz fusion was the reason I switched to Linux, I'll admit it.
What do you guys think?
Maybe some contest?*
This could increase awareness and have some modders join the KDE ranks.
To all the developers: Great job so far on the features. You really did great work!!
We still have a long road ahead of us. Don't give up/slow down yet.
________
* the prize could be bragging rights for the most customized desktop.
I like the idea...
We should have feature presentation videos. :)
I actually proposed this on the kde-promo ML a few weeks ago (like a month ago, to be precise), but I haven't found the time to make those Plasma video tutorials. Worse than that, recordmydesktop segfaults every time so at the moment I'm rather unable to record anything.
My idea was to show:
- Adding applets
- Adding applets to panel
- Applet operations
Yes, please make vids.
Love to see what features are possible.
Then please make a thread, or link them from kde.org somehow.
Tried out the Kubuntu packages. Getting slowly better but still not really usable. By far the worst thing for me are those stupid semi-transparent boxes behinf every icon. And without any ability to create (labeled) containments for multiple icons there isnt that much advantage for me in contrast to KDE 3.5. Though I must admit it's quite cool to be able to put a Dilbert comic on your desktop and even rotate it freely.
you can make those disappear, I think
Locking the widgets makes it disappear.
Indeed it does but then you can't change desktop wallpaper, move things and stuff like that.
I'm really starting to think that the Ubuntu people gave up on Kubuntu, and KDE.
Which is very sad.
I'm comparing the alphas of Fedora, openSUSE, and others, then KDE under Kubuntu looks halfa$$ed. Like there is no passion behind it. Everything is default, then not even well put together.
Get your act together Kubuntu, or stop carrying KDE altogether. At the current state you're embarrassing us KDE fans and the whole KDE development team.
"Get your act together Kubuntu, or stop carrying KDE altogether. At the current state you're embarrassing us KDE fans and the whole KDE development team."
What a ridiculous remark! Currently, only KDE 3 is actually ready for "prime time" in that you could sit a non-technical user down in front of it, have them expect it to more or less work, and have a bunch of people willing to support it (in the end-user support sense, not "how do I compile this?" sense).
As for the embarrassment, the "KDE fans" do this all by themselves. I've used KDE now for around eight years or so, and it's a great environment for end-users (contrary to what various usability "experts" say), but I certainly wouldn't want the job of packaging it all up and supporting it, and that's KDE 3.x in a fairly mature form, let alone the fruits of the latest development effort with all its chopping and changing.
The embarrassment has already been on the KDE developers for hyping up KDE 4.0 and then delivering something that people report to be less usable than KDE 3.0. Perhaps the Kubuntu people don't feel like switching their default desktop to KDE 4 and sharing in the embarrassment: an understandable choice, and in stark contrast to your "stop carrying KDE altogether" outburst which betrays the bizarre belief that it is now "verboten" to ship KDE 3, now that KDE 4 has burst forth in all its glory.
If you are a KDE fan I think it would be better to use opensuse rather than any other distros.
I agree with you totally. I also agree with what S said, the KDE version of Ubuntu (Kubuntu a.k.a Ubuntu's unwanted child) is a shame for the KDE world. It's put together half-heartedly and that's why I decided to stick to openSuse after trying Kubuntu so many times. Ubuntu is without the shadow of a doubt the best Gnome distro that I have tried until now but I don't like Gnome. On the other hand Kubuntu is the worst KDE distro around and it doesn't matter which version of KDE they use.
It's really a pitty that they treat the best Unix/Linux DE like that :(
+1 I agree too.
I used SuSE since version 9.0. It always seemed "finished". Clear cut, thought out, everything. (drivers and mounting of hardware seemed to be an issue back then, as well as the headache that are RPM dependencies. - it's better now.)
I tried Kubuntu when 7.10 came out because it's the most hyped up distro at the time. Suse has all the flak because of the Microsoft deal, so I figured out, why not try out the competion. Since I "grew up" on KDE, I decided to use Kubuntu, instead of the extremely popular Ubuntu. Right from the start it felt like Kubuntu was put together as an afterthought. The desktop was all the default install. The OS selector screen looks like it came from the MS-Dos days. All the icons are KDE default, same as the taskbars. On the online forums it felt that Kubuntu was a red headed stepchild indeed. Every useful information came from Ubuntu. I keep having to "translate" the tricks in my head to work in a KDE environment. It's like Canonical isn't even trying to use KDE and they have been forced to carry it.
Needless to say, I'm back at openSUSE. Oh, how I missed thee Lizard.. :-)
What I miss from Kubuntu is the Debian based-ness. I love Apt-get. So much easier to use than RPM's (No dependency problems either.) Just no "one-click" under Kubuntu :(
Either way, I'm glad there is multiple distros, and I'm glad there is choice.
There is only one Windows Vista, and that os has a "take it, or leave it" attitude. I can't wait to use KDE desktop manager on the Windows environment.
> What I miss from Kubuntu is the Debian based-ness. I love Apt-get. So much easier to use than RPM's
Orange and apples? Either you compare dpkg with rpm or apt-get with zypper.
We use Ubuntu a lot here, and decided to try out 4.0.1 The (K)ubuntu version sucks. No customization at all, almost no features. No progress.
What is wrong with the (K)ubuntu people? Are they asleep at the wheel?
All their development seems to be gnome, 4.0 seems to be completely ignored. (3.5 doesn't seem much better.)
We're going to try Fedora alpha and opensuse alpha this week. Hopefully they're better.
Testing the alphas doesn't seem like a good/fair way to evaluate distro's to me. For example, opensuse 11.0 is at alpha2 today there are 3 more alphas and probably 4 more beta versions after that before release mid-year. It's likely to be so cutting-edge it'll bleed all over your PC! :)
I would try the stable live-cd of opensuse 10.3 which includes KDE4.01 backported. http://home.kde.org/~binner/kde-four-live/
I imagine there are Fedora spins too (which to be fair I should try out to check that suse is still best).
We have KDE 4 packages for Fedora 8 in the kde-redhat unstable repository (currently 4.0.0, 4.0.1 coming soon), but we don't have a live CD of that. We do have a KDE live CD spin of the Fedora 9 alpha (but that was frozen a couple weeks ago, so it's still 4.0.0 and still has some bugs which are now fixed in Rawhide), and occasional Rawhide snapshots (I don't know when we'll have a new one available though, currently the alpha is the latest).
Sorry, probably not what you wanted to hear, but we're focusing most of our energies on developing the next release, not on shiny discs for the impatient. ;-)
Yea, we use the alpha's just for testing purposes, not for production environments.
Since in our company everything seems to move so slow and takes forever, we have to start pitching the next distro to use now, in hopes to get it approved by June.
We Test the alphas, to get an idea of what distro to start pitching now, so we can switch to it in time the final release arrives.
"The (K)ubuntu version sucks. No customization at all, almost no features. No progress."
I don't see why people are complaining about Kubuntu not butchering KDE like other distributions. It really irks me to not have a consistent KDE look and feel across different distributions, and Kubuntu does a good job at preserving that consistency. To each his own, I suppose.
As far as Suse goes: Even if Novell hadn't betrayed the Linux community, I still wouldn't use anything Suse-related simply because it's slower than thick molasses on a cold winter night. I have to wonder if there is some 80286 compile-time switch that the Suse people are fond of enabling on all of their builds, or if maybe Suse's user interface is actually a cleverly themed Java-based system. It is juuuust...sooooo...slooooowwww compared to everything else out there.
"Even if Novell hadn't betrayed the Linux community"
What betrayal did Novell do to Linux community? What about the financial and developer support they are doing for various Linux based projects? If you feel so and want to stop using Novell related products just because of their pact with Microsoft then I think you may have to quit using Linux because Novell is supporting many of the opensource products used in a Linux distro (including the kernel, KDE, Gnome etc).
"I still wouldn't use anything Suse-related simply because it's slower than thick molasses on a cold winter night"
I think its been years since you used opensuse. Well try using the current version and let us know if you still feel opensuse is tooooooooooooooo sloooooooowwwwwwww? Seriously there have been lots of improvement in opensuse on each release. Faster boot time, faster desktop, professional look and feel and what not? Well I have tried almost every version of Kubuntu and I don't feel any changes or customization in it on each release. Not only that it is a know fact that canonical is more interested in improving Ubuntu (GNOME version) and not the Kubuntu, so I am not expecting any serious improvement in Kubuntu.
Thank you for keeping KDE3.5.n alive.
It's KDE 3.5.x, not n.
> The KDE 4.0 branch receives regular updates, including bugfixes in trunk/
> which are backported to the KDE 4.0 branch
So, we are back to this. :-(
This method is one of the issues with KDE quality problems. Bugs reported against the current release should first be fixed on the release branch and then the fix should be applied to TRUNK. There are many valid reasons to do it this way (most significant to me is that it is easier to properly fix the bug in stable code) and nobody seems to be able to come up with any reason to do it the way we do. "It works in TRUNK" is not a reason to close a bug unless the bug was reported against TRUNK.
Fixing things in trunk first makes sure the bug won't reappear in later releases. While unfixed bugs in the branch are annoying short term, branch-only bugfixes are much worse because long term, they unavoidably result in a regression. Please try thinking more in the longer term!
As for:
> most significant to me is that it is easier to properly fix the bug in stable code
some developers actually work that way when actually writing and testing the patch, they'll just commit the fix to trunk "first" (well, probably within seconds or minutes of each other, but in descending version order to follow the protocol). I do this sometimes, but not always. I guess a sizable portion of the fixes backported almost instantly have actually been developed against the branch in the first place.
> Fixing things in trunk first makes sure the bug won't reappear in later
> releases.
Actually, this isn't the case. Bugs "fixed" in unstable code often reappear. It would be best if such fixes were added to a "punch list" somewhere for further (and regression) testing.
Regarding: "to follow the protocol". I find it most odd that developers would have to pretend that they were doing things the wrong way, but it is slightly encouraging to see that some are doing it correctly. But, why is the "protocol" based on a poor model?
Obviously, bugs need to be fixed in TRUNK as well and a branch bug shouldn't be marked as fixed till it also is fixed in TRUNK.
Well, it depends on the nature of the bug, but for most classes of bugs, the only way they can reappear is if the fix is directly undone (e.g. by merging a work branch to which it was forgotten to apply the fix). Of course, there are also the bugs where nobody really understands what causes them, and the "fix" only makes it latent and ready to hit again later. But that shouldn't be the norm! For bugs where it's clear what causes them, it is also irrelevant how "stable" the surrounding code is, and testing any one branch (trunk or any release branch) is enough to confirm that it's fixed.
I usually miss the mentioning of unit tests in such discussions. Does KDE employ them in any significant fashion? I'm coming mostly from the Java world where unit tests are a commonly accepted best practice and project leads usually keep an eye on the block and path coverage. It helps tremendously with detecting regressions and makes refactoring code less error-prone. It could probably help KDE to introduce a policy that no new code can be merged into trunk/ without the accompanying tests but this is probably wishful thinking due amount of already existing code.
David Faure looooves Unit Tests and uses them (and encourages others to use them) pretty extensively :)
> Well, it depends on the nature of the bug ...
Agree 100% -- probably should have said that.
OTOH, you forgot about Murphy's Law. :-) And, you are also telling me that the best practices for software engineering that I was taught are wrong. Please excluse me if I don't believe you and continue to believe that hacking code isn't the best software engineering method available.
One thing that we do know for sure is that if the code isn't changed (e.g. to add new features) that changes to the code won't cause a bug to reappear. We know that bugs do reappear and regressions do occur in unstable code (sometimes even is stable code).
Working on stable code allows better analysis of the bug and (I hope) a better and more permanent fix. The problem with this is that sometimes the TRUNK code has changed so much that the fix is either irrelevant or won't work. Well at least you understand the problem.
With the previous KDE generations every release had a "requires or benefits from ..." list of external software/libraries. For example, for 3.5.x this list is at http://www.kde.org/info/requirements/3.5.php. For 4.x, however, we have a wiki: http://techbase.kde.org/Getting_Started/Build/KDE4, which is too distro-specific. I'm running LFS (Linux from Scratch) which does not fit into any of the "recipes"
I'd rather have the old-style listing.
http://techbase.kde.org/Schedules/KDE4/Requirements has what you want.
The "Software Requirements listed by Function" chapter is incomplete.
But the "Software Requirements listed by Module" chapter should been complete.
Thanks fot the info.
BTW... where can I get FooPackage? And how Foo will change my life? :)
Does the fix for using double click get into 4.0.1?
I never use single click and in 4.0.0 setting to double click had two major problems:
a) plasma didn't knew about new configuration without restarting whole kde session
b) double click didn't worked at all
I tested and it just looks the smae on 4.0.1 in kubuntu :(
But maybe it's distro-specific or configuration problem.
Just a quick feedback: Konqueror from KDE 4.0.1 now shows http://www.kde.org correctly (my 4.0.0 installation didn't) but http://www.spiegel.de still does not work (i.e. all boxes are rendered vertically, making the page totally unusable).
What's the news on Amarok?
The program has a great following at our University. Students as well as techers prefer it over iTunes and it's great under Linux.
We can't wait for the Windows and Mac versions!!
We'd love to see more of KDE ported to Windows and Mac. We're stuck with Windows and Mac OS-X machines in the computer labs, but would love to install KDE and Plasma on top of that.
Is there going to be an iPhone/iPod Touch port of Amarok?
Just follow the developer blogs, for example this post by Shane King:
http://amarok.kde.org/blog/archives/583-Windows-Binaries-of-Amarok-2-Tec...
Cool.. Thankies..
I LOVE AMAROK.
Cool to see a newsletter on KDE about it too. :)
Any new developments on Amarok?
@everyone who knows a bit of C++..
instead of writing rants here on the dot or waiting for someone to fix a bug.. get the sources from SVN and have a look! I myself started to fix some of the small strange glitches myself and the KDE sources are really nicely documented, with superb API docs, so START HACKING ON IT TODAY! Every bug you fix, god resurrects a kitten! And it's fun, too :)
The panel is just awful!
I'm hoping that by the time 4.1 is around there will be multiple "panel's" to choose from.
The idea is that it's modular. I nominate a gnome themed panel to ease the transition for users. (also to mess with people's heads.. :p I did that when I made my KDE 3.5 install look like Windows XP default one day, and Windows Vista default another day. The reaction of people is priceless.. ]:-)>~ )
There should be an easy way to find said themes. KDE-look.org is confusing at best. They don't really make a distinction between KDE 3, and KDE 4 and it's hard to use for beginners.
We need an alternative, and links from within KDE 4, and from KDE.org. It should be easy to find widgets, Plasma apps, "Panel's", Window decorations. It be cool to see some google vids of what people have come up with.
KDE 4.0 is really amazing. One problem I've been having in KDE is that you cannot move between tabs with a scroll wheel. This has been in Gnome and is a very handy feature - just place the mouse on top of a tab and scroll over it to go to the next tab. This is what I've been looking for in successive KDE releases and is a gauge I use to measure if KDE is responsive to user requests. I'm surprised KDE4 doesn't have this. Are there any plans to include this feature in 4.0.2 or 4.1?
KDE 4.0 is great! One important feature often overlooked by KDE guys is the changing of tabs by scrolling over them. Gnome has had this feature for ages and is extremely handy. Amazingly, konsole has this feature (the tabs change by just scrolling over them), so it is technically possible. Can't this feature be adopted from konsole to apply to the whole of KDE4. Can we see this feature in 4.0.2 or 4.1?
KDE has had this feature for ages.
Any specific application where it doesn't work?
Try the help -> About menu of just about any KDE app! Even the about KDE dialog. Also, the system settings app.
Any new compositioning effects with that release?
(for my fast "daily-driver" machine. I realize on a 600mhz machine it won't work.. :) )
It's really cool that finally something similar to Compiz-fusion exists under KDE.
No new features are being added until 4.1. 4.0 is in a "feature freeze".
There are several annoying things in gwenview.
1) Double clicking on a photo thumbnail should open it (in full screen). As it stands, e.g. in browse view, nothing happens when you double click. Instead, when you hover over it, some icons popup which include open in fullscreen. IMHO, double clicking it should just do the same thing.
2) Apparently, Gwenview does not scale photos to fit the screen or window and does not even have an option in its settings to enable/disable this feature. This is very annoying since one would think that opening a photo in full-screen mode would scale that photo to fit the screen instead of showing it at actual size! At least put an option to enable the scaling (with different algorithms e.g. linear, bicubic, etc).
3) There is a slight flaw in thumbnailing. As it stands, generation of thunbnails of a large photo collection in browse view is sequential. What I mean is, it tends to thumbnail images one after the other and even when you've scrolled down, it takes a lot of time for it to catch up to your screen as it is still processing those already passed. I think gwenview would appear more responsive if the thumbnailing was user centric and generate those that are in the screen as a priority to those not being see. Just a side note, does gwenview utilize the Qt concurrency thingy?? In the age of multicore, thumbnailing would really benefit from this concurrency.
Several things here.
1) Should always open file in relevant app e.g. Fileopen in kate and you select an mp3 file (not text), instead of giving you garbage & telling you its a binary file, why not open the relevat app e.g. amarok2, if associated with the mime type or ask. After opening in that app maintain the original file-open dialog.
2) File-open dialog should take most of the screen realestate IMO. Look, it is a blocking dialog & you are not going to be using the app while its open. Its better to have most (if not all) of the screen real-estate for such a temporary task as opening a file so as to make it natural. The tiny default size is a relic of the old days when widescreens didn't exist and the maximum resolution was 640x480.
You see, we must assume that we are dealing with users who who want things done, not the processes of getting them done. This user does not know (nor care) about mimetypes or binary/text stuff. He/she knows that a file called 'sales forecasts' contains what he/she wants. This historic assumption should be corrected.
> 1) Should always open file in relevant app e.g. Fileopen in kate and you select an mp3 file (not text), instead of giving you garbage & telling you its a binary file, why not open the relevat app e.g. amarok2, if associated with the mime type or ask. After opening in that app maintain the original file-open dialog.
That would not be a good idea, because, for example, the extension might be wrong. Also, most people open a _file manager_ whose job is running external apps, to run external apps. It's not normal, nor does it make sense, to open a text editor just so it can run Amarok.
> 2) File-open dialog should take most of the screen realestate IMO. Look, it is a blocking dialog & you are not going to be using the app while its open. Its better to have most (if not all) of the screen real-estate for such a temporary task as opening a file so as to make it natural. The tiny default size is a relic of the old days when widescreens didn't exist and the maximum resolution was 640x480.
That I can agree with. However, please don't open it full screen. I may need to look beside it.