Gentoo Logo
Gentoo Spaceship

Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-desktop
Lists: gentoo-desktop: < Prev By Thread Next > < Prev By Date Next >
To: gentoo-desktop@g.o
From: Andrew John Hughes <gnu_andrew@...>
Subject: Re: Re: kde-sunset: Calling base_src_prepare from kde.eclass
Date: Tue, 23 Feb 2010 21:33:55 +0000
On 23 February 2010 17:27, Duncan <1i5t5.duncan@...> wrote:
> Andrew John Hughes posted on Mon, 22 Feb 2010 11:58:46 +0000 as excerpted:
>> I've managed to rebuild most of KDE 3.5 against the new jpeg-8 library
>> using the overlay.  Many thanks for maintaining it!
>> I think the removal from the main tree is premature.  Not only is KDE 4
>> still an unstable resource hog, but the KOffice developers explicitly
>> state that 2.1:
>> 'is not aimed at end users, and we do not recommend Linux distributions
>> to package it as the default office suite yet.'
>> Whoever removed it from the main tree has completely ignored this and
>> decided to ship an incomplete office suite to users for the own
>> convenience.
> FWIW, I agree that it's premature, but it's not Gentoo's problem so much
> as KDE's and Qt Software's, as both kde3 and qt3 are unsupported upstream,
> thus, subject to security vulns, getting increasingly difficult to
> maintain in the face of continuing system updates, etc.  Why KDE refuses
> to support the previous stable version until the new version is generally
> stable as well, I don't know, but they don't.  (Qt I can see a bit more,
> as they're a commercial company, now part of Nokia, and supporting older
> versions costs real money.  It wasn't their fault that kde decided to go
> for a full rewrite instead of a straight upgrade port, /then/ do the
> rewrite when they have an existing stable kde based on a qt that's going
> to be supported for awhile.)

You're right that KDE's attitude is even worse - the choice of version
numbering being only the start.  I just don't think the Gentoo
position helps things, especially when the opposite tact could be
taken; provide KDE4 in an overlay for those who want to try it and
maintain KDE 3 in the main tree.  After all, they wouldn't be alone as
Debian is also maintaining it in stable.  Instead, we are faced with a
blanket mask out of the blue and the 'upgrade -- it's so much better'

I also approach this not so much for myself (I only use the odd KDE
app and not the desktop environment itself; I find even 3.5 too
bloated) but for other less tech-savvy users who just want to go about
their day-to-day tasks on the computer.  For them, everything works
fine wtih 3.5.  Why do they need to change?  It gets worse when you
then install a few KDE 4 apps and see sporadic crashes and heavy CPU
utilisation.  I used to find khexedit a useful tool for debugging data
files when coding.  In 4, there is a complete rewrite called okteta
with no apparent additional functionality but which uses 100% CPU as
soon as it loads up and is basically unusable.  And that's with 4.4 on

I don't really put Qt in the same boat.  Qt4 has been around for quite
a while longer than the equivalent KDE release (because of this huge
rewrite they decided to do) and I'd be happy to ditch it for the
superior 4 release if it wasn't for the loss of all those usable KDE
applications.  If you compare the switch from Gtk+1 to Gtk+2, it was
also painful but developers tended to do the minimum required to get
their code building (making use of the deprecated symbols still
available) rather than throw it all away and do a complete rewrite.  I
don't remember anything like this KDE upgrade with GNOME.

> FWIW, I've been quite pleased with kde 4.4.  The upgrade from 3.x is still
> likely to be a big nightmare for many, as so many things have changed and
> there's some areas that other non-kde-core solutions will have to be used
> instead, but that's to be expected with an upgrade of that size. I had
> predicted with early 4.3 that based on evident rate of progress, 4.3 was
> the first one I could in good conscience call late beta quality, and 4.4
> should be rc quality with 4.5 hopefully finally reaching release quality.
> 4.4 has certainly met at least that prediction, here, and to my very
> pleasant surprise, exceeded it to the point where I'm very nearly ready to
> call it full release quality, the only things keeping me from doing so is
> that I don't have all of kde installed, and haven't tested in 4.4 all of
> what I do have installed, and the caution from having been burned so many
> times previously by kde4.  But kde's official position was that 4.2 was
> ready for normal users, and that was terribly sad, because all it did was
> demonstrate how terribly out of touch with reality they were.

I haven't used it as an environment much.  I've seen it running on a
Debian testing box and to me, it just seems much the same with lots
more flashy gimmicks that slow the machine down.  Of most
disappointment is the decision to copy Windows with the K button, a
change I immediately reverted.

