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

List:       kde-core-devel
Subject:    Re: KDE 1.89
From:       "Dirk A. Mueller" <dmuell () gmx ! net>
Date:       1999-07-06 13:28:26
[Download RAW message or body]

Harri Porten <porten@tu-harburg.de> wrote:

>> * 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.

It can be removed, I think, although it is currently used at many
places in CVS.

But take a look at the applications that use them. IMHO there is a lack
of a widget that takes care of user-friendly manipulating an integer
value in configuration dialogs. There are different solutions floating
around, one of them is kslidercontrol (i.e. kdebase/kcontrol/bell), but
none of them is afaik standardized, nor are (imho) userfriendly enough.
Therefore Kslider should be replaced by a new KWidget instead.

I think of something like a combination of a QSlider and a QSpinBox,
that should be placed into kdeui and used everywhere to establish a
common look and feel, which is much more important than to slim kdelibs
down.

Is anybody already working on it? Any suggestions?

If nobody works on it already, I'd really like to write such a widget
class after my exams are over (two weeks, maybe earlier).

>> * kcombo
>> QComboBox seems to be a complete replacement for this, but I did not 
>> check this so far.

KCombo seems to be a workaround for an QComboBox bug?!

It isn't documented at all...

However it looks like it could be removed. it is only used in
KFileDialog, KFinger, KMid, KGhostview, KTimeMon and some Koffice
applications (and python bindings).

>> include: * kmsgbox (QMessageBox)
> Removed ?

afaik not yet. Imho it should be make compatible to QMessageBox and
only handle i18n itself (like your KWizard class).

>> * ktabbar (QTabBar)

it only provides left and right "scroll" buttons for QTabBars. The
source code could be cleaned up (why doesn't it inherit QTabBar?
would make it MUCH simpler).

Additionaly, it's only used in KIconedit and webmaker (which hasn't
been ported to HEAD yet).

>> * ktabctl (QTabDialog)

It emits a signal when the tab pages changes.

Well, these two can't be replaced that easily and iirc Qt doesn't
provide their functionality yet. However, they're currently only used
rarely, so we should think about either removing or polishing them
(they probably break styles support) and use them more regularly.

But, Qt's documentation quotes some style guides which say that the
usage of these two classes would be bad style anyway. Having read their
explanations I tend to agree.

>> * kcursor (QCursor)

This looks highly obsolete to me, as theme support is in Qt now (or am
I wrong?)

> I strongly agree with offering a first "snapshot" to the public soon
> to attract new developers or let 1.1 app developers catch up.

Imho we should get kdelibs api and functionality stable first. It won't
help us much if the app developers will try to overcome kdelibs bugs by
implementing workarounds into their apps or they would miss the new
sophisticated kde classes that aren't in kdelibs yet ;)


-- 
Dirk A. Mueller

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