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

List:       kde-core-devel
Subject:    Re: todo before KDE3?
From:       Holger Freyther <freyther () gmx ! net>
Date:       2002-01-21 15:42:26
[Download RAW message or body]

Am Montag, 21. Januar 2002 16:36 schrieb David Faure:
> On Monday 21 January 2002 16:09, Holger Freyther wrote:
> > Hi all,
> > I had a quick look at kdelibs/kdecore, kdeui and kded and some issues I
>
> would
>
> > like to talk about.
> > One general item is on my list is what is if we've a *Private defined but
> > have private members not in the Private class? Should we move them to the
> > Private class?
>
> Generally, if there's no chance that such members will ever be removed or
> changed, there's no point (it makes accessing them slightly slower, and
> prevents inline methods). Moving them to the private class makes only sense
> if there's no inline method for them, if they're not accessed 10000 times a
> second, and if they have any chance of being removed at some point.
>
ok
> > This applies to kinstance.
>
> I really don't think we're going to remove any of those member variables -
> they are directly related to the KInstance API.
>
> [snip KNotifyClient, glad someone's looking at it ;)]
>
> > krfcdate: we return t_time which is ok but couldn't return QDateTime?
>
> It's not too hard to go from one to the other, so I don't know.
> (although if we can avoid doing many calculations just to go
> time_t -> QDateTime -> time_t, we might as well ;)
>
???
> > kapplication: first of all frerich do you want to fix any stuff after
> > kde2.0
> >
> > :). Isn't it the right time to fix it?
> :
> :)
> :
> > Then there's a lack of api documentation int kdeInitExec( ) what is the
> > int?
>
> Which one ? The return value is documented. You mean int* pid ? Well, it
> returns the PID of the process that was started (on success).
hmmm. Did the docu somehow sneaked in? I think I'm reffering to a differen 
file...
>
> > Why don't remove KStyle *style()?
>
> We probably should, I've seen KStyle has been removed ;)
>
> > Then I've my issue with invokeMailer. I don't argue having two but having
> > three where two would be really enough? Just delete invokeMailer(const
> > QString &addres, subject ) and make it like this:
> > void invokeMailer( const QString &to, const QString &subject, const
> > QString &cc = QString::null, and so on ). I need to admit I don't know
> > how much code this will break.
>
> That's why I didn't dare removing it.
>
> > KAboutContributor isn't kde conform it uses names methods like get*. it
>
> seems
>
> > like it is only used internally but in a public header. Either we make it
> > name()... or move it to a private header
>
> !? Where's that ?
it's in kaboutdialog.h

Holger

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