The discussion was not about openSUSE, it was about the OP's request to have KDE developers continue to maintain KDE 3.

If the question was about maintenance, he just wanted to have KDE3 working. It is for sure a distro-specific question. Otherwise we just should point the Trinity project which is currently being developed.

KDE developers would need to keep supporting KDE 3 forever

Probably you don't count Trinity devs as true KDE devs. Well. That's OK.

especially since Qt 3 is no longer even getting security updates

Do you know about any security-related bugs in Qt3? Otherwise this statement is pointless.

Probably, but eventually openSUSE is going to want to stop packaging obselete components like HAL, which I guess will leave it up to you to keep packaging it.

Currently KDE4 also requires HAL. And yes, if it is removed from OpenSUSE, it can be moved to KDE3 repository by just one mouse click. HAL itself calls udev, it is just one more layer above udev.

guu wrote:

Anixx wrote:

The installation in the VM with the yum package worked well, although I had to break 2 dependencies

There should not be such behavior because all dependencies are satisfied in build-time. Can you provide more details?

Are you sure you're installing it from the correct repository (i.e. I provided the .ymp file link for 11.3, so if you use 11.2 it can report errors).

If there were actually some missing dependencies one could not build the OpenSUSE Studio images because to build an image one have to satisfy all dependencies. So apparently you did something wrong.

Hmmm, where can I find these messages afterwards? It happened in my VM installation which is a bit minimalistic. Both messages were "nothing provides" messages. Meanwhile I used the same repository and yum packet in the main installation. There it installed without problems. I'll test it soon.

Interesting side note: with the KDE3 repository the kdetoys3 package can be installed which contains the kworldclock. It works like a charm even in KDE4. I wonder why it's not part of the kdetoys4 package or even better available as a separate packet?

Ok, now I'm logged in as normal user with KDE35 and WLAN
I got some initial error messages (KDE crash handler with some nspluginscan messages), most likely because my .kde folder was copied from an old SuSE10.0 installation (I had reasons for this particular version...LD_ASSUME_KERNEL support for some legacy stuff). Now everything looks fine. The knetworkmanager can be started from a superuser-shell or with kdesu. I just didn't figure out how to let it start automatically this way.

I had to install some more packets to get the image viewing capability of konqueror back. But now it looks as I like it And I think konqueror is much much faster than gwenview.

So, thanks again for giving me KDE3 back! It solved most problems for me. I hope the rest of the year will continue as good as its first day

(KDE crash handler with some nspluginscan messages)

I suggest you to remove nsplugin for konq package and see if it repeats.

The knetworkmanager can be started from a superuser-shell or with kdesu. I just didn't figure out how to let it start automatically this way.

install networkmanager-kde package (which is for KDE3) and there is an option for autostart.

By the way, I recommend you to use ifup configuration through Yast, and not NM.

guu wrote:I had to install some more packets to get the image viewing capability of konqueror back. But now it looks as I like it And I think konqueror is much much faster than gwenview.

I suggest you to try kmetabar, a plugin for konqueror with an outlook like this:



with a preview area in the left corner.

TheBlackCat wrote:Probably, but eventually openSUSE is going to want to stop packaging obselete components like HAL, which I guess will leave it up to you to keep packaging it.

Alt Linux has an option to build with or without HAL. Here is their spec http://prometheus.altlinux.org/en/Sisyphus/srpms/kdebase/spec, with %define with_hal 1 . One just have to change 1 to 0 to have it compiled without HAL. I think this can be adopted in OpenSUSE as well.

TheBlackCat wrote:Probably, but eventually openSUSE is going to want to stop packaging obselete components like HAL, which I guess will leave it up to you to keep packaging it.

kdebase3 builds well without HAL (just tested in OBS), without any patching. The configure script detects HAL absence automatically. So what's the problem?

Anixx wrote:kdebase3 builds well without HAL (just tested in OBS), without any patching. The configure script detects HAL absence automatically. So what's the problem?

Is it still able to handle removable devices?

TheBlackCat wrote:

Anixx wrote:kdebase3 builds well without HAL (just tested in OBS), without any patching. The configure script detects HAL absence automatically. So what's the problem?

Is it still able to handle removable devices?

