A little review of kdecore & kdeui

[Frans Englich]

On Wednesday 05 April 2006 21:32, Thiago Macieira wrote:
> David Faure wrote:
> >Not until we see the actual proposal - did you forget to attach it? ;)
>
> How could you tell? :-P

Hehe, the mail was one long drum roll :)

Quoting the attachments:

> KCmdLineArgs

A candidate for Qt rollback? It's something at least I have been very annoyed 
at missing, when writing Qt-only stuff. I would perhaps rename it to 
QProgramArguments, instead of all those short forms. (Is it worth a rename 
from KCmdLineArgs to KProgramArguments, in case it doesn't end up in Qt?)

> KDateTime -> can it be replaced with QDate/Time with extended range?

Not fully: time zones and offsets are missing in QDate/QTime. However, some 
usages can be converted to QDate/QTime when QDate has been extended. If 
QDate/QTime also received zone offset(which doesn't require a whole timezone 
framework) even more cases can be converted. If QDate/QTime had zone offsets, 
you could handle the W3C XML Schema types, increasingly used in databases.

KDateTime also needs the extended range in QDate.

> KStaticDeleter (Q_GLOBAL_STATIC?)

Many of Qt's macros are very useful, but they lack documentation. If KDE 
should use macros like that(Q_DISABLE_COPY, etc) on a more general basis, I 
think they should "officially" be part of Qt's public API and be documented.

> to kcontrol library
> ===================
> KCModule

See my other mail in this thread.

> Other stuff:

A mere suggestion: I would like to see a one-to-one mapping between file names 
and class names. For example, that KStatusBar class resides in KStatusBar.h. 
It would resemble Qt, and I think it has many advantages such as that it 
makes it easier to use. It is less confusing on where to find what(which C++ 
already has enough of). KDOM and KOffice(right? or parts of it?) has it like 
that.

It would mean a lot of work, but that's another issue :)


Cheers,
		Frans