What's the official status of 3.5.x, anyway?

[Duncan]

Anne Wilson <cannewilson at googlemail.com> posted
200907121047.36858.cannewilson at googlemail.com, excerpted below, on  Sun,
12 Jul 2009 10:47:36 +0100:

> On Sunday 12 July 2009 10:17:10 Duncan wrote:
>>
>> I guess the ubuntu/kubuntu folks were indeed wise ignoring such claims
>> and thus avoiding a 3-year LTS version of KDE.  Well, either that, or
>> KDE indeed doesn't consider "end users" as /their/ users, only
>> distributions, etc, and with all the major distributions moving on, and
>> those that weren't doing so before now pretty well /forced/ to move
>> on...
>>
> 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 
unmaintained.

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...

>> 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
> broken".

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%?

For those people, it IS "substantially broken".  Again, that's the claim 
I made.  Yes, there are parts of KDE4 that work great.  But there are 
equally parts that do not, and there are obviously quite a number of 
people depending on one of them or another or you'd not have to be asking 
"Will there ever be an end to this "BS".

Fact:  I'm not telling you how well your KDE 4 (or 3, or anything else 
for that matter) is working for you.

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

Fact:  There's enough similar complaints from others, under many 
different circumstances, to generate "will there never be an end to this 
BS" comments from people who apparently don't suffer those same problems.

Now you propose to tell me that it's working /fine/ for me?  How can you 
even know that?  Do you have spyware on my computer?  What about the 
computer of everyone else that's complaining, that you're now asking 
"Will there ever be an end to this BS?" about?  Because I did NOT say it 
was "substantially broken" for everyone, only that it was "substantially 
broken" for some people. (I'll take the point you did NOT argue, that my 
"all" should have been "many" sorts.  Had you argued that, you'd have 
been 100% correct.)  If you're saying that's BS, then YOU'RE the one 
spouting "BS".

> It cannot be blamed for problems that arise from changes
> occurring in the realms of display systems and sound systems, even
> though in some cases using KDE can side-step these issues for the
> moment.

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.

>> I haven't run into anything really broken with 3.5 yet, here (tho I
>> don't have knotes installed as I just use text files for that purpose).

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 
it.

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.

>>  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.

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.

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.

Working with noscript, firefox's JSView extension allows one to actually 
view the source of individual external CSS and scripting files, if 
desired, to see if they're safe to execute, or simply to see what they're 
doing, without having to go thru the process of viewing the primary page 
source itself and parsing it to get a list of every script and CSS file 
it references.  Combined the two and one has far more powerful scripting 
permission and debugging resources available thru firefox than thru 
konqueror.

Practically, I saw the effects of this with my US income tax efile 
provider.  Visiting it with konqueror in the default scripting locked 
down mode, it naturally didn't work, as it requires scripting.  OK, 
that's expected.  No problem.  Hit the button to turn it on for that site.

But it still didn't work.  Well, since I was already trusting the site 
with my financial info, I decided I might as well turn on scripting 
globally.  IT WORKED.

With a serious bit of hassle, reading web page source code to find where 
it's fetching the scripts from, etc, I was eventually able to figure out 
just which sites needed permissions turned on, and turn off scripting 
globally again.

Now compare that to firefox (with noscript and JSView extensions).  I 
visited the site in firefox with scripting off.  No surprise, it didn't 
work.  OK, click on noscript to see what sites it /wants/ to have 
scripting permissions.  Turn on some of them them, then check again.  
Turn on a few more.  Decide I want to see just what one of the sites is 
serving.  Check JSView and grab the script from the list (note, just ONE 
source file viewed, an actual script file).  Decide it's fine.  Allow 
that.  See that it's also wanting to run the usual urchin-tracker etc. 
scripts.  But they're already in the blacklist so no problem.

IT WORKS!  With firefox, I was able to do it all except examine the 
source of the one script I was unsure about, with simple GUI clicks, no 
further examination of source required.  Even that one script, called 
from another a couple layers down in the list, was a simple couple of 
clicks to view source once I turned on site with the script that called 
it.  Compare that to konqueror, where I had to wade thru viewing the 
source of multiple files just to find out what sites the page wanted to 
pull scripts from.  (Actually, I cheated a bit with konqueror, switching 
to firefox and using its much better tools after about the second or 
third source file on konquoeror, thus getting me quick access to the list 
of sites and scripts, allowing me to feed them back into konqueror's 
config dialog to allow them as appropriate.)

