Really? All the hype has suggested that KDE 4 is less demanding of hardware.

Can the effects be dialed down so that KDE 4 runs smoothly on old hardware? I'm very happy with the performance of KDE 3.5 on my Pentium III computers.

Regards,

-Drew

KDE4 turns my normally fast and responsive Slackware system running KDE3 (P4, GeForce 6600GT) into a sluggish vista like system...

I think its just that: hype. Most of the apps are still buggy. Basically KDE4 turns your system into a slow broken one. I wonder if gnome is releasing a new version soon...

I have to say that KDE4 runs pretty well on Kubuntu (Yes, better than on Slack current), but still with lots of little annoying bugs/ programs with limited functionality.

Aha, so the plot thickens...

I also just now remembered that I ran my first test with the 2.6.27.7 kernel and not the 2.6.29.2 kernel that is packaged with Current. Hopefully I'll find time to play more next weekend.

Runs on my PII 450, 256MB ram, with a Trident 4MB video card. Slow, but so is KDE 3. Everything that barely ran KDE 3, will still barely run KDE 4.

I don't believe many have issues with the resources, as KDE 4 is actually lighter and more responsive (IME) than KDE 3. It's that they are used to, like, enjoy .... KDE 3, and are dependent on a qt-3 application.

Even though you can run qt-3 applications with KDE 4, much in the way you can run qt-4 applications with all Slackware versions


Here's some info on building KDE3 that will help with Slackware-next.
http://www.linuxfromscratch.org/blfs...ebindings.html

Today I ran another pass at using KDE 3.5.10 with Current.

Regarding the error I received about the Media Notifier not running and that I could not manually start that KDE service, that was a straightforward fix. I had inadvertently removed the dbus-qca package, which is listed in CHANGES_AND_HINTS.TXT. Of course, that package is needed to support 3.5.10.

I don't how to test KDE 3.5.10 versus Python 2.6.x, as reported previously by disturbed1. I'll try to test if anybody offers some examples.

Otherwise, seems that KDE 3.5.10 works just fine with Current, the 2.6.29.2 kernel, and the proprietary Nvidia drivers 180.29.

Are you having any problems with suspend/hibernate with the Nvidia drivers?

I don't use suspend/hibernate. Some time ago I wrote a simple script to test that feature. I'll try to test again and provide a report.

To see if things will still work, try something that uses python. I believe Amarok uses some of the python bindings. Not sure, but I know there is a python-dbus binding that KDE uses. Perhaps it is used with mounting external drives?

I know the following is for KDE 4- the list might help you see what issues there might be.
This will interesting if everything works! Usually when you take a binary compiled against python # it does not work with python >#.

Might want to check some third party KDE 3.x apps as well.

Today I tried testing. I never use suspend/hibernate and I won't pretend to know much about the topic. I can't get suspend-to-ram to work properly in 12.2 or Current. My box would suspend but restoring always presented a blank screen. I sometimes could toggle to an alternate console, I sometimes could press Ctrl-Alt-Backspace to kill X, but I never saw my KDE screen restore. I toggled to the generic nv driver and saw the same results. I tried suspending without X and could not restore my screen then either. I probably am not configuring things correctly. I verified suspend is enabled in my kernel config. I think the last I tried to test suspend-to-ram was with 12.1. I do remember from then seeing the X screen restore.

I tested Amarok and visualizations. I play only basic playlists from ripped CDs and DVDs. Therefore I can't say I tested thoroughly. Regardless, I played songs just fine.

I tested Kaffeine (ATSC TV, DVD ISO images), Patience, Shisen-Sho, Gwenview, KuickShow, KView, KSnapshot, Konqueror (both file and web browsing), KMail, Akregator, KAlarm, KNemo, Kate. I ran Konqueror, Kate, and Kompare with the kdesu command and the apps ran fine. Hardly exhaustive testing, but looks promising compared to early concerns.

I'll test further if anybody can present some specific tests.

I've been sporadically testing 3.5.10 with Current. Thus far, the things I do with 3.5.10 are working fine. With that in mind, here is how I update my testing partitions to Current without killing 3.5.10.

