[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: why kdelibs?
From:       Milian Wolff <mail () milianw ! de>
Date:       2010-10-28 13:17:31
Message-ID: 201010281517.34145.mail () milianw ! de
[Download RAW message or body]


Thomas Lübking, 28.10.2010:
> Am Thursday 28 October 2010 schrieb Milian Wolff:
> > KConfig (QSettings is horrible)
> > KShell helpers
> > K* ui widgets, most notably KUrlRequester
> > KJobs + ThreadWeaver
> 
> Maybe you could elaborate your preference of KConfig agains QSettings (i
> never saw one or the other as horrible... at least on straight forward
> "everyday" usage)

QSettings' implementation of groups is a joke:

settings.beginGroup("foobar");
// everything written now will be in that group
settings.setValue("myValue", ...);
settings.endGroup();

To read it:
settings.value("foobar/myValue");

I much prefer the KConfig way of doing this:
grp = settings->group("foobar");
grp->writeEntry("bar", ...);

To read it:
grp = settings->group("foobar");
grp->readentry("bar", ...);

Much more straight forward and easier for big applications (like KDevelop) 
with plugins. The plugin would just take some KConfigGroup ptr and save it's 
settings there, no need to come up with some unique name or anything, the 
parent app could handle that.

> ThreadWeaver about the QtConcurrent stack (QFuture,
> QThread/Pool)

ThreadWeaver is reliable and using KJobs is easy and straight forward.
The API is also really good to work with.
QtConcurrent has imo a strange custom api and I heard that it's not a good 
implementation from people that know a lot about concurrency.
 
> I don't say there're no strong advances - i just never hit some (on pretty
> limitted usage of both threading impls. tbf...) - and this would help out
> Chani ;-)
> 
> Thomas


-- 
Milian Wolff
mail@milianw.de
http://milianw.de

["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]