Anixx wrote:

QT3 and KDE3 reached a solid state. even if it's not maintained anymore, there shouldn't be so much to maintain? Isn't it possible to have some compatibility layer?

There is no need for compatibility layer. Just install KDE3 from KDE3 repository. I wonder, if it so difficult to just write "opensuse kde3" in google? Here is the first search result: http://en.opensuse.org/KDE3

And to install the minimum KDE3 desktop you have to just click here:
http://software.opensuse.org/ymp/KDE:KDE3/openSUSE_11.3/kdebase3-session.ymp

Thanks for the tip!

I read a lot about why KDE3 has been removed from the list of available desktops and my impression was that it would be impossible to run it anymore. It also lets me wonder why a new branch "Trinity" has been started (which apparently doesn't come with rpm packages yet, so I didn't test it).

Since I easily ruined my KDE4 by just changing to nm-applet, I'll certainly try your suggestion in a VM first

TheBlackCat wrote:There is a huge amount to maintain.

End-user has no reason to bother about maintenance.

TheBlackCat wrote:Linux is a rapidly-changing target. The solid (KDE 4 hardware interface people) spent much of the KDE 4.5-4.6 period just switching KDE from the old Linux hardware stack (HAL) to the new one (udev, upower, etc). Changes in things like gcc need to be dealt with.

If you say so, one could presume you're familiar with what you are saying. Can you please give some examples of such difficult to maintain changes in hardware and gcc?

I am asking seriously and as a maintainer of KDE3 in OpenSUSE. Maybe you even can teach us which packages we dropped?

To be more precise, here is the KDE3 status in OpenSUSE, https://build.opensuse.org/project/monitor?project=KDE%3AKDE3. Can you please count what percentage of packages were dropped since OpenSUSE 10.3 or since 11.1 ?

TheBlackCat wrote:Further, the KDE 3 code base was extremely brittle and hard to maintain.

Was KDE2 code also brittle? I suppose you looked at the code yourself, and not just repeating what KDE4 devs said?

Since I easily ruined my KDE4 by just changing to nm-applet, I'll certainly try your suggestion in a VM first

In that case I suggest you to try the pre-built KDE3 ISO images:

For 32-bit image: http://susestudio.com/download/0052edb3 ... -0.0.1.iso

For 64-bit image: http://susestudio.com/download/94f02b17 ... -0.0.1.iso

Anixx wrote:

Since I easily ruined my KDE4 by just changing to nm-applet, I'll certainly try your suggestion in a VM first

In that case I suggest you to try the pre-built KDE3 ISO images:

For 32-bit image: http://susestudio.com/download/0052edb3 ... -0.0.1.iso

For 64-bit image: http://susestudio.com/download/94f02b17 ... -0.0.1.iso

Woooow!!!
Thank you so much! If I knew that before I had used it for my other 10 new machines. Why we didn't see that earlier? I really can't figure out. Over the last years each new machine got a slightly different desktop which is really a mess. I guess I'll add KDE3 to all of them.

The installation in the VM with the yum package worked well, although I had to break 2 dependencies (one of them a dbus packet with a "nothing provides..." message). However, KDE3 is running, kworkdclock is back and I can change it's size , the application search is back in the KDE style menu... No nuts and bolts on the screen... great

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.

guu wrote:

TheBlackCat wrote:

guu wrote:For konqueror, I think it lost all capabilities with images. Yes, it can display one if I click on it. But it doesn't show the exif previews, it doesn't show the thumbs in a sidebar, and as pointed out the controls to move to another pic are missing.

Did you follow bcooksley's instructions?

Yes, I went to these settings before and double checked. There are not many options to check, and the suggested settings were already there.

I submitted a bug report about this.

guu wrote:I don't like an app to store separate thumbs somewhere. I use many scripts for automated image processing (may run a few days on a server). In a sequence of steps, same file names will look different over time and a huge amount of useless thumbs would eat my disk space. I really don't want any undesired actions if my server already recreated the EXIF thumbs and they are available on a USB disk which holds the pictures.

This is not just how KDE works, this is a standard on the Linux desktop. Nautilus, for instance, not only does the same thing, but stores them in the same directory. I am pretty sure it has built-in mechanisms for clearing obsolete thumbnails, so this shouldn't be an issue. But you can set gwenview to clear them on exit. It may even use the exif previews for the thumbs, I don't know.

TheBlackCat wrote:previews can be shown in a 3xN matrix. If I use the left/right arrow keys I'd expect to go through all images...similar to reading a book line by line. Instead, the program stops at the end of one line if I use "right". To go to the next image in the sequence I have to do "down" and 2x "left" which is a bit strange.

This appears to be a Qt issue, not a KDE one. However, it doesn't matter in gwenview if you are using the thumbnail bar since it is a flat list (one row or column, depending on where you put it). So I am not sure why you would need to do this in gwenview.

