The KDE Project is happy to announce a new major release of the award-winning K Desktop Environment. Many features have been added or refined, making KDE 3.5 the most complete, stable and integrated free desktop environment available. For a quick look at some of the new features see the visual guide to KDE 3.5. Packages are available now for ArchLinux, Kubuntu, Slackware and SuSE or try Konstruct to build it yourself.
Notable changes include:
- Konqueror is the second major web browser to pass the Acid2 CSS test, ahead of Firefox and Internet Explorer
- Konqueror can also free webpages from adverts with its new ad-block feature
- SuperKaramba is included in KDE, providing well-integrated and easy-to-install widgets for the user's desktop
- Kopete has support for MSN and Yahoo! webcams
- The edutainment module has three new applications (KGeography, Kanagram and blinKen), and has seen huge improvements in Kalzium
Stephan Kulow, KDE Release Coordinator, said: "The improvements made in the past year show how mature the KDE Project is. KDE is the most powerful desktop environment and development platform in the market. With huge changes expected in KDE 4, our next release, KDE 3.5 should provide users with the perfect productivity platform for the next couple of years."
Comments
I can't argue with you. What you said here is true. For me a stable system is more important, than to have the latest stuff around.
Last time I had upgraded from KDE 3.2 to KDE 3.3.2 I had big problems
with upgrading my userprofile. I managed to solve it myself, but it was a major hassle. Things like that should be adressed, so that a upgrade makes less headaches.
I can wait. And if I am feeling bored, I will try out the new release. As I noticed by running a live CD KDE 3.5 feels faster than older releases.
That is a good sign :-)
If you look at the very last picture in the Visual guide, showing the new-media notifier, you'll see that the "OK" button is shorter than the buttons on either side of it. Qt's layout helps maintain the text baseline but, if it's still present in the actual release, it's a silly little mistake to have made.
The screenshot is http://www.kde.org/announcements/visual_guide_images-3.5/device-popup.png
The option to make command buttons all the same width is something that Qt has never been able to do. I think some themes try to do it, not sure how well they succeed.
I fully agree with you; its ugly and since Windows has been doing the equal-width thing for a couple or releases already Qt (or KDE) really should follow.
You can enforce this through the style by defining a certain minimum width for command buttons. We do that for Windows style and it covers most cases. The case in the screenshot would be covered well.
Another problem is really plastik's, and you see it in the screenshot: the default button appears smaller in all four directions. That's space taken away for the default button indicator. Qt's own Motif and Windows styles do it better: they take the same space away from all autoDefault buttons, so all buttons appear to have the same hight.
> Another problem is really plastik's, and you see it in
> the screenshot: the default button appears smaller in all
> four directions. That's space taken away for the default
> button indicator.
The default button indicator should have a nice colour and not the background colour!!
I wasn't talking about width, I was talking about *height*. Matthias seems to have explained what's wrong though (it's Plastik's fault ;-) ).
To be honest, I don't really mind variable width; so long as buttons don't get too narrow I don't see any issue.
He was talking about height, and unless there's a very good usability reason for it it looks like arse. How the hell has no one seen that?
The big problem here of course is not the button -- switching to another style will help there -- but the wording. It should have said "An audio CD has been inserted." All the verbosity about mediums (new or otherwise) and what do you want to do? is superfluous. I'd also use "this" instead of "that" in the "Always..." message. And I'd left-align the "configure" button to create some distance between the ok and cancel button, and reword the cancel button to "Do nothing for me, and remove the silly icon from my desktop, too, please, and be right snappy about it, cocky". Or perhaps just "Close"
Errrr, you're avoiding the point. The OK button is smaller in height to all the other buttons around it. It looks like absolute crap unless there is a goo usability reason for it. Seriously - no one picked up on this?
Please scroll up a little bit and you'll find that someone going by the name of "Segedunum" already posted the exact same thing you did. Only he used the word "arse" rather than "crap".
Have a very nice day!
"Please scroll up a little bit and you'll find that someone going by the name of "Segedunum" already posted the exact same thing you did. Only he used the word "arse" rather than "crap"."
Gee. If you scroll up a little bit further you'll also see another comment that doesn't answer the question either! It seems as though some people may be a little embarrased they didn't notice this.
Have a nice day!
The button is a function of the Plastik style; if you use another widget style, then you won't have this problem. And even with Plastik it may look bad, but it isn't half as bad as the wording of the dialog. Upon consideration, I think the cancel button can go, too, since the cancel action is already present in the option list.
"The button is a function of the Plastik style; if you use another widget style, then you won't have this problem."
Sigh. Plastik is the default style of KDE........
My KDE shows a blue line around the "OK" button (which is very good!).
I did not do any special. Style: plastik, Colour scheme:plastik.
Maybe it's a bug con the computer where the screenshot has been taken.
"My KDE shows a blue line around the "OK" button (which is very good!).
I did not do any special. Style: plastik, Colour scheme:plastik.
Maybe it's a bug con the computer where the screenshot has been taken."
Is this KDE 3.5? I sincerely hope so. I haven't used an RC of 3.5 nor have I checked out SVN for quite a while so I don't know.
If it is just something wrong with the set up of the machine that the screenshots were taken on can somebody just say so?
Ok, I did investigate a bit:
This bug can only be seen in some applications, for example the "what do you want to do" dialog or the "file already exists" dialog of Konqueror.
The bug can not be seen on the buttons of the kontrol center.
How to reproduce:
Open konqueror in file manager mode.
Klick on a file, hold mouse down, press and drop it anywhere in the same directory. Konqueror asks: "File Already Exists This action would overwrite..."
The "suggest new name" and "Continue" buttons have the same size, the preselected "Cancel" button shows the reduced size. Press two times and the "Cancel" button becomes normal again.
In Kcontrol or in this web form buttons stay always the same size regardless if they become activated () or not.
If you select another style (for example ".net") this bug disappeares.
Hmmm. Interesting, thanks.
imho your suggestions would really improve this little dialog. Please fight for it, make a report or *heyho* would one of the devs please obey to his recoms they make the pain go away....
Checking my own computer (also 3.5) the problem is that the actual height of the buttons is exactly the same, but the visual size is indeed smaller for the default button. This means that there are some very light lines around the default button that take space away from the button itself.
The obvious solution would be to make the button larger. Not sure how well that would work, though.
I guess I have gotten used to it and never noticed it :(
It's up to the individual developers whether they fix bugs or add new features. No one is there to force them to do one or the other. It's called freedom.
That said, bugs are still getting fixed. No competent developer ignores reproducible bugs in release software. They do fix a lot of bugs. Some they can't fix, because it's outside of their area of expertise. Others may be minor and not worth the risk to fix in the 3.x codebase (every bug fix has the potential to introduce new bugs). Still others are currently being worked on, and will be merged in for 3.5.1. Then there are those few bugs that are design/architecture related, that must be fixed in the 4.x codebase.
3.5 is a feature release, and the focus is on new features. KDE could keep going on and on and on with 3.4.4, 3.4.5, 3.4.6, 3.4.7, and so on. But without new features users lose their excitement and developers get bored. This is especially true with a high visibility project like KDE. Thus every so often there is a feature release.
> No competent developer ignores reproducible bugs in release software.
Then should I believe that the developers that ignore (or worse summarily close) my bug reports are not competent? :-)
> KDE could keep going on and on and on with 3.4.4, 3.4.5, 3.4.6, 3.4.7,
> and so on.
And if we did that we would eventually have the most stable and bug free software on the market. Some users would prefer that to new features that don't work and the serious regressions that seem to come with them.
KDE 3.5 totally breaks my desktop due to a serious regression, and several serious issues which I have reported have not been fixed.
> KDE 3.5 totally breaks my desktop due to a serious regression,
> and several serious issues which I have reported have not been fixed.
Which regression/issues are those? Could you quote bug numbers?
The serious regression which makes my desktop unusable is: Bug 116562
Some unresolved serious issues, 53052, 59901, 06542, 108510, 107087
Personally I would class these bugs as "annoying", not "serious". I certainly think "unusable" would be going too far.
Please look at the screen shots that I attached to bug 116562.
My previous desktop setup is now unusable.
From the bug report it looks like the size of panels is not correctly handled when creating a no-icon placement zone. Rather than getting it correctly from panel/icon size ratio, it looks like it uses a "better safe than sorry" approach. A bug creating some annoyance for some users, but IMHO it's preferable to the bug of having panels overlapping icons when unhidden.
>My previous desktop setup is now unusable.
Which I guess is very annoying for you, but not serious. Afterall you can simply reorder your icons.
And I agree with Paul's classification of those other bugs as annoying too. Not that they should not get fixed, but they are far from serious. Besides it's grate you help by folowing up your own bugs, it's far to many stale reports in there. Hope you close those that do not longer apply, too:-)
I have posted two more screen shots to bug 116562.
Specifically, please look at:
http://bugs.kde.org/attachment.cgi?id=13831&action=view
I have added yellow cross hatching to show the very limited area of the desktop where I can place icons. So, although this bug doesn't even matter with the default setup with 3 icons and one panel, it totally screws up my rather elaborate setup.
Does not look to nice, I agree. But looking at the other screenshot:
http://bugs.kde.org/attachment.cgi?id=13832&action=view
The top and botton part look correct, and the same for the right side(if that clock of yours is some kind of panel). But the thing in the middle of the screen looks strange, and most likely whats breaking your setup. Without knowing the exact code I guess the no-icon placement code most likely suppose you have the panels at the screen edge. Not having the possibility to have icons on both sides of it. Other than that the distance to the icons look correct. I think you have to move that one to reclaim your desktop space.
The thing in the middle is a panel which is supposed to be upper left. The problem is mostly caused by the external taskbar which is lower left. I also note that the small panel that holds only my clock has: "Allow other windows to cover the panel" checked so it shouldn't influence the position of the desktop icons either. I did the unhidden screen shot to show that the icon positioning is being set by the panels which are hidden just the same as if they were not hidden which is not correct. Auto hide panels should not influence the position of the desktop icons.
>The thing in the middle is a panel
>which is supposed to be upper left.
>The problem is mostly caused by the
>external taskbar which is lower left.
This is your real bug then.
>the icon positioning is being set by
>the panels which are hidden just the
>same as if they were not hidden which
>is not correct.
No, it's actually the correct behavior. If not, changing settings to/from hide/no hide of panels would lead to automatic rearranging of desktop icons which is not wanted. And more importantly panels should never cover desktop icons regardless of settings, anything else is a major bug.
> This is your real bug then.
That is what I said, space is being reserved for the hidden External Taskbar and that is a bug.
> No, it's actually the correct behavior.
This is not the way it worked in 3.4.x or, IIRC, any previous 3.x.y version.
To elaborate on this, in 3.4.x, two hidden panels could be on the same side of the screen as long as there was some way to determine which one would unhide when you did what. In my case I have the External Taskbar in the left bottom and a Panel in the left top. Since neither one is full "length" (actually height) there was never a problem. Now in 3.5.0, a full height space is reserved for both of them (full height space is being reserved for the External Taskbar) with the result that the left top Panel has spaced reserved near the center of the screen where it can never go unless both the External Taskbar and the Panel were unhidden at the same time which is usually impossible.
> If not, changing settings to/from hide/no hide of panels would lead to
> automatic rearranging of desktop icons which is not wanted.
This behavior not being wanted, might be the case in some instances, but as you can see this is not always the case and does not work with my DeskTop setup. Therefore, as I said, if this "feature" is what is wanted, it is going to have to be a configurable option.
> I would prefer, that developers concentrate on fixing bugs than adding new features.
Good news for you, all next releases for foreseeable feature will be bugfix releases.
> I can't count how many times konqueror has crashed when broswing or working locally as a filemanager.
And you use the current version (as of yesterday) and reported the bugs?
> I will continue to use KDE 3.3.2 und will perhaps upgrade to release 3.4.
I don't think that anyone will fix anymore bugs in KDE 3.4.x.
> I don't think that anyone will fix anymore bugs in KDE 3.4.x.
Of course, there aren't anymore left =)
Unfortunately, this is not how KDE works. If you use OSS, you *are* an unpaid software tester. While you should resent this with commercial software, you should simply accept that this is the way it works with OSS.
Therefore, you should upgrade to 3.4.3 since bug fixes for the older branches stopped with the release of a new minor branch. Actually, IMHO, there should only be one final bug fix release for the older minor branch. E.G. now that KDE-3.5.0 has been released, there should be a KDE-3.4.4 release which incorporates the bug fixes as of the date of the 3.5.0 release, but with OSS, that is all the support that can be expected for the old version.
Yes, it is probably true that 3.5.0 will have more bugs than 3.4.3. Which is why 3.4.4 should be released and why those that value stability more than features should upgrade to it while waiting for 3.5.1.
You do make a good point though. We should be careful that stability does not take a back seat to new features. If we are not careful about this, adding new features will introduce new bugs and if new features are added faster than bugs are fixed, the releases might become less stable. Naturally, we should strive to have the new releases always be more stable than the previous ones and it is an important thing to keep in mind.
> If you use OSS, you *are* an unpaid software tester
This is true for every kind of software because you can only test so much before a release. The advantage of OSS is actually that the release phase is open and everybody can help to find bugs before the release. This is not possible with closed-source software.
> Unfortunately, this is not how KDE works. If you use OSS, you *are* an unpaid
> software tester. While you should resent this with commercial software, you
> should simply accept that this is the way it works with OSS.
I have no claims, because I didn't pay anything. As I enjoy reporting bugs and helping to improve software, being an unpaid software tester is also no problem.
With my comment I only wanted address a common problem today. Often before a problem gets fixed new problems are intoduced. If I had paid for a piece of software, I would get pretty angry.
I am grateful, that I have the choice to wait.
> You do make a good point though. We should be careful that stability does
> not take a back seat to new features. If we are not careful about this,
> adding new features will introduce new bugs and if new features are added
> faster than bugs are fixed, the releases might become less stable.
This is a thing which is important for me. The second one is: Keep things small and simple.
I can't count how many friends had their "state-of-the-art" laptops or mobile phones repaired under warranty several times.
As I don't follow that direction, I have less problems.
"I can't count how many times konqueror has crashed when broswing or working locally as a filemanager."
Have you reported all these bugs? Have you followed them all the way through to fixes?
Anyone know is Mandriva is gonna package 3.5 ? (Conectiva used to, and now they merged ... I really hope so)
Thanks in advance. Cheers!
Already in Cooker.
Thanks. Although, Cooker packages many times require updating other packages
to untested versions. It would be nice if they compiled 3.5 for the current
stable Mandriva releases and post it in the net (as Conectiva used to do,
or SUSE, Kubuntu and others do)
Cheers
Allright, I tried at home. A KDE upgrade to cooker would
imply upgrading the X server too ... too much risk. I'm not
doing it.
I guess I will soon be signing as KubuntuUser_exMandriva
;-)
Well, considering that in mdv2006 Xorg is a cvs release, it is probably not that bad to upgrade it.
You may also recompile the src.rpm for your actual configuration.
cooker is not stable, it is an unstable development version, not made for users. In other words, you do not answer the question.
Go to forum.mandrivaclub.com on "General Software", search for Thac&Zé packages (Mandriva Enhanced). I'm using them.
...really fast.
I just upgrade from 3.4.3 to 3.5 on my laptop and most of the big apps load faster. I love it.
If this one day goes into gcc/glibc/ld, it will be even faster:
http://sourceware.org/ml/binutils/2005-11/msg00179.html
Let's pray for the gcc developers to accept this.
This fontconfig optimization sounds very effective as well:
http://mail.gnome.org/archives/performance-list/2005-November/msg00094.html
"Let's pray for the gcc developers to accept this."
It doesn't look as if they're going to, and you could also do it through pre-linking if you wanted to. It would break some stuff though.......
From the luminary that is Lubos Lunak it probably won't make much difference to KDE anyway.
What makes you think that the suggested improvement by Michael Meeks equals to your "pre-linking" approach?
"What makes you think that the suggested improvement by Michael Meeks equals to your "pre-linking" approach?"
Apparently, you can actually achieve exactly the same thing that Michael has achieved for dlopened libraries with a 'hacked' prelink. The only reason why prelink doesn't currently work for dlopen is because it would break some 'rules' about how ELF libs are supposed to work, as does Michael's -Bdirect method according to Lubos and having done a bit of reading around. These rules are not too significant really, but if you ignore them you can actually make a hacked prelink work for dlopen which renders his -Bdirect method a little bit redundant.
It's a pity, because there looks as if there are some gains to be had, even if not a huge amount for KDE over normal prelinking, but because they break some stuff around ELF libs then I guess nothing will get committed - and there seems to be a complete lack of interest. It's a pity Michael's posting got such short shrift. It would have been interesting to see a discussion.
So far, 3.5 seems to be faster and apps seem to load faster. My only disappointment is with Konqueror and the Acid2 Test. It almost successfully passes the test, everything is fine when you run the test, the smiley face shows fine, but then if you scroll, it breaks a tiny bit. I have 3.5 installed on Ubuntu Breezy.
Got pics posted here:
http://www.ianchristie.info/
The first is after scrolling, the second is when you just run the test and don't scroll.
Still excellent work. I think it might have just stollen my desktop from XFCE.