I did not test it but I think this is a minor issue. I believe kernel can now mount them authomatically.

Anixx wrote:

TheBlackCat wrote:

Anixx wrote:kdebase3 builds well without HAL (just tested in OBS), without any patching. The configure script detects HAL absence automatically. So what's the problem?

Is it still able to handle removable devices?

I did not test it but I think this is a minor issue. I believe kernel can now mount them authomatically.

I don't think being able to connect and disconnect removable devices is a "minor issue", especially not when so many people are using thumbnail drives for storage.

TheBlackCat wrote:I don't think being able to connect and disconnect removable devices is a "minor issue", especially not when so many people are using thumbnail drives for storage.

The removable devices are now mounted by kernel. KDE has nothing to do here. The only thing the removal of HAL can affect is the disappearance of mount properties tab in the properties dialog of a drive - the tab which currently does not affect anything anyway.

TheBlackCat wrote:...especially since Qt 3 is no longer even getting security updates, making KDE 3 a potential security risk.

As I read this, I would like to note that Qt 3 is part of Red Hat Enterprise Linux 6, which means that Red Hat takes responsibility to support it in their distribution until late 2017.

Wouldn't anyone like to provide KDE 3 packages for RHEL 6/CentOS 6/Scientific Linux 6? I might be interested in using them myself. Maybe it would be useful for this purpose to have a look at the KDE 3.5.10 packages provided for RHEL 5 at http://kde-redhat.sourceforge.net.

I only see KDE4 packages there.

Anixx wrote:I only see KDE4 packages there.

That's odd... the binary packages are at http://apt.kde-redhat.org/apt/kde-redhat/redhat/el5/i386/RPMS.stable/, but it looks like he deleted the SRPMS Sorry.

I am presently running KDE v. 4.5.4 on Slackware-Current. In all honesty it was hard getting here. The upgrade from v.3.5.10 was indeed painful at first because it was a huge change and one that whose first impression was confusing. It's not hard to accept great change, a steep learning curve if one can see the destination in mind and agree that is a good place to go, The upgrade was a triple whammy because

1) it was hard to even see the desired destination let alone agree it might be worth the effort to get there.

2) One had to give up skills as well as applications for questionable replacements and some seemed like the exact wrong direction. A case in point here is that it seems like the important KPackage (with it's full path list of all installed files for each specific package) was gutted and dumbed down to be a bad Synaptic clone. If one has Synaptic (or it's analog) one doesn't need KpackageKit where KPackage was a useful complement. This seemed a poor tradeoff and an indication of poor planning and an indicator of heading in a wrong direction. And why did it seem so hard then just to add a symlink to the Desktop?

3) Added to the above it came at a huge cost (at first) in resources. What was this akonadi, nepomuk, strigi, virtuoso combo proposing to do for me at such a huge load on resources?

Fortunately starting with v. 4.5 each of these issues began to be resolved not the least of which for me was getting a glimpse of the Big Picture. I am beginning to see that in time the Unholy Four will actually become of use to me and they already are beginning to behave themselves resource-wise. I still like kfmclient better than Dolphin but I recently learned I can set kfmclient as default. I can run the old KPackage with Slack's KDE3-Compat package.

The biggest surprise was discovering how easy it is to add programs to the desktop once you know how and more importantly how many of those can be replaced by Plasmoid widgets that use negligible resources. Not only that but Plamoids can do things like report to the Desktop items that were impossible for any program before because of the new Desktops deep integration with databases and underlying services. I love the STDIN widget and run several. I am also pretty amazed by all that KRunner can do once I found out what "the wrench" was for.

So I am posting to deliver a carrot and a whip, The KDE Team deserves kudos for vison and ambition and the courage to take such a big leap. They also deserve some castigation for gutting KPackage for no good substitute but mostly for implementing the Unholy Four when they still hogged so much in the way of resources. Also at first I was a bit horrified to see 300 running processes where v3 commonly sported half that, but another reason for accolades is that apparently the Team has implemented superior memory management for sleeping processes because once The Four were tamed, it's quite fast even compared to v.3

You guys still grousing should bite the bullet, upgrade to 4.5 for the improvements and take on the learning curve. IMHO It's worth it.