Re: [kde] What's the official status of 3.5.x, anyway?

On Sunday 12 July 2009 14:35:49 Duncan wrote:
Anne Wilson <cannewilson@xxxxxxxxxxxxxx> posted

Will there never be an end to this bullshit? No-one forces you to do
anything. You can use KDE3 in a number of distros. You just choose to
use one centered around KDE4. That's entirely *your* choice.

It's not bullshit when, apparently, bugs are being closed on kde3 apps as

It is bullshit when you state that you are being forced to use KDE4. It's
that simple.

There has been an attempt to 'clean up' recently, identifying which packages
no longer have maintainers. There are a number of them, for many reasons,
mostly unconnected with KDE. People's lives move on. They get a first job.
They get a fiancee. They marry, have children, get other family
responsibilities. Sometimes they just lose interest. If someone else steps
up to maintain a package that's fine. If no-one does the choice is between
marking its bugs as 'won't fix' and 'unmaintained' or leaving you in hope that
if you hang on long enough you'll get a solution.

As for my distro, it's still keeping kde3 around for awhile. However,
it's (apparently) simply being honest about upstream, and well, when
upstream starts closing bugs on apps as unmaintained...

Honest to your view, but wrong. As I explained above, there are good reasons,
often unconnected with KDE.

Oh, well. So despite the fact that it seems there's all sorts of
people for whom KDE 4 remains "substantially broken",

KDE4 now has about 98% of KDE3's features. It is not "substantially

Now /that's/ BS! Note that I /very/ /carefully/ stated "for some
people" (here quoted as all sorts of people). Yes, it is still literally
"substantially broken" for "some people", even "all sorts of
people." (Tho, you DO get a point that I should have qualified that "all
sorts" a bit more, perhaps saying "many sorts". I should know well
enough by now the dangers of "all" without qualification.) That's the
claim I made, and it's absolutely true. I won't argue the 98%, which may
or may not be a figure simply taken out of thin air, but suppose it's
right. What about the people that depend on that broken 2%?

People that depend on the last remaining broken features generally cooperate
in finding the problems and getting them fixed. Sometimes they cannot be fixed
in the way you may expect, but generally solutions or at least work-arounds
are found. People that truly depend on these things don't sit back a whine
vague claims.

Fact: It remains "substantially broken" for me, and my usage.

Have you defined anywhere what it is that is "substantially broken" for you?
Was it buried in a long message I gave up on, or is there a clear statement
somewhere that I've missed?

Now you propose to tell me that it's working /fine/ for me?

Point me to exactly where I said that. I merely asked you to be explicit
about what doesn't work.

It CAN be blamed when the same system worked with a previous version, but
does NOT do so with a new version, with the same general config and eye
candy settings. That's called a regression.

You are not listening. If there is a bug in a package it can and should be
fixed. That does not alter the fact that the deeper issues of video driver
changes and audio driver changes are way outside the control of KDE. It's
true that the older releases and other desktops do not necessarily use the
parts that have these issues, but working with the kernel folk and driver
developers is in the long run more rewarding than simply putting your head in
the sand and hoping the issues will go away.

After I sent that I remembered one problem I have run into. kmail
started crashing when I closed the compose window, either to send the
mail, or even without sending. If to send, the message would still
appear in the outgoing mail folder, and upon kmail restart, I could send

I'm guessing that was naturally occurring issue due to a library upgrade,
however (tho none appeared in the binary library dependency scan that
revdep-rebuild does), that would have likely gone away had I recompiled
the various components in the right order. I even have a general idea of
the components I'd have had to investigate and/or recompile, and the
basic order I'd have done it in.

However, as it happened, I didn't need to, as I had kmail4 installed as
well, and after setting it up with my mail accounts (which didn't
transfer for some reason, tho everything else seemed to), it worked
fine. As mentioned in the post that quote came from, I'm already
switching to kde4 apps where possible, unmerging the 3.5 counterparts,
and since I was already looking at switching to 4.2 kmail, I just did
that and uninstalled the 3.5 version, rather than bother tracing and
fixing 3.5's kmail issue.

I'm glad you got a solution. It does sound as though the problem was the
hybrid 3.5/4 system. In most cases I'd suggest that you post a bug report,
but in this particular case I think you are correct to ignore it and move on.
KMail is changing to the new database-maintained system, and I don't see
anything much but security issues being resolved in the older one, due to
that. We should all see the resolution of KMail issues that have bugged us
for years. :-)

Except of course the fact that konqueror 3.5 isn't the best at
supporting the latest web standards

Most of Konqueror's problems have been that it does support web
standards, where other browsers such as Firefox bend over backwards to
handle sites that are totally non-standard.

