Directly to the beginning: This is my opinion and my thoughts - I wrote this with the hope that a (some) developer(s) read this and/or some(one) of the release team.

I know that KDE 4.5 is unstable and unsupported - however, I was curious and wanted to have a look at it.

KDE 4.5 runs here since the beta phase - and think that there is something definitely wrong with releasing.

This shouldn't be considered as a rant - I really appreciate the work the KDE dev's are doing, the free time they spent and especially the near to the community! I like KDE - this is just a post to give a feedback what I think should be done definitely better.

Before I installed KDE 4.5, I needed to wait for Gentoo's KDE unstable repository (really a big thanks to them too ) - I read a post entry of ArchLinux Forum where someone of the KDE packaging team stated they would not release 4.5 Beta 1 due to the first Beta being always faulty... I didn't knew that this prognose would be right...

Well 4.5 Beta 1 landed in the repository, let's torture the system

KDE 4.5 beta 1 started good - everything seemed to work... for the first 2 minutes, then I found the right click bug. Hmmpf. Not good.... Took a few days, updated packages were in, nasty bug squashed.

User happy? No... KDE 4.5 beta 2 is now there.
Another problem - kwin (or) plasma gone mad. As I'm closely following planet KDE and other "information sources" I quickly found a link to ChaniBlog and the related solution.

This was the time I got disappointed... I don't think something like that should happen in a second beta - well. Okay...

But what I found more disappointing is the thing that you'll seem to be too rigid with the releases. In my opinion, it would be best to release KDE 4.5 a month later and to polish 4.5 furthermore.

It's not only about KDE PIM packages in 4.5.1... They could land in 4.5.2 for more testing (yes I think that it's better to give the people more time) - other projects seem to be not really in a good shape too.

Kopete for example is for me unusable - I would have filed a bugreport, however there are too many bugreports to check against (it are mostly memory leaks and sluggishness which annoys me) and there are even open patches on the mailing list / reviewboard...

I'll understand and like the way KDE improved - bit by bit, step by step.

However, you've written by yourself in the 4.5 beta 1 announce:

A special focus of this release cycle is the stability of the software delivered with KDE SC 4.5. While there are many exciting new features, developers have spent considerable amounts of time finishing off features and polishing those that haven't come to full bloom yet

http://www.kde.org/announcements/announce-4.5-beta1.php

Two (severe in my opinion) bugs in 2 beta's, a still unusable kopete (don't think I'm the only one who is complaining - I think I even heard this from developers of KDE) and a "KDE PIM" coming later (it seems to work fine, however, it's a major change!) doesn't sound like stable...

So please - couldn't you overthink your release schedule? To fulfill the promise and make a lot of users (and I think business people in regards to KDE 4.5.1 PIM) happy?

Thanks for reading!

- KDE User since 5 years.

I must say my opinion that I do not like when the KDE SC releases are scheduled to exact 6 months cycles with 4-5 bug fixes scheduled on every month.

Some times I think that KDE is doing too quick work now. The KDE SC is started to being more cluttered by features what are very much needed but the UI is not being tough trough.

Like the systemsettings, it was terrible in KDE SC 4.0 -> 4.4. Now in KDE SC 4.5 they really managed to get it in the shape where we do not have "basic" and "advanced" tabs and everything was in one view with much better logical order (like the application appearance and workspace appearance separated wisely with the win decorations and so on).

Sometimes there really would be need that some versions release could be pushed one month. Especially that the freeze could be delayed 1-2 weeks if needed. Because many (most?) KDE devs are volunteers, they have day job and social life what is the thing what is fighting against the time what is spend to KDE SC. The Open Source idea is "release early, release often" in the development and in the stable releases as well. Because every user is as well developer. Because every user finds bugs, they get new ideas and needs new features. Usual problem is just to get such information easily from normal user to developers itself.

That is one reason why we have brainstroming sub-forum in KDE forums. But the bug/wish filling is too difficult for normal user. It should happend from KDE (application) menu HELP -> Bug way. But instead loading the BKO (bugs.kde.org) and pre-filling the website with some information. It should be own separated application, with security question so spambots would not misuse it. I believe that would be the thing what would give more bug reports and wishes for developers and allow the more easily to actually manage them somepoint.

There are many users who want to try the newest KDE SC version. But I bet only small part of those actually fills bug reports. Especially when they use Konqueror because even the forums.kde.org, like BKO are terrible with Konqueror. What is littlebit ironic because Konqueror is official web browser in KDE SC and KDE's own sites does not work well with it! It is like the BKO and forums.kde.org are designed only for Firefox and other browsers does not matter!

Fri13 wrote:use Konqueror because even the forums.kde.org, like BKO are terrible with Konqueror.

