KDE Quality (problems)

[Duncan]

John Longer posted on Fri, 15 Apr 2011 17:43:39 +0100 as excerpted:

> Interesting comments on this thread. I have recently moved to suse 11.4
> which runs KDE 4.6.0. Only a few problems in KDE really. Slow response
> at times. I've put that down to the file indexing feature and disabled
> it. Seems to have worked. Machine is also running ext4 which I haven't
> delved into but from brief info - why is this in kde? Probably because
> some one some where thought wow I would love to do that. Understandable
> really, The dog thing in 3.x was much worst.

Why is /this/ in kde?  By "this" I assume you're referring to the indexer, 
not ext4 (which is a Linux not kde filesystem, as I guess you well know), 
but I had to stop and reparse to get that, as ext4 was what I first took 
"this" to refer to, but that didn't make sense.

To be fair, the whole semantic desktop thing (including the indexer) isn't 
yet at the stage they want it.  4.5 and 4.6 are starting to get closer, 
but aren't there, yet.  Way back in the 4.4 era (so a year ago), I saw 
discussion hoping it'd be finally close to what they want by 4.7 or so.  I 
don't know if that still stands or not, but it /is/ getting closer.


However, from a more global perspective, I've concluded after some thought 
and experience, that this whole "semantic desktop" thing really isn't 
targeted at people already comfortable with their computers anyway, but 
rather, at those who struggle with them, finding the desktop and directory 
analogies, among others, unintuitive and far more difficult to work with 
than their real-life physical counterparts.

People comfortable with the computer-conventional nested-directory 
structure really don't need tagging, indexing, etc, as they tend to 
remember more or less where they put their files and can retrieve them 
with little effort.  Instead, they find all this "needless" file indexing 
mostly a waste of resources, taking memory, slowing down computer access 
at the wrong time, etc.  They might find it nice to do all the fancy stuff 
the semantic desktop is supposed to allow, eventually if not now, but 
aren't willing to pay the cost in resources taken, because they "grok" the 
current system and have little trouble going nearly directly to what they 
want in any case.  In the event that they can't immediately find it, they 
can at least narrow down the list so a real-time grep of a specific 
directory is possible and in fact, quite reasonable, and are comfortable 
using grep or similar tools in exactly that manner.

But it's not for these people that the semantic desktop is created.  The 
semantic desktop, instead, is targetted at those folks who have 200 icons 
on their desktop, because it never occurs to them to put anything 
elsewhere, and if they do, they can't find the file they just told the 
system where to put, to be able to use it!

I'm not one of these people, and from your post, it appears you're not one 
either, and we tend to be at a loss to understand how these folks can't 
get it.  Never-the-less, I think we've all seen the phenomenon, to some 
degree or other, however much we're at a loss to explain it.  As such, I'm 
not /absolutely/ sure and I don't believe the semantic desktop folks are 
either, that this is exactly the right approach for such people.  But it 
/does/ seem to be more effective for them than the typical nested 
directory tree that works so well for us, to the point that we get 
exasperated at seeing the flat structure with everything at one or at most 
two levels, that these guys seem to like.

I've never used gmail, but from what I've read, it's arguably the first 
really popular (to the point it became part of a generation's cultural 
database) application of this idea.  One huge massive flat inbox, no 
subdirs, but oh, the messages can be TAGGED!  And they can't simply be 
tagged with ONE thing at a time (what nested subdirs effectively forces, 
at least if symlinks/hardlinks aren't used to create references from 
multiple locations to the same thing), but with a half-dozen or a dozen 
different things, whatever makes sense to the user.  Then the user can 
search by tag, instead of by subdir.

Hey, it works for gmail, and gmail's pretty popular, so they must be 
doing /something/ right!

But us tech types tend to find such flat structures on the one hand, but 
highly complexly overlinked and interlinked on the other, exasperating.  
It really is a different way of looking at things, but the popularity of 
solutions such as gmail suggest that it's one that resonates with the 
general populace, arguably rather more so than the highly nested 
structures us geeks tend to like.  For us, yeah, it may be nice to have 
the extra ways of accessing the data, and on an independently hosted 
system like gmail, we may even find the flat structure tolerable given the 
flexibility of the access allowed in trade.  But on our own systems, where 
we're controlling the resources and actually see the tradeoffs made there, 
what's arguably tolerable on gmail when it's someone else's resources, is 
simply not worth the high cost in resources, when it's our own.

But again, that's because we're actually comfortable with the conventional 
highly nested structures that computers have traditionally used, and have 
no problem working with them.  As such, the tradeoff is seen as far more 
expensive from our viewpoint, than it is from the viewpoint of someone who 
never understood and only tolerated the deep-nested structure because it 
was the only option computers had available.  These folks are willing to 
pay a lot more in terms of resources, for a more natural to them way of 
interfacing with the computer.  And they're far less aware of the 
resources they DO pay, they only know them in terms of "it's slow" or 
"it's fast", and systems are now "fast enough" that the extra coule 
seconds of delay accessing something because the computer's busy indexing 
at the same time, doesn't particularly matter to them.

Having come to that realization, I'm now reasonably comfortable turning 
off most of the fancy semantic desktop features, knowing I'm not losing 
that much I really value anyway, since in trade I get a more responsive 
and less buggy system.  At the same time, I realize the very real value 
all this fancy semantic desktop stuff can have for users that were never 
comfortable with the nested directory structure and computer desktop 
metaphor in the first place, and see how they might find that same tradeoff 
a worthwhile one to make, because the value of the to them more natural 
metaphor is higher, to the point it's often worth the resource cost and 
then some.

> Worst problems are migrating data from my past set up on late 3.x. Mail
> import and bookmark import into konq do not work and have obviously only
> been trivially tested. I use folders of my inbox which may be the
> problem. Folders else where too. Address book - seems it may be possible
> but no obvious way to do it.

One good thing that can be said about the kdepim folks (those in charge of 
kmail and the address book) is that when they realized that their akonadi-
based rewrite wasn't ready, they didn't "call it stable and ship it 
anyway", as kde4 itself did (thus all the problems with early kde4), but 
decided to hold off until it /was/ ready.  In that regard, arguably they 
DID learn from the mistakes of the early kde4.

That's actually the situation we're in at the moment.  The current stable 
kmail and other parts of kdepim are basically frozen in their kde 4.4 
state, with only minimal updates, as the rewrite they intended to ship 
with 4.5 simply wasn't ready, and hasn't yet been ready in 4.6 either (tho 
I've read that the functionality itself is there, it's just the conversion 
scripts that as you point out are critical as well, that are still being 
debugged and polished)

I've repeatedly stated that 4.4 was IMO what should have been the 4.0 
release candidates, and the frozen state of kdepim at the 4.4 level really 
isn't an exception.  It was only with 4.5 that the rest of kde4 reached 
reasonably stability IMO, what /should/ have been the 4.0 release, so it's 
no surprise really, that the 4.4-frozen kdepim still has issues.

I /do/ hope that the wait is worth it and the conversion scripts as stable 
as they can possibly be. (if the old version could handle it, there's no 
reason the script shouldn't be able to handle it as well.  After all, they 
have access to the parsing code used by that old version!)  And seeing how 
long they've held back despite what's certainly immense pressure to ship, 
I actually have some hope that they ARE sticking to a "we'll ship it when 
it's ready, NOT BEFORE!" policy.

Regardless of how stable it actually turns out to be when it ships (and 
I've already stated my reasons for believing they're actually doing it 
right, this time, unlike the early kde4 fiasco), the new code is clean and 
modularized, free of the effects of the close to a decade of bandaids that 
have been applied to the current code.  As such, I expect that once the 
release does occur, it'll be like a dam breaking, and improvements will be 
fast and furious for several feature-releases after that.

So yeah, there's known issues of varying degrees of severity with the 
existing stable kdepim code, but part of the reason for the lack of 
progress there, is that they have new code that was planned to have 
shipped ~8 months ago, that they actually did the right thing with, and 
held back because they didn't believe it to be ready.  When they /do/ 
release, I really do expect and hope it's going to set a new standard of 
reliability for a conversion of this size, and as a result, go some way to 
restoring the reputation for great quality kde so terribly lost in the 
early kde4 era.

I hope I'm right! =:^)

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