KDE's rough edges... what are your experiences?

[Duncan]

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?

Yes...

[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
> application-development?

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

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

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

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

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.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.