I expect you're correct, there. Thus, thanks for the correction. Never-
the-less, I expect konqueror 4.x to work better (or anyway, not worse, it
works, but I'm not sure if it works better yet, by actual testing) than
the 3.x version was.

I'm not sure of the current situation. I do get the impression that it's
slightly better, but it still does have issues. However, I sat in on part of
a developer meeting a few days ago, so I can categorically assure you that
work is being done and issues are being addressed. It won't happen overnight,
but we will see improvements arriving.

But there's a bit more to it than that. As I explained, a lot of it is
that the konqueror scripting permissions are much harder to get working,
without simply turning it on for every site, than they are for firefox
with the help of the noscript extension.

This is something I know nothing about. I'm sure someone would be willing to
help if you ask clear and specific questions about it. If you can't get an
answer from the normal lists I'll try to get an answer direct from developers
for you - but you will have to remember my ignorance on this subject and
describe the problem very clearly.

With konqueror (and I believe one of the addons packages, which I believe
supplies the GUI elements to avoid the round trip to the javascript tab
of the java and scripting applet in konqueror's config/preferences), it's
possible to have scripting off globally, then turn it on with the click
of a button for a specific site, as well as to configure retained
permissions for specific sites.

konqueror is missing, however, a way to turn on scripting for both that
specific site/page and any it references, except for those that are
blacklisted, without turning on scripting globally. It's also missing a
method by which one can easily see the sites whose scripts will be run if
it's turned on thusly, and a way to blacklist or allow each individual
site on its own, all from a simple click-GUI, that is, without view-
source and groking the page code, plus potentially the code of several
additional "extra" files. Third, it's missing dummy aka
stub-scripts that can be executed in place of the originals to prevent
scripting errors, etc, for the most popular tracking and etc scripts
(Google's urchin-tracker, etc). Those are all provided for firefox by
the noscript extension.

At this moment I don't know who would have answers to this, but I'll try to
find out for you.

However, there /is/ a question buried in there. That was intended to be
an aside note of other threads I have yet to start, as I've been trying
to keep one main issue per thread, which is why I didn't ask it in
plainer terms. However, if you can answer it, I'd welcome it. Then I
won't have to bother with the separate thread.

The question is: Is there an easy way to get a base KDE 3 desktop,
kicker, kdesktop, dcop, konqueor-3 file associations, etc, to switch to
using konqueror-4 as the main browser, while konqueror-3 remains
installed (as a dependency), without having to go thru each individual
file association, etc, and set it to use konqueror-4 specifically.
(That's as opposed to the default generic konqueor, which will naturally
default to konqueror-3 for a kde3 desktop).

Look, I'm not a developer, but it seems to me that you are asking for trouble
to mix KDE3 and 4 like this. Is there really a reason to? In KDE4 you can
have a panel that is very similar to kicker, and desktop that is almost
identical to your KDE3 desktop, dbus doing what dcop used to. Why risk
trouble by trying to use the old methods?

It seems to me that many of the complaints about KDE4 come from people
who try to run a very mixed system, on a pick-n-mix basis. If you feel
you really need to stick with KDE3 for now I'd recommend installing KDE4
as a VM, learning to use it, and resolving any issues you find. That
way you'd both be useful to the wider community and be prepared to move
over full-time when the advantage outweigh the disadvantages.

Actually, I've been doing pretty much that, tho not the VM thing. But
separate 3.x and 4.x configurations, scripts to switch between them, the
whole thing. And 4.x simply hasn't been working well as a whole.

Since the launch of KDE 4.0 I have run systems that have parallel 3/4 and pure
4. I can state categorically that the pure KDE4 systems did run better than
the parallel ones. Again, this is not a developer's insight, but I suspect
that to run them in parallel needs some concessions, which have side-effects.

So now I'm going the piece at a time route. switching what works, while
I'm still running a base kde3 desktop since the base kde4 desktop has
been the big problem -- in general the individual apps work now. There's
just too many huge (for the way I work) exceptions to switch over to kde4

One of those huge exceptions is khotkeys-4 multi-key.

Please explain in detail - and I'll try to get information for you.

I often skip over long threads when my time is limited, so I presumably missed
your description. Can you give me detail without making it too long?

(FWIW, I go days without using the menu, and tend to use the run dialog
for stuff like the web shortcuts

As I do. Indeed I use it far more under KDE4 than I ever did before.

gg: google search, etc, stuff like k3b
that's not used enough to have a hotkey for and more hassle to get to in
the kmenu than to type in, etc. All my routine stuff is hotkeyed,
including menu entries I've added with shortcuts to my favorite sites and
my bank. A new KDE without such functionality, now that it was there in
kde3, is not only a regression, but is, for me, "substantially broken.")

There is certainly the facility to set keyboard shortcuts - is this not what
you mean?

If that was the /only/ issue, it wouldn't be a big deal, but it's not.
There's many such issues for me alone, and others I'm not even running
into as I don't use that functionality. Further, as linked in the
initial post, the announced policy was 3.5 support as long as there are
users, and there are obviously still users, end users at least, but
policy seems to have changed. KDE seems to be deserting these users it
had announced it was going to support until they moved on.

"Support" and "development" are different issues. Security issues will be
supported, I believe, for some considerable time. However, as long as
developers give their time freely they will choose to develop the packages
that interest them most and have the most potential. That's a simple fact of
life. KDE is a loose group of people who care deeply but have limited time,
just like you and me.


Attachment: signature.asc
Description: This is a digitally signed message part.

This message is from the kde mailing list.
Account management:
More info: