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

[Duncan]

Anne Wilson <cannewilson at googlemail.com> posted
200907121825.34053.cannewilson at googlemail.com, excerpted below, on  Sun,
12 Jul 2009 18:25:27 +0100:

> On Sunday 12 July 2009 14:35:49 Duncan wrote:
>> Anne Wilson <cannewilson at googlemail.com> 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 unmaintained.
>>
> It is bullshit when you state that you are being forced to use KDE4. 
> It's that simple.

I said that with the context being that when support drops, security 
support, etc, people will be /forced/ to move on (well, either that or 
remain vulnerable).  Distributions, etc, may continue support for awhile, 
but when upstream drops it, everyone else is on borrowed time.  That 
remains true.  It was also in the context of claims that said upstream 
support is ending now -- that 3.5.10 was the last upstream version.  /If/ 
that's the case, questions about which were why I started the thread, 
then that /forced/ is indeed "now", (where "now" is as soon as the next 
security vuln, several of which appear a year, so it's "now" in the 
context of a change that's likely to take some time).

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

OK, that makes sense and it is indeed part of the question I was asking.  
I now have both your statement and Lydia's on it, which is good.

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

I said "(apparently)".  Of course, lack of a definitive statement, either 
in the archives here that I could find, or on the KDE site itself, adds 
to the confusion, when there's rumors floating around and when KDE 
projects of various distributions are making definitive public statements 
of their own.

This thread at least gets something in the archives, with a title that 
should be easily found for anyone looking.  I spent many hours looking at 
both at the list archives and on the KDE site, and didn't see anything 
even close to as covering this, or I'd have not started the thread.

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

No, they ask questions, get the answer that they can, and then either go 
with that or find other solutions, as appropriate.

Which is what I'm doing.

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

One example that I've cited numerous times now is the khotkeys multi-key 
support bug.  There's even a single-post thread on it, no replies yet, 
quoting bug number, etc.  FWIW, it was also covered here previously, and 
I found that discussion in the archives, which was how I knew it wasn't 
just me, and that there was an open bug on it, with no fix in sight.

FWIW, bug #161009  http://bugs.kde.org/show_bug.cgi?id=161009

As I've explained, that's "substantially broken" based on my work-flow.  
That's the one issue of several I've already researched reasonably 
definitively, but it alone is enough to make kde4 "substantially broken" 
for the way I use KDE.  But there are others I'm still researching.

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

I was explicit, having mentioned that in several posts now including in 
it's own thread.  Plus I've been explicit in (I believe consistently, if 
not, someone point it out) limiting the "substantially broken" claim to 
the way some people use KDE.  It's NOT "substantially broken" for 
everyone, nor did I ever claim it was.  (I've also been quite consistent 
about putting that "substantially broken" in quotation marks, indicating 
that's what people like me, with blocker issues, that have yet to be 
resolved, can call it, for the way we use KDE.)

Since you claimed that was BS, /with/ those limitations, even in what you 
quoted, that's the equivalent of saying that it must work fine for me, 
or, at least, that it works to the extent that it has no blocker issues, 
and thus is not "substantially broken" for me.

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

... And I've been regularly testing kernel rcs for some time, and in fact 
now run a direct git repository.  I've filed and had a number of kernel 
bugs fixed, and there's one open right now that I just finished git 
bisecting to the specific commit earlier today.

So that side's under control.  But what I'm saying is that with the same 
hardware, the same drivers, working correctly on kde3, if they aren't 
working on kde4 (or are, but dog slow, compared to kde3 on the same 
hardware, kernel and X) with the same basic settings (opengl off, 
composite on, exa on, set for transparency, no drop shadows, no fading, 
so transparency is the only effect that's active), that's a regression 
and kde4 bug, not a driver bug, not a hardware bug.

In my case the bug would appear to be either kwin or plasma related, 
unless of course it's qt-4 related.  But then that's developed in pretty 
close tandem with kde anyway, in an all around beneficial relationship.

What I may have to do is try a different window manager, maybe kde3's 
kwin instead of kde4's, and see if that speeds it up with an otherwise 
kde4 desktop.  If it does, then it's certainly the window manager, kwin4, 
that's the issue there.  If it's still slow, it's probably plasma.  I can 
then check bugs and file one if necessary, accordingly.

That's what I was saying about still needing to do research on the 
others, before I file bugs or ask about them here.

> I'm glad you got a solution.  It does sound as though the problem was
> the hybrid 3.5/4 system. 

I doubt it.  What I expect it was, was a minor library dependency issue.  
One of the dependent libraries had been upgraded I imagine, and the ABI 
was just enough different that kmail (or a function in kdelibs that kmail 
used, or a function in kdepimlibs or whatever).  I've little doubt that a 
bit of investigation and rebuilding first kdelibs, then kdepimlibs (I 
think it is that kmail depends on, I'd have checked, of course), then 
kmail, in that order, would have fixed it.

But I just switched to the 4.x version and unmerged the 3.x version, 
instead.  Since switching to 4.x is my goal anyway, might as well.

> We should all see the resolution of KMail
> issues that have bugged us for years. :-)

The way it has worked has been perfectly fine for me, for years.  So 
hopefully they don't break what's working in the process.  Of course, I'm 
POP3 and a local maildir, no IMAP, and from what I've read, it's the IMAP 
folks that have had the most problems with kmail, so I wish them luck, 
but just don't break POP3 and local maildir in the process. =:^)

> I'm not sure of the current [konqueror4] situation. [...] 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.

We both agree on that! =:^)

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

Really, there's nothing to help with.  It's simply that because firefox 
is so extensible and due to its much greater usage, all sorts of people, 
power users with their own little project, SOHOs doing it for at least a 
job on the side if not their main job, companies sponsoring it for PR, 
there's all sorts of extensions for firefox that do all sorts of things.

No devs, firefox, konqueror, IE, otherwise, are going to be able to 
develop that sort of variety on their own.  All they can do is make their 
browser extensible, document it so people can work with it, and if at all 
possible, cooperate with enough other people on the same extensibility 
standard that it has market share like firefox or IE.  Do that and all 
those little power user and normal people extensions will just appear, 
and because they're all specialized at doing what they do and doing it 
well, they'll be better than any feature the main browser devs could have 
designed from the top on their own.

Because konqueror doesn't have that mindshare, and isn't yet cooperating 
with enough other like projects on a common standard (well, actually, I 
think there's at least a bit of that in the works, but it's still very 
much just that, in the works), there's no way it can match the extension 
flexibility firefox has, and since it's firefox extensions that allow it 
to do what I was talking about, konqueror simply isn't going to be able 
to match it, and if they did manage to match it at a snapshot, they'd 
never be able to keep up with the firefox extension improvements.  Not 
until they get a big enough market/mind share to have that sort of 
variety of community authored extensions that firefox has.

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

But that's what I'm having trouble with.  Plasma (or at least the 
plasmoids I'm familiar with) is still missing some of the stuff kicker 
applets did.  There's also some serious problems with speed in either 
plasma or kwin4 or both.

So what I'm having to do is use kde3 for the base desktop, while 
migrating most individual apps (other than kicker, kdesktop, kwin AND 
khotkeys) to 4.x.  The general apps seem to work reasonably well for me.  
But the core desktop itself, doesn't.  So I gotta still use kde3 for the 
core desktop, until I can resolve whatever kde4 issues remain with the 
components that I'm having issues with ATM.

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

But even when running all kde4, the stuff that's broken is still broken.  
I'm only running the mixed desktop, because there's parts of kde4 that 
aren't working for me, and for them, I have to still use kde3.  And, I'm 
only now switching to kde4 at all, tho I've had it installed and have 
been trying it on and off since before 4.0's release.

As for having them on the same machine, well, there indeed used to be 
issues with them overwriting each others stuff, but Gentoo has that 
pretty much taken care of now.  I've not seen a bit of that since I 
finished straightening out and separating the two user profiles to match 
what Gentoo had just finished doing to separate the system installation 
and profiles.

>> One of those huge exceptions is khotkeys-4 multi-key.
> 
> Please explain in detail - and I'll try to get information for you.

See the bug link above, and the separate (single post) thread for my 
details on it.  The title is "Any known timeline on bug 161009, kde4 
multikey khotkeys?", posted here about 40 minutes before my original post 
starting this thread.

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

Yes, but they can't be multi-key, except for modifiers.  IOW, my keyboard 
has extra "Internet" keys.  I have one of them, XF86HomePage, setup as my 
"launcher" key.  Currently on khotkeys3, I have XF86HomePage,w (hit the 
launcher, then the w key) setup to start konqueror in web mode (w for 
web), for example, while XF86HomePage,c  starts konsole (c for console).

Then I have Ctrl-Shift-XF86HomePage combinations for a whole additional 
set of apps, and I could setup each modifier set separately.

With khotkeys4, I can only setup one key for each modifier.  So I can 
setup XF86HomePage for one thing, Ctrl-XF86HomePage for another, Shift-
XF86HomePage for a third, etc.  But I can't setup XF86HomePage,w for web 
browser and XF86HomePage,c for konsole, because it won't take the second 
key.

That's what bug 161009 is all about.  And, there's no fix in sight.  But 
for people like me who do 90% or more of their app launches using multi-
key khotkey sequences, that's a blocker.  For me, it's a serious enough 
blocker that kde4 as a whole remains "substantially broken" until I find 
a working solution, preferably a working khotkeys4 multikey, but if the 
bug's correct, that could be 4.4, or 4.10, or 4.20, or 4.100, before 
/that/ ever gets fixed, despite the fact that the bug is confirmed by 
popular vote.

In ordered to circumnavigate that blocker, then, I'm now looking at non-
kde solutions, xbindkeys, xhkeys, others.  If I can find one that works, 
kde4 or non-kde, that'll eliminate /that/ blocker at least.  But there's 
others I have to research and eliminate as well, before all the blockers 
are clear and I can actually run a full kde4 desktop and eliminate kde3 
entirely.

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

Believe it or not I do understand the distinction.  But when the most 
authoritative word I have is that 3.5.10 is the last from KDE ever, there 
won't be a 3.5.11, even of just konqueror/kdelibs/etc security fixes, 
then I get worried.  I'm not asking for continued development.  I don't 
want or expect any new features.  Just keep what's working, working -- 
and secure, until thinks like that khotkeys4 bug are fixed and those of 
us depending on kde3 functionality that we can't get in kde4 yet can 
finally upgrade without issue.  And I'm normally an early adopter.  So if 
there's stuff blocking me, as a normal early adopter, from switching, 
then what of all the others?  (Actually, in this case, I think it's the 
power users, the folks that were using some of the features of kde3 to 
its fullest, that are having the issues with kde4, because it's those 
fancy features that haven't been fully ported yet.  Some of them may 
never be ported as the kde4 functionality is simply different.  But I'd 
hope something as basic as multi-key hotkeys, can be, as indeed the base 
functionality already has been, just not the advanced multikey stuff.)

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