This thread is not about the merits of KDE 4.x. That subject has been discussed among Slackers quite enough.

When the moment feels right for me I expect to move to the newer KDE version. For now, however, I want to entertain KDE options when the next Slackware release arrives. Specifically, updating all packages except KDE 4.x and maintaining 3.5.10.

To continue using 3.5.10 with the next official Slackware release, will I or similar users have to rebuild those packages? Or will the 3.5.10 version packaged with 12.2 be usable as is with the next release?

I ask only because I don't what peculiarities exist with compiling KDE.

If I understand correctly, there are some additional packages in the /extra branch that need to be installed, but perhaps there is more required. Perhaps not.

Yes, I could create a virtual machine and test, but asking for preliminary information never hurts.

Thanks again.

The packages in extra do supply some libs for qt 3.x but the path is different. Instead of /usr/lib/qt, qt 3.x has the path of /opt/$. These packages are only there to allow you to run legacy qt 3 applications.

This would cause a problem with just installing the KDE 3 binary packages, since they were built with arts/qt/qca in a different path location. Another thing, a few of the binding libraries have upgraded as well. I don't think it would be possible to simply install the KDE 3.x binary packages.

If I wanted to use KDE 3 on Slackware-next, the first thing I'd try would be to not install qt 4, nor qca. Use the SlackBuilds from 12.2 for arts, qca, qt 3, and KDE. This way your qt path will be correct for KDE. Then if you want support for qt 4 applications, use the 12.2 SlackBuild from slackbuilds.org for qt-4 which puts qt-4 in a path that doesn't interfere with qt-3.

Then, if there's ever a security update to something that links against KDE, you'd have to rebuild KDE again, after each update.

If you haven't built qt nor kde from source before, it takes some time and resources. On a dual-core machine, qt-4 used 2gigs of RAM, and a long time, not exactly sure how long, but I can build Seamonkey at least 4 times in that time frame. KDE takes even longer.

You could use the packages in extra/ to install qt-3, but you'll have to edit the KDE 3 SlackBuilds.
That's the default setting for KDE. If you do not have qt 3 installed in /usr/lib/qt - fail.

You would have to change them to

Woodsman,

I will be very interested to hear what you come up with running KDE 3.5.10 on the next version of Slackware. I'm going to take the plunge and move to KDE 4.2.3 when the next stable version of Slackware is released. My main work station should run KDE 4.2.3 very well. My secondary Slackware box, a Celeron 850 with 768 MB RAM, will be running XFce when Slackware 13 is released. I'm going to keep my wife's Slackware 12.2 station as is (Slackware 12.2 will be supported for several years). Interesting times ahead:-)

Add another vote for staying with KDE 3.5.10, if possible, with the next release of Slackware. Having recently used both 4.2.2, and 3.5.10, I would really prefer to use 3.5.10, until 4.x, and the applications for the same, catch up to 3.5.10, in functionality and "configerability."

That topic has been discussed at length in other threads. Any usage of 3.5.10 with future Slackware releases will be up to users. Hence this thread --- unless Pat decides to throw 3.5.10 packages in the extra branch.

I don't want this thread or topic to become combative. I only want to explore options.

I'll have to run some test passes of updating to Current but excluding the qt, qca, arts, and KDE packages. That would leave all the related 3.5.10 packages intact. Perhaps I'll get lucky and all will be well after that. If not then I'll have to rebuild them under Current and try again.

Well, I'll compile at night while I sleep.

Indeed!

Sounds like a nice project, Woodsman. Assuming you are successful in building unoffical Slackware KDE 3.5 binaries, are you planning on hosting them for the community? I get the impression that there would be decent demand for them, and thus decent bandwidth needed.

Make a "KDE 3.5.10 Slackware" project on SourceForge?

Also if the maintaining of the packages becomes community based it would mean that we could remove the components of KDE that do not work with Slackware like KNetworkmanager. It would be a double edge sword with regards to staying with KDE 3.5.10 and having it be a community based project. We wouldn't get any of the developmental benefits of some programs that have moved to KDE 4.x however we would get the stability and the ability to compile in what we wanted.

It is still a toss up for me. I will probably move to KDE 4.x on my desktop because it has enough power but my laptop will stay at 3.5.10.

iono, just my .01 (the enconomy took my other penny )

I don't know the release schedule for Slackware. Could be many months yet. Therefore that kind of decision remains down the road.

