Re: KDE is now broken (Fwd: Heads-up: KDE4 hitting testing tonight (UTC) )
On Wed, May 27, 2009 at 12:10:54PM -0500, Boyd Stephen Smith Jr. wrote:
> >It's
> >something hidden from the user instead of telling them about
> >it. That's never a good idea.
>
> Actually, according to actual HCI studies it is often better to hide things
> from a user instead of telling them about it.
What means "better" in that case?
> Now, once the user starts
> looking for that setting, it should be available, but too many settings and
> too much explanatory text confuses rather than enlightens.
Whatever you do, there's nothing that helps against stupidity.
> >> >> These same issues can be hidden when using RDBMS backed, but the
> >> >> translations are usually much faster.
> >> >Both of these won't be human readable, plain text files.
> >> Actually, yes. KDE Configuration files are human-readable, plain-text
> >> files. They aren't free-form prose. For the most part they follow the
> >> ".desktop" file specification put together by XDG.
> >If you have to make so many "translations" of a configuration file
> >that nowadays' computers run into performance problems when doing so,
> >I don't consider the file as a human readable configuration file
> >anymore.
>
> I never said the translations were causing performance issues. I
> said they'd be faster with an SQL backend. That is definitely *not*
> the reason Akonadi wants an SQL backend.
Then it's irrelevant that translations can be "usually much faster"
when an RDBMS is used.
> They are quite readable. Usually a translation is just changing the
> name/spelling of a key. But, it might be converting a value that is a list
> into multiple stanzas or something like that. Generally, they leave the
> values alone, but they are the migration path from 'old' configuration files
> to 'new' configuration files.
So these translations need to be done only once?
> >> >Try to read
> >> >your current kde configuration in 35 years, or try to read your data
> >> >from the the RDBMS you're currently using in 35 years. You'll find
> >> >that it won't be easy.
> >> I hope so. I plan on using different, hopefully better, software by
> >> then.
> >And what if you need the information stored in it?
>
> I won't. I'll export the data as I abandon that software. Actually, I'll
> export the data before I abandon the software so I can import it into the
> new software and test it.
That is a possibility, but it requires to plan for it and to work on
it, and mistakes can be made. It would be easier if that wasn't
required.
Reply to: