KDE's rough edges... what are your experiences?
1i5t5.duncan at cox.net
Fri Nov 1 13:02:35 GMT 2013
Michael posted on Thu, 31 Oct 2013 11:45:04 +0100 as excerpted:
> Am Tue, 29 Oct 2013 14:35:29 +0000 (UTC)
> schrieb Duncan <1i5t5.duncan at cox.net>:
>> Michael posted on Tue, 29 Oct 2013 06:48:40 +0100 as excerpted:
>>> If KDE5 will have the same QA-style, I guess KDE will
>>> go into the history books of open source software, as always shiny
>>> but buggy to a degree that it may even be unusable.
>> Call me an optimist (heh, wrote that before noting your email address
>> =:^) if you will, but I believe the kdeers are on the right track
>> with this kde frameworks five stuff.
> That means you think with QT5 and KDE5 the overall bug- and
> maintenance-situation will improve?
[tl;dr summary, more modular-qt/kde-frameworks discussion]
>> Both the kde foundations and the qt it's based on are becoming a lot
>> more modular, with the ability for developers to pick and choose the
>> dependencies they want/need without having to bring in the whole big
>> currently monolithic qtlibs and kdelibs.
> How I see it, that would only help to get the issue-list down for
> people NOT using the full-stack of KDE.
It tightens down the scope. Individual modules are smaller both in code
and in authors. Less code means less bugs.
At the same time, more projects that would have previously ruled out
using that library due to the cost of pulling in the whole ecosystem will
likely find the now lower cost of pulling in just the module they need
rather more palatable.
More application users and more application developer's and advanced
user's eyes looking at a smaller pile of code... should mean faster and
more in depth bug finding and fixing.
>> Qt itself is maturing as a developer-community-based toolkit in its
>> own right, and qt5 is far more community-driven than any qt ever
>> before in history.
> More community-driven as non-qt frameworks as well, or at least on par
> with them? And regarding the issues discussed in this thread, I don't
> see a necessary benefit from the possibly higher factor of
> community-drivenness there too. And I doubt the issues I have in mind
> here are QT-issues.
When qt was driven by trolltech and then nokia, it was corporate
controlled, and certain changes that might have made sense from a library
and code perspective would not be accepted because they conflicted with
where the corporation intended to take its product. It was sort of like
closed source, you can't fix it as it's not in your control so you
develop your own workarounds. It wasn't near as bad as closed source
because the source was open so people could see what the code was
actually doing without reverse-engineering it and could submit proposed
patches, but whether those patches would be taken or not...
>From the various mostly kde devs blogs I've read, but supported by the
razor-qt and lxde moves as well, that's gone and qt is fully community
driven and community transparent now. It's far easier for kde to move
former kdelibs functionality down into qt where it makes sense, yet
because of the increased modularity, doing so doesn't bloat qt as a
whole, because to a large extent the code is going into optional qt
modules, not into qt-core where it'd be forced on every qt user,
regardless of need.
Meanwhile, kdelibs is itself becoming smaller as bits of it break off
into optional kde libs or into various qt modules.
The bigger picture is one of the entire ecosystem going more modular,
with higher level users now able to interact far more directly with their
now narrower scope lower level dependencies, meaning the whole stack is
more transparent and what were kdelibs or kde-category-libs level
workarounds to qt level bugs in the kde4/qt4 and even more the kde3/qt3
era, now can be fixed directly in the qt module with the bug by the
developer experiencing the bug themselves (of course providing they're a
qt dev too, but it's a community and that's open to them now). And the
same at the kde frameworks level as kdelibs breaks into a framework of
libs, some higher level some lower, with some functionality transferred
to qt and thus not kde level at all any longer.
That problem I mentioned with khotkeys4 that ultimately traced to qt4 not
having proper multikey support? Based on comments I've read, qt5 doesn't
have that problem, in part because the kde developers who suffered with
it in qt4 made very sure qt5 did it right.
Entire qt4 era workarounds in kdelibs and above are now being chopped
from the qt5/kde-frameworks-5 code, because the problems can and are
being fixed directly in qt5 now, so the workarounds are simply no longer
necessary. Both directly less bugs and less workarounds as a result, and
indirectly, slicing whole layers of workaround code out as a result,
meaning any bugs in THAT code are now gone!
> Off-Topic (writing style): Both paragraphs repetition over repetition of
> former statements with only small amounts of new arguments. Do you see
> that now in retrospect?
Part of that is inherited. My dad's a teacher, and one technique
teachers use is stating and restating the same thing in different ways
and from different perspectives, so that ideally it'll eventually soak in.
Now as a student I'd often skip quite a bit of the daily "make work"
stuff designed to drive a principle home, and would /still/ typically
score high enough that in on-the-curve tests I was often setting the
upper end of that curve. But others /needed/ that repetition or the
material simply wouldn't sink in.
Perhaps its those people who get the most benefit from my posts, which
explain for the first time in language and concepts (and repetition) they
can understand, the basics of some concept or other...
Those who don't need it... can skim or skip, much as I did back in school
myself. I've already said I appreciate the killfile, and don't mind
people making use of it on me, if indeed they don't find my posts useful.
>> Up the stack at the application level, kde5 is breaking up and
>> shipping most individual apps with their own version tagging and
>> release timing, so apps that are evolving fast can ship updates every
>> month or even every week if they wish, while already mature apps in
>> primarily maintenance mode might ship an update a year, mostly just
>> to keep them building on current libraries with current tools, with
>> the occasional security update as well when necessary.
> With QT4 / KDE4, could applications not just build against maybe older
> qt- / kdelibs which would then not prevent fast-paced
For the version-synced releases that isn't in general supported. While
many apps and some libs didn't have a single code change in especially
the monthly bugfix-only micro-releases and sometimes in the semi-yearly
feature releases as well, (re)building against the version-synced kdelibs
and other lower level dependencies was assumed, and failing to do so
would sometimes trigger interesting bugs. (Gentooers tend to have more
personal experience than most with these sorts of bugs, since gentoo is a
rolling release distro and actually running a version of an app or higher
level library on a changed version lower level library is not only
possible but done routinely, and there are in fact automated tools such
as gentoo's revdep-rebuild to help spot and fix via rebuild such
I remember the update I did, back when I was still running konqueror as
my primary browser, when it broke after updating kdelibs, until the
rather later in the build process libkonqueror and then konqueror itself
was rebuilt. Most of the time I continue to run kde during the upgrade
but don't try to restart it, as I know some bits likely won't work until
the upgrade is completed. In this particular case, however, the old
konqueror wouldn't run on the new libraries, so I was left without a
(primary) browser until konqueror itself was upgraded too.
The independent kde-based apps such as amarok and k3b do allow this in
general, but there are both code level workarounds to manage it and
occasional bugs it triggers even then.
Which is where the whole independent release cycles thing gets
interesting. It can be made to work in general and in fact that's how
library upgrades are handled normally, but there are certainly other
compromises necessary in ordered to do so. (Generally, an upper level
depender will state a lower level dependency minimum version requirement,
and lower level libs maintain their old interfaces within a major
version, only dropping them at major version bump time, and only adding
new interfaces but not changing the exposed older interface for minor
version bumps.) But those sorts of compromises and bugs tend to be
reasonably well understood and the community is already used to dealing
with them, since they deal with them in the independent library case all
the time, so I believe overall it'll still be an improvement over the
> Right, there *is*! No idea why the new "de-coupling style" benefits
> such projects. BUT ignore the question you might see here, as it will
> go in a direction which is out of the scope of this thread. Really,
> don't answer the question, ignore it.
If you say so... =:^)
>> The effect should be that individual kde apps will be chosen on their
>> merits, no longer simply because they're part of kde, and people
>> doing what I'm effectively already doing here, mixing a few kde apps
>> with a few gtk apps with a few independent apps, picking the app in
>> each case that best fits their needs, will become much more common.
> I really don't see *any* important change there. As all sensible users
> already know that they can mix applications today. There was never an
> issue with that. And no one I know would suggest otherwise. I use
> K3b and Amarok for years now on all DEs. The only benefit I see would
> be a possibly smaller dependency impact, slightly less used
> harddisk-space, which isn't a big problem these days anyway and wasn't
> for a long time.
I believe you're underestimating the impact. I've seen a lot of folks
say they like k3b, for instance, but won't install it because it'd be the
only kde (and sometimes only qt) app on their system, and they refuse to
pull in the whole heavy set of kde deps including qt and kdelibs, just to
And even that underestimates things as there's a lot of people that see
that it's a kde app or take a look at what it would pull in, and cross it
off their list as too expensive, without ever having tried it.
Of course on build-from-sources distros such as gentoo, that effect is
amplified many times, as every dependency pulled in is likely to be
upgraded and rebuilt many times over the period it's a dependency, and
that's a real cost, not the trivial install and forget cost it is on
binary distros. (I look at it as significant encouragement to do what
the security folk already say is best practice, only install what you're
going to use, and if you're not going to use it regularly, consider
As an example from the flip/gnome side, I do have some gtk2 apps (pan,
firefox and now claws-mail being the big ones) installed, but when I
decided kmail2 with its akonadi deps and bugs was no longer the right
choice for me, I looked at and immediately crossed off several email app
choices (IIRC balsa was one of two, IDR the other, evolution was off the
list already since it uses the same database style solution I was leaving
the akonadified kmail to get away from, tho arguably evolution is more
mature so it should actually /work/ there) simply because of the gnome
related deps they'd pull in, that no how, no way, was I willing to do.
Fortunately I found claws-mail, which turned out to be about the perfect
match for my needs, without all those inflated deps I didn't need =:^),
but there's several email apps that I otherwise would have at least done
more research on and might well have installed temporarily to play with,
if they hadn't wanted to pull in most of gnome in ordered to do so.
And that's on a full size/strength desktop. Then there's netbook level
machines (I have one) and even embedded, where non-volatile storage is
often single or double digit gigs and memory is at best a gig or two.
Big deps are a real luxury there, and while I do have kde on mine, I'd
definitely veto both gnome and kde on it (and it wouldn't even be a
practical choice on the smaller <10 gig non-volatile storage machines),
much more so than on my main machine.
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.
More info: http://www.kde.org/faq.html.
More information about the kde