Now, it should be mentioned that I do NOT particularly expect the 
konqueror (or khtml/webkit) devs to implement this sort of thing 
directly, just as it'd be ridiculous to ask them to develop an 
alternative for every other extension that firefox implements.  However, 
what they COULD do is implement a plugin architecture, shared by enough 
of the khtml/webkit family to give it reasonably widespread distribution, 
so that USERS can develop these sorts of solutions.  Note that konqueror 
as of 3.5 ALREADY has an extention architecture (tho I'm unsure if it was 
as flexible as firefox's), but that because of the limited market share, 
it didn't attract the self-sustaining and indeed THRIVING ecosystem of 
user, SOHO and corporate sponsored extensions that firefox has.  The 
failing is thus one of market share, not of failing to implement 
extensibility.  If konqueror was to cooperate with the other khtml/webkit 
users to create a single extensibility architecture that Google Chrome, 
Apple Safari, Konqueror, and whoever else, all implemented together, and 
further cooperate in developing a centralized security pre-screened 
repository, such as firefox has, there's a strong likelihood that a 
similarly active extension community would develop.

As I said, this is beyond (way beyond) simple standards compliance.  But 
it's simple fact that just as no proprietary company can keep up with the 
code output of the entire open source community, no single open source 
project is going to be able to keep up with the code output of the entire 
open source extension community.  That's where cooperation with enough 
others to establish a decent market base is all about.

And actually, that's one of the reasons I'm interested in konqueror for 
kde 4, because the times they are a changin', and konqueror 4.x (among 
other components, plasma, etc) is doing far more in this regard than pre-
webkit, pre-webkit qt-integration kde3 konqueror could have ever done.

>> I'd like to switch to konqueror 4.x, but that's rather difficult as
>> long as konqueror 3.5 is installed and I'm running from a 3.5 desktop,
>> including kicker and dcop.  But I can't unmerge konqueror 3.5, as it's
>> a dependency of kdesktop 3.5, which I'm still running because the 4.x
>> plasma etc stuff is still too broken...
>>
> Vague claims.  Try asking questions about particular problems and you'll
> probably get answers that clear them up.

This isn't complaints.  It's simple statements of dependencies.  I 
unmerged konqueror 3.5 and the system wanted to remerge it.  
Investigating why, it was due to kdesktop.  That's not surprising and is 
actually reasonably expected.  I left konqueror alone at first, precisely 
because I did expect it to be required by something.  Then after I had 
the other components unmerged and all dependencies came up clean, I 
decided to try konquoeror 3.5 on its own.  As I expected, it was a 
required dependency, at least of kdesktop, which as part of the base kde3 
environment, can't be unmerged if I'm still going successfully continue 
to run the kde3 desktop, since the kde4 desktop still has issues.

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). 

Realistically speaking, I'll be surprised if it's particularly easy, as I 
wouldn't expect it to be, but then again, I might just have a pleasant 
surprise coming. =:^)

Note that before I actually started the separate thread on the topic, I 
was going to investigate changing the browser preference, seeing if I 
could set konqueror-4 specifically (as opposed to 3 or generic), and 
seeing what effect just that single setting had.  It /may/ be all I 
need.  However, this here is before I've actually had a chance to 
investigate that properly yet (not that it matters but I spent several 
hours git-bisecting a kernel bug today, to update a bug report I made on 
the 2.6.31 kernel I'm testing, thus didn't have time to do much with my 
kde project today), so I can't say for sure how well that's going to 
work.  Again, maybe I'll be pleasantly surprised. After all, it's 
technology that has had a few years to develop, what with the MS abuse 
and various subsequent agreements, etc, so it might work better than I 
expect.  =:^)

> 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.

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 
entirely.

One of those huge exceptions is khotkeys-4 multi-key.  Running kde4 all 
by itself in a VM isn't going to help that.  It's simply broken, it has 
been broken, and there's no fix on the horizon as far as one can see -- 
or at least none indicated on the bugs I've seen on the subject. (I've 
already done that research and that thread, no replies yet.)

For someone who uses khotkeys multi-key for probably well over 95% of his 
app opens, that's "substantially broken".  It is, however, not the only 
way KDE4 is substantially broken for me, but it's enough all by itself to 
qualify KDE4 as "substantially broken", for my usage.

(FWIW, I go days without using the menu, and tend to use the run dialog 
for stuff like the web shortcuts 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.")

For that one, I'll probably end up giving up on KDE, and switch to some 
third party hotkey service application.  But that doesn't change the fact 
that a KDE without it, given my usage and the fact that it worked so well 
before, is "substantially broken."  It's just learning to work around 
such breakage.

And that's "substantial breakage" that no VM or config is going to fix, 
because it's functionality that is simply missing from the new version, 
which is therefore a regression from the previous version.  Apparently, 
enough other people agree that the bug has been "confirmed by popular 
vote".  I don't know how many votes that takes, but it's obviously not 
"just me".

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.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.