AUG
26
2008

KDE 3.5.10 Updates Kicker and KPDF

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.

Comments

I love 3.5. Nice to see it's still getting updated. :)


By tsb at Tue, 2008/08/26 - 5:00am

Didn't we promise we would? :D


By Jos Poortvliet at Tue, 2008/08/26 - 5:00am

Yeah, well .. Canonical said you wouldn't. Someone was wrong.


By Tom at Tue, 2008/08/26 - 5:00am

I don't remember saying any such thing.


By Jonathan Riddell at Tue, 2008/08/26 - 5:00am

Hello,

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?

Yours,
Kay


By Debian User at Tue, 2008/08/26 - 5:00am

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.


By David Johnson at Tue, 2008/08/26 - 5:00am

This may seem strange, but it is open source, and people work on what they want to work on.


By Troy Unrau at Tue, 2008/08/26 - 5:00am

OR what they're paid to work on.
FOSS supports and encompasses pretty much all development models out there.


By ethana2 at Tue, 2008/08/26 - 5:00am

> 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.


By Carlo at Fri, 2008/08/29 - 5:00am

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.


By David Johnson at Wed, 2008/08/27 - 5:00am

Hello,

see David, that's not attitude, that is free will, and circumstances.

Like your favorite distribution doesn't offer from 3.5 anything else but kdelibs anymore. And if you were to compile it yourself, you probably would find out that:

a) The library versions you can have on your distribution (easily) are too new and have had interface changes. Tough game.

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

b) The C++ compiler of your distribution will no longer accept the invalid C++ that in one form or the other is in KDE 3 right now.

I recall trying to compile a g++ 3.2 on a system that had 4.x series only. I had to go backward in steps to get the gcc compile the gcc.

I am almost 100% sure, KDE 2.x won't be accepted by latest gcc release. Prove me wrong.

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 :-)

Yours,
Kay


By Debian User at Tue, 2008/08/26 - 5:00am

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.


By ad at Wed, 2008/08/27 - 5:00am

Opss, of course that should be 6 minor releases for KDE 3 (not 11) Still twice as much as those for KDE 2.

And then 10 bugfix releases for KDE 3.5 release versus only 2 bugfix releases for KDE 2.2.

Point remains. 3.5 is way more mature and stable.


By ad at Wed, 2008/08/27 - 5:00am

Hello ad,

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 -> ?

Yours,
Kay


By Debian User at Fri, 2008/08/29 - 5:00am

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.


By Tom at Tue, 2008/08/26 - 5:00am

> At least that is what was reported on the interwebs.

Well, it must be true then. ;)


By mart at Tue, 2008/08/26 - 5:00am

"I don't remember saying any such thing."

No, but Canonical certainly did in the discussion on what to do for a LTS release. The premise was that KDE 3.x would not be updated during the lifetime of KDE 4.


By segedunum at Wed, 2008/08/27 - 5:00am

I wouldn't worry what they say.

Because 3.5 is still a major part of OpenSUSE, you can expect there to be updates for a few years, at least from the OpenSUSE team.


By anon at Tue, 2008/08/26 - 5:00am

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.


By T. J. Brumfield at Wed, 2008/08/27 - 5:00am

3.5 will still be mantained, due to it being part of SUSE, there is no reason to keep it in OpenSUSE 11.1


By anon at Wed, 2008/08/27 - 5:00am

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.


By bico at Wed, 2008/08/27 - 5:00am

"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.


By Stefan Majewsky at Thu, 2008/08/28 - 5:00am

openSUSE 11.1 will have KDE 3.5.10
http://en.opensuse.org/Roadmap/11.1


By ad at Wed, 2008/08/27 - 5:00am

Lets hope it doesn't crash as much now.


By blah at Tue, 2008/08/26 - 5:00am

... then please stop compiling on your own if you have no clue and start using a proper distribution ...


By MyLaidy at Tue, 2008/08/26 - 5:00am

Don't remember it ever crashing on me on 3.5.9 (openSUSE 10).


By ad at Tue, 2008/08/26 - 5:00am

I've had kicker crashes in Gentoo, Sabayon, Kubuntu, openSUSE, Arch, etc.

I just restart kicker and move on without thinking too much about it.


By T. J. Brumfield at Wed, 2008/08/27 - 5:00am

I don't have any crashes of Kicker in Gentoo for ages.


By KejPi at Wed, 2008/08/27 - 5:00am

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.

The bug report for this crash is on http://bugs.kde.org/show_bug.cgi?id=133386

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?


By Naveen at Wed, 2008/08/27 - 5:00am

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).


By Benoît Minisini at Fri, 2008/08/29 - 5:00am

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.


By Naveen at Wed, 2008/09/03 - 5:00am

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.


By Artem S. Tashkinov at Tue, 2008/08/26 - 5:00am

"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."

Which aspect of KDE4.1 do you find consumes the most memory?


By anon at Tue, 2008/08/26 - 5:00am

Double buffered Qt4. It's pretty well known, and nothing can really be done about it. Such is the price of advancements in the toolkit.


By Leo S at Tue, 2008/08/26 - 5:00am

Hello!

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

If what you say is true for Qt, I don't think it's a universal truth that double buffering alone should increase the memory usage noteworthy.

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.

So I guess, something else would need to be blamed. My guess would be lack of optimization.

Yours,
Kay


By Debian User at Tue, 2008/08/26 - 5:00am

"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."

None of the benchmarks I saw counted x-server usage.


By anon at Tue, 2008/08/26 - 5:00am

Hello,

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.

Yours,
Kay


By Debian User at Wed, 2008/08/27 - 5:00am

There is more in the world than Qt *Desktop* Edition.


By Andras Mantia at Wed, 2008/08/27 - 5:00am

"Since most apps basically have their whole windows covered in widgets, this is a large amount of memory consumed."

Qt 4.4 has alien widgets: Only the windows are real X clients, the other widgets are merely data structures who paint on the window's buffer.


By Stefan Majewsky at Thu, 2008/08/28 - 5:00am

You did render the argumentation from Anon invalid.


By rogue at Thu, 2008/08/28 - 5:00am

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.


By Artem S. Tashkinov at Tue, 2008/08/26 - 5:00am

I asked "which aspect"; I didn't say I didn't believe you.

Something in KDE4 is apparently taking more memory than in KDE3 - the question is, what, and why, and what can be done to fix it?


By anon at Tue, 2008/08/26 - 5:00am

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.


By Morty at Tue, 2008/08/26 - 5:00am

++

LiveCD's are not a good measure of performance on low-memory systems because loading the LiveCD into a ram disk kills almost all your memory.


By T. J. Brumfield at Wed, 2008/08/27 - 5:00am

> The rest of the 256M are used for buffer and cache.

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.


By Carlo at Fri, 2008/08/29 - 5:00am

`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.


By Artem S. Tashkinov at Wed, 2008/08/27 - 5:00am

> 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.

It's not a fact. It is just based on your own experience.


By Juan Miguel at Wed, 2008/08/27 - 5:00am

And others, me included :)


By Iuri Fiedoruk at Wed, 2008/08/27 - 5:00am

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.)


By Adrian Baugh at Thu, 2008/08/28 - 5:00am

Using top for measuring memory isn't exactly a smart idea:

http://www.kdedevelopers.org/node/1445
http://www.kdedevelopers.org/node/1567

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.


By Pumpkin at Wed, 2008/08/27 - 5:00am

Pages