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

List:       kde-core-devel
Subject:    Re: Standard dialog margins.
From:       Mosfet <mosfet () jorsm ! com>
Date:       1999-08-25 22:37:03
[Download RAW message or body]

We are talking about 10 items so far... If we get a ton of methods I can see
splitting things up based on functionality, but not based on if something is
loaded from KConfig or not. As to if we should take UI specific methods,
encapsulate them in a class, and have it accessed through KGlobal, that's up to
you all I guess. It does seem funny to me to do that for just 4 methods tho. 

On Wed, 25 Aug 1999, Sirtaj Singh Kang wrote:
> On Wed, 25 Aug 1999, Mosfet wrote:
> 
> > What is the problem with the loading of variables to get the inital
> > value? Is it just a style preference? My main objection to splitting the
> > classes is that we will end up with two different classes with very few
> > methods and similar function... I think it is a inconvenience to the app
> > developer to be doing this based solely on if the values are read from
> > KConfig or done via a new allocation of another object (which is
> > probably reading KConfig anyways).  KGlobal is for global variables,
> > period, IMHO of course ;-)
> 
> KGlobal was born due to the same problem with KApplication becoming a
> dumping ground for dozens of otherwise unrelated variabless. I'd hate to
> see that happen to KGlobal too! The idea is to group variables as much as
> possible and use KGlobal to access the _groups_ rather than the
> variables/constants directly. Believe me, adding one or two globals every
> now and then adds up, and before you know it KGlobal will become as messy
> as KApplication.
> 
> -Taj.
> 
> Sirtaj S. Kang       taj@kde.org         ssk@physics.unimelb.edu.au
> Univ of Melbourne	The "gui" in "Penguin" is pronounced "K-D-E"
-- 
Daniel M. Duley - Unix developer & sys admin.
mosfet@mandrakesoft.com
mosfet@kde.org
mosfet@jorsm.com

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