A little review of kdecore & kdeui
frans.englich at telia.com
Thu Apr 6 16:02:44 BST 2006
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:
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
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
It would mean a lot of work, but that's another issue :)
More information about the kde-core-devel