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.
