Anne Wilson <cannewilson@xxxxxxxxxxxxxx> posted
200907121047.36858.cannewilson@xxxxxxxxxxxxxx, 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.