guu wrote:In a list of 10 repositories in yast2 there was no plasma-network thing.

It is called plasmoid-networkmanagement, and it is in the main openSUSE repository for 11.2 and 11.3, as well as KDE:Distro:Factory and KDE:Distro:Stable, and KDE:SC:4.5.

guu wrote:change yast to ifup, and voila...

As I keep telling you, you should NOT be using ifup.

guu wrote:Then I searched for the KDE-Extra repository and added the following two to get the plasmoid stuff:
/http://download.opensuse.org/repositories/KDE:/Release:/45/openSUSE_11.3 and http://download.opensuse.org/repositories/KDE:/Extra/openSUSE_11.3_KDE_Release_45/
After selecting the plasma-network stuff I was bothered with a dozend conflicts which should have made me suspicious...

Of course you did. openSUSE 11.3 comes with KDE 4.4. You added the KDE 4.5 repository. The plasmoid-networkmanager for KDE 4.5 depends on you having KDE 4.5 installed. So when you tried to install plasmoid-networkmanager for KDE 4.5, it tried to install KDE 4.5. You need to change over to KDE 4.5 to make sure you don't have a broken system. Go to the software installer, go to the "repositories" tab (add it with the "view" menu near the upper-left if it isn't there), go to the KDE 4.5 repository on the left, then select "switch system packages to the one in this repository" (you may still get a few conflicts). Then do the same for the KDE:Extra repository (it must be in that order).

guu wrote:now there was another widget which also couldn't connect.

If you were still using ifup, it isn't going to connect. You need to turn off ifup and turn on Networkmanager.

guu wrote:dbus is not my friend

As I keep saying, this has nothing to with dbus. dbus is merely a communication tool that allows two programs to talk to each other. If there are problems, it is almost certainly with one of those two programs. If one of the two programs isn't running (which is the case here when you disable Networkmanager and enable ifup), then of course the communication is going to fail.

guu wrote:I'm pretty clueless how to get this thing work.
I guess first I will get rid of the KDE45 repositories and revert to the other openSuSE packages to get KDE back.

[/quote]
You shouldn't be messing with repositories unless you know what you are doing. It is very dangerous, you can easily end up with a broken system. You shouldn't need to, either, plasmoid-networkmanager is available in the default repositories and has been since openSUSE 11.2.

Anixx wrote:

TheBlackCat wrote:There is a huge amount to maintain.

End-user has no reason to bother about maintenance.

We weren't talking about the end-user, we were talking about how developers spend their time. We are already very short on developers, dividing their resources like this would drastically slow down KDE's progress.

Anixx wrote:

TheBlackCat wrote:Linux is a rapidly-changing target. The solid (KDE 4 hardware interface people) spent much of the KDE 4.5-4.6 period just switching KDE from the old Linux hardware stack (HAL) to the new one (udev, upower, etc). Changes in things like gcc need to be dealt with.

If you say so, one could presume you're familiar with what you are saying. Can you please give some examples of such difficult to maintain changes in hardware and gcc?

I just did: the move from hal to udev. As for gcc, I've personally had issues with gcc not building older programs because it obsoletes certain things. Not on KDE specifically, but it is likely only a matter of time. Support for python 2.x is also going to end eventually, and python 3 has major breaks with backwards compatibility. Programs coded in python 2 will almost certainly not work with python 3.

Anixx wrote:Maybe you even can teach us which packages we dropped?

I'm not clear on what you are asking here. I am not saying that packages have been dropped (although it looks like a few have, such as kpowersave and the beagle-related packages). The problems are longer-term and more fundamental. It has only been a few years since the switch to KDE 4, yet Linux is already in the process of dropping an entire core software stack that KDE 3 depends on.

Anixx wrote:Was KDE2 code also brittle? I suppose you looked at the code yourself, and not just repeating what KDE4 devs said?

Yes, I listen to the KDE devs. Why shouldn't I? They are the ones who know the code best. Or are you accusing the KDE devs, including those that have been around since KDE 2 or even KDE 1, of lying? Or do you trust them code your entire desktop environment, but not trust them to actually understand that code? If I thought they were liars or incompetent I wouldn't be using KDE at all, any versions since many of the same people who work on KDE 4 also worked on KDE 3 and before.

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?

As for gcc, I've personally had issues with gcc not building older programs because it obsoletes certain things. Not on KDE specifically, but it is likely only a matter of time.

To be more concrete. Currently KDE3 builds well with GCC 4.5, the GCC release which will be used in OpenSUSE 11.4. Suppose GCC introduces some changes which will break compatibility with older software. What could be done then?

1. First, such changes are never revolutionary, fixing software for newer GCC release is usually nothing more than just a mechanic change in syntax, otherwise such changes would require software rewrite which is usually avoided by GCC devs.