Exactly what issues are you facing? I can use FKO just fine, and I use Konqueror full time (Firefox is too slow, Chrome doesn't integrate, rekonq does not respect my font settings).

einar wrote:

Fri13 wrote:use Konqueror because even the forums.kde.org, like BKO are terrible with Konqueror.

Exactly what issues are you facing? I can use FKO just fine, and I use Konqueror full time (Firefox is too slow, Chrome doesn't integrate, rekonq does not respect my font settings).

The javascript side does not work well at all. I need to use HTML version to get site working someway.

Example, if I try to return back to list after I opened a topic, it goes all the way back to start. Not to the page where I was. So I need to remember the site number where I was, then open it and then search the topic what I clicked first. And with Konqueror the multiple tabs are almost useless in FKO. Like if you open multiple topics to tabs.

einar wrote:

Fri13 wrote:use Konqueror because even the forums.kde.org, like BKO are terrible with Konqueror.

Exactly what issues are you facing? I can use FKO just fine, and I use Konqueror full time (Firefox is too slow, Chrome doesn't integrate, rekonq does not respect my font settings).

I also use Koqnueror, and it mostly works fine; and when it doesn't I just change to WebKit...
But there are few problems I hope get fixed:
-I have to reapply the spellchecker always when I start Konqueror, it somehow doesn't remembers it. And this worked previously, I have no idea why it stopped...
-KDE Furms site is "broken"; See printscreen:

@OP

The problem with activities was that we needed a /live/ conversion from the old system to the new one, and Beta 1 didn't get the updating mechanism in time. And IIRC, Beta 2 had a small issue with creating empty activities. (note that this is something completely new in KDE SC 4.5 - it is not a previously existing feature - so it wasn't in the "we already have that, lets make it more stable" process of 4.5)

It is rather unfortunate, but Betas are meant to be buggy, otherwise, they would be called /final/ The whole point of a beta is to be used for bug-detection.

--

Concerning the 6-month release schedule, I have to agree, things were more pleasant for us - 7 months of development, and 2 of polishing...

But, that's the way things are now, so, no point in complaining

The good thing (which will have its downsides as well) is that we are switching to GIT as a revision system which will allow us to develop outside of the main source tree, which would ideally mean that the trunk (current development version) will always be rather stable.

ivan wrote:@OP

Concerning the 6-month release schedule, I have to agree, things were more pleasant for us - 7 months of development, and 2 of polishing...

But, that's the way things are now, so, no point in complaining

I can think as well that 7+2 was ideal but when now thinking the current situation = we have more KDE SC users than what we had about 3-5 years ago. But what we really need, is distributors to always make easy way to get development versions to users who are willing to test it. Even better if it would be packaged such way it does not override the stable KDE SC. That way I think we could get more normal testers if the KDE SC beta installation would be just few clicks away (more like openSUSE one-lick-install) but just available from package management without need to add repositories etc.

But it would need instructions how to make new user and get the KDE SC beta -session open instead the stable version. And then I believe we should get the bug reporting so easy that it is own application client (with captah) without the need to use web browser for it. We get the reporting wizerd from help menu but why not have a application for such thing what would do same thing? (search same kind reports, give input boxes for reporting etc). If the bug reporting would be so easy, I bet we could get much more beta testers = more bugs closed in next versions and more stable next releases!

The good thing (which will have its downsides as well) is that we are switching to GIT as a revision system which will allow us to develop outside of the main source tree, which would ideally mean that the trunk (current development version) will always be rather stable.

That was very nice change. Especially for developers but I think that downstream will love that as well the test users who can snap some parts in the test.

I'm a relatively new Linux user (switched over in early 2009), so I wasn't around before the 6 month release cycle was started, but I currently like the rate at which KDE SC is released. The way it seems to me, a 6 month release cycle gets me new features faster without much cost to stability. Some things that were buggy in 4.2 were still buggy in 4.3, and I doubt having an extra month to work on it during the 4.2 cycle would have made much of a difference, if the 6 months before 4.3 didn't seem to be enough time, either. (Note: I'm not referring to any piece of buggy software in particular, but I'm sure most of you can think of an application where this is true)

What seems to be the problem to me is just an obsession with new features over general stability, but this isn't across the board. For the most part, KDE is a smooth ride for me, now. However, Knetworkmanager and whichever process controls the time it takes for a computer to wake up from suspend could use some polish. They seriously lag behind their gtk counterparts in terms of speed and reliability.

It would be cool (maybe GIT will make this possible) if we had small-feature-6-month-release and large-feature-12-months-release.

An example of a big feature are the new activities. Currently, thanks to the short development cycle, we only managed to make them in Plasma (so, not much news for the users here) and KWin. The full implementation will require *much* more - patching almost every KDE SC application that wants to harness the power

ivan wrote:An example of a big feature are the new activities. Currently, thanks to the short development cycle, we only managed to make them in Plasma (so, not much news for the users here) and KWin. The full implementation will require *much* more - patching almost every KDE SC application that wants to harness the power

That is something what I really waited for 4.6. The activities are just so great idea but when we get great big features dropped one by one and always half-baked, some might get feeling that KDE SC is not ever ready for production!

And that just is gasoline for the fire with some people who then suggest to always jump over every other release and never use newest release but wait that x.x.3 is out. That is some peoples suggestion for normal users! And some persons are even more suggesting to wait that KDE SC 5 comes out.

But does KDE SC 4.5 feel so bad? I dont think so. It just needs polishing what actually should be done right away. Like systray icons for all applications to be ready. So we get good looking black/white icons only, not them and now normal colored ones. So KDE application developers should start making them fast. Maybe on RC versions that is in better state... The small things are those what leaves tha bad taste to mouth. In that way missing the full spectrum of the activities or nepomuk (still almost useless state) it is not so bad. If they do not work correctly, they should be disabled by default so normal user can not even notice them at all. Like that means removing the search bar from Dolphin etc.

Small features makes users happy as well, not just big ones. Like the feature to allow move window from any empty space of the window.

With KDE SC 4.5 it seems it is more like big polishing upgrade than bringing new features. Even that suchs has been added.

But when compared to 4.4, the 4.5 feels better, altough you can not pinpoint the the big changes. It is more like 4.2 was for KDE SC 4.x series. So I am waiting the 4.6 release because how many great things I heard were dropped off because developers did not make the deadline. Only few weeks could give enough time.

With KDE SC 4.5 I am happy of the few features.

1. Blur plugin works again. The plasma started to look good when you get blurred background. (but it does not work perfectly. Window what is transparent does not blur the background. Like konsole or when window is set to be 50% transparent when not active)

2. The notification system works better way now. Altough it needs still polishing (and personally I think it should be still redesigned).

3. Systray icons makes the workspace more clean. No more need to use custom maded themes but the default set looks good.

4. The system settings finally got simple. The advanced tab was removed and it is more logical now. Like separated the workspace and application themeing settings.

And those are just basicly from KDE Workspace improvements.
More improvements are in KDE applications what is very nice thing.
What I was waiting from KDE SC 4.5, so now waiting from 4.6 are:

1. Acticities to work such way that I can have different panel configurations on every one. LIke one activity to have 2 and oher 3 panels. Third to have no panels at all and fourth have autohided panels. Just like different wallpapers, just having different panels.

2. Possibility to have KickOff menu button like Lancelot menu button when placed to desktop as widget. Now the KickOff is open menu what takes lots of space. Lancelot is great in that way it stays as icon what can be used as it would be in panel!

3. Lots of new widgets. Aaron Seigon has kept many widget developing -sessions with javascript etc. And I hope the people would start having ready their ideas and get them ready. If we would get 20+ new widgets, people would really love the KDE workspace more!

I am waiting 4.5.x releases to make KDE SC even better and bring new fans for it. But same time I am hoping KDE SC developers would discuss in 2010 Akademy how to maintain the similar UI between applications. Because we are starting to have the Google Chrome effect now where applications like ReKonq are trying to force users to one UI way. KOffice with the Kexi, Amarok.. There seems to be movement to want to get rid off the menubar with multiple different ways. Altough we have always had creat Ctrl+M but KDE SC main developers has not (yet) wanted to add it to kdelibs so it would be used in every application. Many applications would really need it, like KMail and Amarok. The Ctrl+M is not problem. Just add the shortcut feature and make it by global settings disabled. Or set the shortcut to something like Ctrl+Alt+M. Focus to default toolbars and we would get even better KDE SC! (my opinion!)

Well, the users can't really complain about the state of the activities in 4.5 - it is not like those existed and we removed some features. It is just about adding one thing at a time.

As for the items for 4.6 you mentioned, where did you read that those will be implemented at all? (I don't know whether anyone even plans on doing different panel settings for different activities.)

Fri13 wrote:There seems to be movement to want to get rid off the menubar with multiple different ways. Altough we have always had creat Ctrl+M but KDE SC main developers has not (yet) wanted to add it to kdelibs so it would be used in every application. Many applications would really need it, like KMail and Amarok. The Ctrl+M is not problem. Just add the shortcut feature and make it by global settings disabled. Or set the shortcut to something like Ctrl+Alt+M.

Please, someone, make this happen!

Well I must say that I am pleasantly surprised at the return of the places plugin for konqueror (okay it used to be called devices).

Also happy that no longer entire directories popup when accidentally hovering a directory icon on the desktop, still a big icon popup which cannot be disabled though

Though kde has gotten another annoyance too: the select effect in Lancelot, why can't kde just do a few subtle effects? This is just way to "busy" and overwhelming (edit: this might actually be a plasma theme bug)

Still not done: device icons on desktop (instead the mount plasmoid); still in "i" in the systray that cannot be hidden

> still in "i" in the systray that cannot be hidden

It can, unlock the desktop, right-click the "i" and choose remove.

> the select effect in Lancelot

That effect is introduced for greater visual integration with the rest of Plasma - all views have that sliding-background.

If you want to disable it, open lancelotrc and in the [Main] section add the following line:
itemViewBackgroundAnimation=false

ivan wrote:> still in "i" in the systray that cannot be hidden

It can, unlock the desktop, right-click the "i" and choose remove.

But then you don't get notifications or at least no way to view older notifications

> the select effect in Lancelot

That effect is introduced for greater visual integration with the rest of Plasma - all views have that sliding-background.

If you want to disable it, open lancelotrc and in the [Main] section add the following line:
itemViewBackgroundAnimation=false

Sorry I think this is a bug in the eleonora theme, or at least a very ugly effect with 2 highlights moving