I have no idea whether 3.5.10 will run under the next Slackware release. My guess is probably, but with how much elbow grease is the $64,000 question. Hence this thread. That is a road not traveled by anyone here, at least not yet reported as such. I have a set of testing partitions I use just for this kind of project. Hopefully I eventually will report something in the next few weeks.

Regarding hosting from my web site, I would have to consider the additional financial cost from the increased bandwidth. I would not commit to anything like that today, but if I did I would let everyone here know.

Another element is that, in my opinion based upon my usage of apps, when KDE 4.x is fully functional, then I likely will migrate to 4.x. I imagine many other people will too, which would reduce demand for 3.5.10, and reduce motivation for maintaining packages.

As we discussed in another thread, not all of the third-party KDE apps are yet 4.x compliant, which in the opinions of at least a few people, renders KDE incomplete. When those remaining apps are 4.x compliant, then migrating seems to make sense to me. For me that at least includes K3B, Amarok, Kaffiene, KMPlayer, Digikam, Gwenview, K9Copy (and possibly more). I have not been keeping pace with the latest development news and I imagine some of these apps are now 4.x compliant (Amarok, Digikam?).

I don't want a hodge-podge mixed environment. I don't even like running GTK apps in KDE, although I have little choice with respect to a handful of apps. Therefore I'll remain with 3.5.10 longer than some people. The 3.5.10 desktop is configured much the way I want and is stable for me. There is no rush on my end to move to 4.x. I might even forego updating to the next Slackware release and only rebuild/update certain packages. Final point: I am undecided today as are many people.

It sounds to me like the logical choice would be to skip the upgrade - stay with 12.2 for as long as you want.

If there's no compelling reason to upgrade Slackware outside of KDE, then don't. I have 12.2 running beautifully and, like you, I am more comfortable with KDE 3.5.10 for the time being. The downside of not moving to KDE4 is that KDE3 versions of apps are no longer being actively maintained. This, however will still be a problem whether you run KDE3 on Slackware-12.2 or Slackware-13.0, so trying to build KDE3 on the next Slackware seems like a waste of energy. You may feel you need to move to the next version of Slackware for other reasons - I don't know.

I dual-boot both on my laptop at the moment (and spend 95% of my time in 12.2) and will likely continue to do this long after the next version of Slack is released.

Steve

Not quite enough, it's just a beginning. The subject itself screams for the merits, and these screams will rise the very same day new release with kde4 sees it's first daylight.
On the other hand, I'm not really sure if Kde4 will be part of new release at all (the way it is now of course). There are still lots of work that has to be done, but if so, it would be nice to have an option to chose between 3.5 and 4.x, if not, I don't see a reason of switching at all, I stay with 12.2 for a while, just like many others.

KDE4 will be a part of the next official release as KDE3 is now gone from -current.

There is always room in this world for one more opinion and I'm not going to resist that. Yet I would appreciate keeping this thread focused on the technical challenges of keeping 3.5.10 running with the next Slackware release.

Just a quick note. I won't have time to investigate further at least until next weekend.

Today I ran a first pass at updating 12.2 to Current to test KDE 3.5.10. Roughly, I did not update any KDE packages, qt, or any qca packages.

I was able to boot into KDE 3.5.10. I received an error message about the media notifier not running and I could not manually start that KDE service. I'll investigate that oddity on a proverbial rainy day. Otherwise my quick checks seem to indicate no noticeable problems. Caveat emptor: My checks were quick, however, as I ran out of time to proceed with the project.

For now then, the first report is that people wanting to run 3.5.10 with the next Slackware release might not be in a tight bind. Of course, that is subject to change as Current evolves.

Slackware-current uses python 2.6. KDE will not work with python 2.6 without patches. Namely the dcop python bindings (from kde-bindings) needs patched. I'd search Gentoo's bugzilla for the patches.

You can build KDE 3 on -current, install it to /usr/opt/kde3 to match the naming convention of other qt-3 packages in Slackware. Everything works with changing the QTDIR=, prefix=, sysconfig= for the original SlackBuilds.

Here's a patch against the 12.2/sources/kde/ directory to get you started. Get the kdebindings patches, and you're all set You'll need extra/kde3-compat for kde-libs, qca, arts, and qt3. This builds a proper Slackware-current kde3. That way you can install the next version and kde3, rather than 12.2 - upgrade - kludge.

--------
Can't upload .diff, .gz, .tar, .tar.gz so here's the .diff renamed to .diff.txt

Attached Files

kde3.diff.txt (19.7 KB, 25 views)

KDE4 is a lot more demanding of the video hardware. GEFORCE2 mx100 32MB is barely usable. RIVA TNT2 is not.