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

List:       kde-core-devel
Subject:    Re: KDE 1.89
From:       Harri Porten <porten () tu-harburg ! de>
Date:       1999-07-06 12:06:45
[Download RAW message or body]

Waldo Bastian wrote:
> 
> Are their important changes being planned for kdelibs?

Anyone remembers the "Cleanung up libraries" post from Mario ? I think
we have dealt with most of the addressed topics meanwhile. Here's what's
left (to my best knowledge):

> * kslider
> It's the same as QSlider, except it's only Windows style (according to
> docs), which only hurts styles and doubles the work to implement styles.
> Should be easy enough to remove.
> * kpanner (obsoleted by knewpanner)
> knewpanner already made it obsolete, but it's neither source nor binary
> compatible, so some applications may need rework.
> * kcombo
> QComboBox seems to be a complete replacement for this, but I did not check
> this so far.
> 
> There are some other classes which have similar or the same name as classes
> from Qt (of course with a "K" in front), and for some it's not really obvious
> when to use the class from Qt and when the KDE class. These classes include:
> * kmsgbox (QMessageBox)

Removed ?

> * ktabbar (QTabBar)
> * ktabctl (QTabDialog)
> * kbutton (QButton/QPushButton)
> * kcursor (QCursor)
> * knumspinbox (QSpinBox)
> 
> For these classes it would be nice to have a (short) README, explaing when to
> use these classes and when to use the Qt pendant. This is especially important
> for KMsgBox, it's still not clear to me when to use QMessageBox and when
> KMsgBox.
> 

> Would it be feasible to feature-freeze kdelibs in the
> first week of august?

I strongly agree with offering a first "snapshot" to the public soon to
attract new developers or let 1.1 app developers catch up. The word
"feature-freeze" sounds a bit too limiting in my ears, though. That
somehow suggests that feature richness of KDE 2.0 would already be
determined at that point. How about simply calling it alpha and saying
that the rough framework is set ? Major changes shouldn't be expected
anymore but if someone comes up with a very smart class later .... why
not include it ? ;)

Harri.

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