2. Even if certain difficult-to-fix changes will be introduced, we can take patches from other projects such as Trinity as they will face the same difficulties, so as long as Trinity alive the GCC-related patches will be available. There are also other Linux distributions such as Alt Linux who provide KDE3 in their official repos so they also can provide easily available patches.

3. Even if we cannot fix, and no patches available, OpenSUSE usually comes with a wide set of GCC compilers, with 11.3 including as old compiler as GCC 3.3. Even if no suitable compiler is available in the official repo, we can build it specifically for KDE3.

So the fear that KDE3 eventually will become incompatible with newer GCC is as valid as regarding any other software.

Besides this it should be noted that KDE3 is in a large part based on kdelibs3 and qt3, both libraries being currently included in the official OpenSUSE repositories because required not only by KDE3 but by a number of other applications.

The same is with Python, with a sufficient note that Python of 2.x branch is gradually becomes closer to 3.x branch. We did not experience problems with Python so far but even if Python completely dropped, it will not seriously affect KDE3 because KDE3 is not based on Python.

Yes, I listen to the KDE devs. Why shouldn't I? They are the ones who know the code best.

Oh yes, KDE4 is rock solid compared to KDE3. No doubt.

many of the same people who work on KDE 4 also worked on KDE 3 and before.

Well I know no KDE4 devs who were here since KDE1. The oldest KDE4 developers I know joined the project when KDE2 was already released. And the difference between KDE2 and KDE3 is mostly cosmetic (not to the benefit of KDE3 regarding stability and appearance).

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.

You can check if your KDE3 repository matches your release.

And to illustrate the validity of GCC fears I would add that I have KDE2 installed on my system which bulds with modern GCC pretty well. You can test KDE2 on OpenSUSE 11.3 yourself by downloading this ISO image: http://susestudio.com/download/8ca72044 ... -0.0.2.iso

You know that KDE2 is about 8 years older than the last version of KDE3.

Anixx wrote:

As for gcc, I've personally had issues with gcc not building older programs because it obsoletes certain things. Not on KDE specifically, but it is likely only a matter of time.

To be more concrete. Currently KDE3 builds well with GCC 4.5, the GCC release which will be used in OpenSUSE 11.4. Suppose GCC introduces some changes which will break compatibility with older software. What could be done then?

gcc and python were just examples. Yes, you deal with changes in any single component pretty easily, especially over the short-term. The problem is that KDE depends on a lot of different components, and we are talking about supporting KDE 3 permanently.

TheBlackCat wrote:gcc and python were just examples. Yes, you deal with changes in any single component pretty easily, especially over the short-term. The problem is that KDE depends on a lot of different components

It seems that at least the changes in Linux since 2000 weren't enough to prevent KDE2 working well on modern systems without any substantial maintenance and patching.

TheBlackCat wrote:we are talking about supporting KDE 3 permanently.

I know no software which is promised to be supported eternally. Anyway KDE3 project in OpenSUSE does not aim at eternal support. If you are for further development, take a look at Trinity project. But even without Trinity I bet that KDE3 in OpenSUSE will be available longer than KDE4 (in case if KDE5 will be introduced).

Anixx wrote:

TheBlackCat wrote:gcc and python were just examples. Yes, you deal with changes in any single component pretty easily, especially over the short-term. The problem is that KDE depends on a lot of different components

It seems that at least the changes in Linux since 2000 weren't enough to prevent KDE2 working well on modern systems without any substantial maintenance and patching.

Major re-working of core components is pretty rare. The problem is that right now it is happening in several areas simultaneously.

Anixx wrote:

TheBlackCat wrote:we are talking about supporting KDE 3 permanently.

I know no software which is promised to be supported eternally. Anyway KDE3 project in OpenSUSE does not aim at eternal support.

The discussion was not about openSUSE, it was about the OP's request to have KDE developers continue to maintain KDE 3. Since KDE 4 was a major reworking of a lot of things, they are almost certainly not going to go back to how things were in KDE 3, in order for things to work out the way the OP wanted, KDE developers would need to keep supporting KDE 3 forever. You are the one who started discussing openSUSE's KDE 3 implementation.

Anixx wrote:If you are for further development, take a look at Trinity project.

Once again, this is about the request from OP that KDE developers continue supporting KDE 3 indefinitely. If Trinity suits his or her needs then great, but those are people who apparently have no interest in working on KDE 4. It is a separate issue from KDE developers taking time away from working on the current KDE version to prop up the old one (especially since Qt 3 is no longer even getting security updates, making KDE 3 a potential security risk).

Anixx wrote:But even without Trinity I bet that KDE3 in OpenSUSE will be available longer than KDE4 (in case if KDE5 will be introduced).

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.