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

List:       kde-core-devel
Subject:    Re: kdebase/khelpcenter/kwelcome
From:       Stephan Kulow <coolo () kde ! org>
Date:       2000-05-02 17:22:49
[Download RAW message or body]

pbrown@redhat.com wrote:
> 
> On Tue, 2 May 2000, Stephan Kulow wrote:
> 
> > Why? KGlobal access the current instance and either the app is a kapp,
> > then it's exactly the one it wants to write to (kapp->config()) or the
> > app is not a kapp, then it's kpart and it should access the config
> > through it's instance pointer. KGlobal::config() should be used
> > (almost only) by kdelibs code for example.
> 
> Well then I got it backwards.  But there was a huge mix (seemingly
> random) that was born out of the confusion of the birth of KGlobal, and
> many apps used KGlobal::config() and kapp->config() intechangeably.  If
> kapp->config() is preferred, it should be documented as such, and a global
> search/replace on kdebase needs to be made.
> 
Well... - let me start this way, it helps thinking :)

In the beginning KGlobal:: was the "we make KApplication smaller in
putting
all the stuff it doesn't belong there to something else" namespace. We
made
KApplication::config() a call to KGlobal::config to not having to edit
tons
of files. Then your changes would have been valid.

Then kparts came and KInstance became the new "KApplication light". Then
we 
moved some parts out of KGlobal to KInstance that were meant to live in
one
address room. Then KApplication::config() was a logical reincarnation of
KInstance::config() - but with a slightly different meaning as in 1.X.
KGlobal::config() in return was there to make other code easier than
we've
just ported to use it ;-)

All in all, you're both right and wrong. Not kapp->config() should be
removed
but kapp should point to KGlobal::instance() instead of
KApplication::getKApplication

Greetings, Stephan

-- 
... but you ain't had mine

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