The KDE community has finalised another update to the 3.5 series. While not a very exciting release, 3.5.10 brings numerous bugfixes and translation updates to those who choose to stay with KDE 3.5. The fixes are thinly spread across KPDF with a number of crash fixes, KGPG and probably most interesting various fixes in Kicker, KDE 3's panel.

Improved visibility on transparent backgrounds

Themed arrow buttons in applets that were missing them

Layout and antialiasing fixes in various applets

Note, as with every release, the changelog is not complete as our developers often forget to document their work. For users of KDE 3.5.9 it should be low-risk to upgrade to KDE 3.5.10 since the rules of what is to enter the KDE 3.5 branch are pretty strict at that point, it is in maintenance only mode.

I think Kubuntu 8.04 is not LTS because of the assumption that KDE 3.5 will not be maintained until 2011.

I wouldn't bet my first born on security fixes for KDE 3.5 in 2010. Could very well be that its up to distributors themselves to do that.

And that could well pose a problem to anybody without deep pockets. They would have to do it for free, as opposed to the RHEL/SLES people. As Ubuntu must remain free of charge (they promised to never charge for Ubuntu), it's a tough demand to do what the community may not want to do.

In 2010 we are talking about 4-5 more releases of KDE 4, like KDE 4.6, only really old fashioned people will even consider KDE 3.5 at that time. Who is going to spend his free time to support KDE 3.5 then?

2010 is only two years off. I know that seems like forever in internet years, but it really isn't. I don't understand the attitude of some developers that they won't support security fixes for a mere two years.

> FOSS supports and encompasses pretty much all development models out there.

That's quite a bold statement and the not uncommon attitude Troy mentioned contradicts it. And no, I don't think there're enough developers paid for pure maintenance, to compensate for the low interest in long term maintenance of unpaid open source developers.

Yes of course. There's no guarantee that developers will maintain their software. That doesn't make the attitude a good one, however. It's not fun and it's not sexy, but maintenance *is* a part of the software lifecycle.

c) You don't even know a KDE 3.x user. These guys certainly don't install new distributions (which won't come with it anymore).

And if they use free distributions, it must be Debian and they will do it themselves anyway for the Stable release, but everybody will be using Testing, which will be on KDE 4 already. All others are going to be unsupported by the time, so would users actually see your fixes?

If they are commercial users, it's not supported by KDE, so you would barely notice and why should you care (they paid other guys already to do it).

d) By then KDE 4 has had 5-6 releases by the time. It is so far better than what KDE 3.5 achieved, you can't convince yourself to invest time into it. That's like sending your ex-wife flowers although you found the perfect replacement - you just don't do it.

Overall, how I see it: Right now, KDE is maintaining 3.5 out of a self-declared unability to satisfy (all of) its users with the new releases. And out of the self-obligation to not let users in the dark.

But as KDE 4 progresses and all distributions do releases based on it, that points become moot and 3.5 will no longer be supported by KDE.

My guess would be that with 4.3 at latest, we could have the point where KDE community decides to discontinue its support. But be 100% assured, only when these criterias are met, will it happen. And as we know, they will be met, sooner or later :-)

Kay, I agree you have a point but if you start exaggerating you'll have a harder time convincing people.

"Try to compile KDE 2.x once in a while on a brand new distribution, to get an idea."

The last KDE 3.0 was released over 6 years ago! Also there wasn't much of a reason to stick with KDE 2.2, it was not that mature anyway (only 3 minor releases) and the transition to KDE 3 was pretty smooth and far from radical, more of an evolution.

Now it's a whole different game. We're talking about compiling KDE 3.5 in two years time (not six). KDE 3.5 is incredibly stable and mature (11 minor releases!) and KDE 4 is a much more radical change, so distros will have much more interest in maintaining 3.5 then they had in 2.2.

I didn't intend to exagerate, it's just that people seem to think that supporting KDE 3.5 will be easy once the developer distributions have jumped ship to KDE 4.x as default.

The effects are the same as I mentioned though. KDE 2 used Qt 2, other library versions under rapid development, required older compilers, the same problems already applied at the time 3.1 was released. And they will apply each time that KDE breaks ABI, be it 1.x -> 2.x -> 3.x -> 4.x -> ?

OK, I didn't say you did .. but the rational behind not supporting KDE3 for 3 years was that upstream would drop support for KDE3 and not update it anymore. At least that is what was reported on the interwebs.

I've had openSUSE devs tell me directly that they expect KDE 3 to be dropped in the upcoming 11.1 or 11.2. Fedora already dropped it, and I heard Kubuntu is considering it as well. Between those three, that would largely kill off a good chunk of the KDE 3 user base. I'm not sure what Mandriva's plans are.

Some people need the functionality of 3.5 more than the bling of 4.x and others just don't want to get used to a new interface, apps (like dolphin), new configurations, etc. Unless KDE 4 will offer some new & useful functionality that people can't live without, there will still be reasons to update KDE 3 and to include it in distros.

"Unless KDE 4 will offer some new & useful functionality that people can't live without"

Doesn't it offer such already? Only compositing is worth the switch (not in the sense of bling, but of improved task management); or look at the new Gwenview, the possibilities with Plasma (even without panel auto-hide), and the upcoming Amarok.

The new kicker crashed for me today on Kubuntu 8.04 when trying to launch pidgin.

Kicker crash is an infrequent problem and it is not much of a issue as kicker restarts automatically and tray icons for KDE apps recover without any problems. But none-KDE apps like pidgin and azureus get a new window on the desktop and a corresponding taskbar entry for their tray icon.

I ended up triggering the bug as i was trying to get kicker to display tray icons in two rows like in 3.5.9. Pidgin with 3.5.9 has a known issue which causes a single row display, removing the 48x48 pidgin tray icons and creating a link to the 32x32 icons used to fix this.

I'm not able to get the new system tray to display two rows even with only KMix, Klipper, KNetwork Manager and KBluetooth. Is anyone else facing the same problem after upgrading? Can anyone help?

The system tray layout algorithm was fixed in KDE 3.5.10, but not entirely. There were bad patches on the bug, and I didn't remove all the patches while removing the bug. Now I think I have finally fixed everything, but you will get it only in a next release.

As for pidgin: pidgin does not specify any preferred size into its icon (I don't know why, as this is done automatically in GTK+). So you get an arbitrary size.

I committed a patch recently to constraint icons to not be bigger than the default system tray icon size. Fortunately, pidgin scales its icon according to its tray window size.

As for the crash in kicker, you should give more details about the configuration (see the bug entry in bugs.kde.org).

Thanks for the reply, i have updated the bug entry with additional details, however I'm not able to reproduce or get any additional details about the crash right now. I will update the bug report when i get more information.

for people who cannot afford upgrading their computers since KDE 3.5.x runs just fine when you have 256MB of RAM (and there are plenty of such PCs).

KDE 4.1.0 is all shiny and sexy but I cannot imagine running it smoothly on a PC with less than 768MB of RAM.

So, thank you very much, KDE team, for your continued support of KDE 3.5.x series.

I only wonder since release notes lack any sings of EOL, does that mean that KDE 3.5.11 will follow? When KDE 4.0 was out I predicted KDE 3.5.10 would be released and it happened so, but now KDE 4.x is maturing and I feel like it's time to say good bye to our old friend who served us well.

Qt 3.x is no longer maintained and I'd like hear the answer from Aaron Seigo or any other major KDE developer who is responsible for releases.

"Double buffering is only needed for parts of the screen that are visible and actually change, which is for nearly nothing."

That might be what is *needed*, but it's not how Qt4 operates: every widget in every window, whether it's visible or not, permanently has a double-buffer. Since most apps basically have their whole windows covered in widgets, this is a large amount of memory consumed.

"And for all I remember, is how we were told that Qt4 has actually reduced the memory usage over Qt3. And there were people to benchmark it."

that combined with the blog, how Qt always wants to convert everything to 32 at one point bits, even if the source and dest are both 16 bits, thus painting with low FPS. It makes me wonder why people seriously consider Qt well suited for mobile devices.

But who knows, maybe they can refactor it one day to something sane. The useless conversions will go in 4.5 I read.

And to Nokia it sure is of interest. You know, like how big a phone do you need, 2G RAM? or 256MB, that's cost.

I have already tried a number of Linux LiveCDs with KDE 4.x onboard and running them in a virtual machine with 512MB RAM is a pain. You can do that on your own if you don't trust my words.

(My own PC now contains 4GB of RAM so I don't much care - but) Sometimes I come to people who have quite old PCs and I wanna boot off a Linux LiveCD and KDE 4.x is not an option if your PC doesn't have enough RAM.

Obviously it sounds like your approach with liveCDs have issues, but it's not KDE 4 memory usage. And live CDs have never been a good option when not having enough RAM, or for running on slow machines for that matter.

I'm currently posting this from one of those old PCs you mentioned, using a distribution known to be heavy without any tweaks, currently peaking at about 161M of physical memory used by applications. The rest of the 256M are used for buffer and cache.

The machine is not fast, but that is not caused by the lack of RAM(As long as I keep a reasonable amount of applications open). Easily deducted from the fact that no significant amount of swap is used. The most noticeable thing more RAM would give are faster restart time of applications, but that's only caused bye more RAM available for disk cache. And it does not make much sense to use as a significant measure. Since anything close to realistic usage is about working with the applications, not stopping and starting them.

When not having any/enough memory for buffers and cache the system has to access the disk constantly working becomes a PITA. So, saying it uses only so and so much physical memory is only half of the picture.

Expecting KDE 4 (or any other desktop built for the next five to fifteen years) to run on a 256 MB system limits the development of a service-rich desktop framework to an untolerable degree, imho. On the other hand I don't understand the generally poor approach towards KDE 3.5 maintenance of the KDE developer community. It's a pity. I'm grateful for any guy like Benoit Minisini, who make a difference.

`Top` says that every KDE4 application eats on average 5-10 MB more RAM (looking at the RSS field) than their KDE3 counterpart and plasma is the greatest offender (over 50MB RSS), so definitely there's a room for optimizations.

As for infeasibility of estimating KDE4 RAM usage using LiveCD: I don't run LiveCDs to really account anything - 1) I run them out of necessity 2) I've tested LiveCDs in a virtual machine with ISO image connected as a CD drive - so there's an issue of the increased memory consumption as CD access time doesn't account for anything (ISO image is saved on a HDD).

So, let me reiterate - what I wanted to say is that KDE4 is not very usable when running on PCs with less than 768MB of RAM. It's not a big deal, but a statement of fact.

Runs fine on my laptop, a Thinkpad T42 with 512MB of memory. (And, OT, the integrated ATI card is so much better than the nVidia card in my desktop machine! Though I'm not yet using the new beta nVidia drivers which I hear make things much better.)

And your claims that KDE 4 isn't "usable" on machines that have *roll a dice* MB aren't exactly as representative as you claim them to be:

- I've installed KDE 4 on a Toshiba Satellite 2430 w/ 512 MB of RAM and it runs smoothly.
- If you search the internet you'll see that KDE 4 is reported to run smoothly on an Asus EeePC (which has "just" 512 MB of RAM). I had installed KDE 4 on my Asus Eee myself, so I can confirm this.