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

List:       kde-core-devel
Subject:    Re: KSycoca::self() method
From:       David Faure <david () mandrakesoft ! com>
Date:       2000-05-31 13:16:00
[Download RAW message or body]

On Wed, May 31, 2000 at 08:32:11AM -0400, pbrown@redhat.com wrote:
> On Wed, 31 May 2000, David Faure wrote:
> 
> > > > should this be available in KGlobal?  It is sort of inconsistent.
> > > 
> > > I don't see why?
> > > 
> > > KGlobal is in kdecore while KSycoca is in kio (libksycoca) .
> > 
> > And the self pattern is used all over KDE. KTrader::self() is what is says,
> > KDirWatch::self() is what it says. Moving anything related to ksycoca
> > into kdecore is just nonsense.
> 
> Maybe you think so, you're the architect.  But imagine this scenario and
> continue to say I'm crazy.  I'm a programmer.  I'm never going to use the
> other esoteric stuff in KSycoca, all I'm interested in is updating my
> application if the system database stuff changes.  For this, I have to
> include a new header file, scan through the documentation in the header
> (how did I even find this header at all, and what does 'sycoca' mean??),
> and then do something like this:
> 
> connect(KSycoca::self(), SIGNAL(databaseChanged()), this,
> SLOT(slotDoSomethingNow()));
> 
> What I'm saying is that this was NON-INTUITIVE.  However, I am already (as
> a new KDE programmer) finding that there are many common things I need
> available via the KGlobal class, so I would have looked there first, and
> had I found this functionality, it would have saved me a bunch of time and
> effort. 

I think what you mean to say, then, isn't that KSycoca::self should
be in kdecore (this is nonsense as you certainly know), but that
the database change signal should be implemented as a KApplication signal
(like the other 'kipc' ones). And indeed it's really the same kind of things
(it's very comparable to color changes, font changes, settings changes etc.:
in all cases, the app has to 'update' itself to follow the change).

If that's what you mean, then I agree. KSycoca doesn't move at all, but
the databaseChanged signal becomes another KIPC signal.
Opinions ?

-- 
David FAURE
david@mandrakesoft.com, faure@kde.org
http://home.clara.net/faure/
KDE, Making The Future of Computing Available Today

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