The applications are a mixed bunch.  Some are close to being Qt4 ports
of the originals with some improvements.  Others are just a joke.

> Well, there's still one bug that could be a show-stopper.  konqueror (and
> all of KDE) SSL and certificate support and management isn't yet up to
> what I'd call normal usable standards (it works in general, but the cert
> management familiar to kde3 users is missing, with the result being that
> it's broken on some sites with more exotic certificates -- good SSL and
> certificate management is absolutely critical in this day and age when
> many banking transactions and purchases are via web browser!).  But
> realistically, konqueror as a web browser is falling behind and looking to
> be replaced by the webkit based rekonq browser after it matures a bit
> more, enough so that few people use konqueror as their main browser any
> more anyway, with chrome/chromium and firefox/iceweasel/icecat being the
> major browsers picking up from konqueror, so this isn't the blocker it
> could have been as there's honestly not that many people, even among kde
> devs I gather, using konqueror as their primary browser anyway.  But that
> same support is used in a few other areas in kde as well, and it continues
> to be problematic there.

Yeah I wouldn't recommend Konqueror to anyone.  It had little use with
3.5 because it was unusable with so many sites, so I haven't even
really tried the KDE 4 version.  khtml has succeeded in being the
basis for WebKit, so they may as well just use that directly rather
than trying to continue developing a separate browser.  Qt even
includes a webkit binding and I assume they are using that to some
extent.  At least, building 4.4 required it.

> Then of course as you mentioned, there's koffice.  Just as it's really not
> qt's fault that kde took so long to stabilize on a reasonably current
> version, it's not so much kde-core's fault that koffice isn't yet properly
> stable on kde4.

koffice is the main issue with the one of the other users I mentioned
earlier.  She uses kword just fine with 1.6.3.  There's no particular
reason to try and use 2.2, and the website explicitly puts you off the
idea.  If only they'd made that more clear by calling it 2.0 beta or
something.  Gentoo seem to have taken the availability of some version
of KOffice that builds against Qt4 as a reason to dump the old
versions.  It seems to me that they don't actually use said
applications and just want a reason to get rid of the old

> The same applies to other apps built on kde, such as k3b, possibly amarok
> (which was bad enough, especially for amd64 users, that I got fed up and
> switched to something else, thus the "possibly" as I don't know current
> status), kaffeine, etc.  But the k3b live version (ebuild available in the
> kde overlay) is actually quite good, as I mentioned I gave up on amarok as
> it never was a real good fit for me, and I found the very good qt4 based
> smplayer to replace kaffeine, so the status on those isn't too bad.  But
> koffice... that remains a legitimate blocker, for those dependent on it
> for their workflow.

The new amarok was the first part of KDE 4 I tried, and probably still
takes the crown as the worst.  They seem to have dumped everything
good about it, including MusicBrainz support.  Strangely enough, users
aren't that excited by knowing an application builds against Qt4 --
that's pretty meaningless.  What they generally want is something that
works and a few new features are a bonus.

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

Thanks again for maintaining the overlay,
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (

Support Free Java!
Contribute to GNU Classpath and the OpenJDK

PGP Key: 94EFD9D8 (
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

Re: kde-sunset: Calling base_src_prepare from kde.eclass
-- Duncan
kde-sunset: Calling base_src_prepare from kde.eclass
-- Ladislav Laska
Re: kde-sunset: Calling base_src_prepare from kde.eclass
-- Martin von Gagern
Re: kde-sunset: Calling base_src_prepare from kde.eclass
-- Ladislav Laska
Re: kde-sunset: Calling base_src_prepare from kde.eclass
-- Chris Bandy
Re: kde-sunset: Calling base_src_prepare from kde.eclass
-- Martin von Gagern
Re: kde-sunset: Calling base_src_prepare from kde.eclass
-- Chris Bandy
Re: kde-sunset: Calling base_src_prepare from kde.eclass
-- Andrew John Hughes
Re: kde-sunset: Calling base_src_prepare from kde.eclass
-- Duncan
Lists: gentoo-desktop: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: kde-sunset: Calling base_src_prepare from kde.eclass
Next by thread:
Re: kde-sunset: Calling base_src_prepare from kde.eclass
Previous by date:
Re: kde-sunset: Calling base_src_prepare from kde.eclass
Next by date:
kopete-3.5.10-r5 from kde-sunset won't compile.

Updated Jun 28, 2012

Summary: Archive of the gentoo-desktop mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.