1. The UPGRADE.TXT file has not yet been revised, although that likely will change before official release. The initial install order needs to be different. The new xz and pkgtools packages need to be installed before proceeding further. Install and update those two packages before proceeding with the usual instructions.

2.Do not install any of the following Current packages:

l/qca*
l/qt*
/kde/*
extra/kde3-compat/*

3. Do not remove the following 12.x packages:

l/arts
l/dbus-qt3
l/qca*
l/qt-3.3
/kde/*

4. Do know that Ark in 3.5.10 does not support the newer package formats. I posted a forum question asking for some help in that direction.

5. I won't claim my testing is exhaustive because I don't know the various ways KDE depends upon external packages. Therefore caveat emptor --- you might find something broken that I have not.

6. The only other significant issue I have noticed is not KDE related --- the newer 2.6.29.x kernel locks-up my on-board NIC when rebooting.

I hope this helps those who want to remain with 3.5.10.

I wonder how feasible it would be to have both KDE 3 and 4 installed on the same machine. That way different users on the same machine can have a choice between the two. Would there still be conflicts if using the stock kde 4 with a custom compiled kde 3 placed under /opt? I imagine there would certaintly need to be some dirty slack hacking to get it to work properly.

I don't think that would be feasable due to the massive library changes that would be required and the extra parameters to be passed to every program in order to make them work with the corresponding KDE version.

I'm not skilled or qualified to rip C++ code. I can write, however. For those interested in continuing to use 3.5.10, I am prepared to consolidate any useful information into a how-to posted at my web site. I also can test and build packages.

To continue the conversation, seems there are three Slackware options:

1. Continue using 12.2.
2. Partially update to 13.0.
3. Use 12.2 and the 12.2 build scripts to selectively update certain packages (an unofficial Slackware 12.3?).

As far as I can tell, the only significant usability obstacle with option 1 is no support for the new package format compression schemes. I have installed the new 13.0 xz package into 12.2 and built the same package within 12.2. Both options worked fine for me. Yet as this discussion is about KDE 3.5.10 solutions, the primary problem is the lack of support for the new formats in Ark.

Robbie W. obliged 3.5.10 users with an (untested) patch to Ark, but as of yet I have been unsuccessful at patching Ark.

Based upon two KDE bug reports, here and here, there might be other areas where the new lzma/xz formats are unsupported in 3.5.10, such as with kdelibs and kdebase. Perhaps that is why the Ark patch did not succeed. I don't know.

Although unlikely, there is a possibility that there will be a 3.5.11 release. In that spirit perhaps a bug report about Ark might help. I'm not optimistic, however, because browsing the KDE bug reports indicate the KDE developers refuse to work on 3.5.x. Regardless, please post links if anybody knows where to find some of these alleged 3.5.x patches. I will try to run and test the patches with the 12.2 build scripts. Some of the bleeding edge distros that supported both versions of KDE might have some patches.

Regarding option 2, I have updated to 13.0 without updating to 4.x. I described my basic approach a few posts previous. However, running 12.2 without xz/lzma support in Ark is nowhere near as frustrating as not having that support with 13.0. Choosing to partially update 13.0 and keeping 3.5.10 basically means wanting that support in Ark.

The alternative is option 3, but that is a lot of work and beyond the skills or time constraints of many people.

There are concerns that certain KDE apps dependent upon Python will break with the newer 2.6 version. I haven't run into any such issues but I don't know where all of those dependencies lie.

Feel free to jump in if you are interested in helping.

Woodsman,

I think we should just try to build 3.5 on current (and -64) and see what happens. If it works, we could rather easily provide slackbuilds and eveything would be fine. This way we could have 3.5 on 13.0 (if we have the breath )

What do you think? Maybe I'll try building qt this weekend, if I find some time. If that works, the rest should doable (and it should work).

Is rebuilding necessary? I don't know. I do know that with my testing partitions I updated all packages from 13.0 except those listed previously related to KDE4 and QT4. I ran the system just fine without rebuilding the 3.5 packages. Perhaps rebuilding is prudent, I don't know. I'm only saying that I did not need to in my basic testing.

For 64-bit, well, yup, rebuilding would be necessary.