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

List:       kde-core-devel
Subject:    Re: RFC: kdeui/KSliderControl
From:       Richard Moore <rich () ipso-facto ! freeserve ! co ! uk>
Date:       1999-07-23 14:52:38
[Download RAW message or body]



"Dirk A. Mueller" wrote:
> 
> Hi,
> 
> I've added KSliderControl to kdeui (HEAD). The initial idea for it came
> from Patrick Dowler, but I've modified it quite extensively. It now
> uses a QSpinBox and a QSlider and is therefore easier to use for the
> user than before. The interface hasn't much changed.
> 
> If you're looking for example applications that now use this class,
> look at
> 
> kdebase/kcontrol/input/kcminput
> kdebase/kcontrol/bell/kcmbell
> 
> for my personal opinion the spinbox is currently a bit too large.
> 
> but it can be used at very many places in almost every configuration
> dialog. It can replace most usages of KSlider and all usages of
> KIntLineEdit and still simplifying the code a bit.
> 
> Well, KSlider will die soon (replaced by QSlider), the problem is with
> KIntLineEdit/KFloatLineEdit. The first one is obsoleted by
> KSliderControl. Using an edit widget where a spinbox would be better
> is definitely a bad GUI design decision, so I'd like to remove that.
> 
> The only problem is KFloatLineEdit. Although it is afaik nowhere used
> up to now, it can handle double (although the class name says float)
> numbers, which KSliderControl currently can't. There comes request for
> comments:
> 
> should we
> a) remove KFloatLineEdit (nowhere used)

Yes, but only after (b)

> b) inherit KSliderControl to handle floats as well

Yes

> c) remove K*LineEdit && KSliderControl and replace it with a new class
> that has a better name, handles integers and float and has an optional
> QSlider? If yes, what name would be better than KSliderControl?

Yes, how about KNumberInput or KNumberEdit?

> 
> Anyway, it's imho a first step to clean up between the different
> implementation ideas that are currently used and put a easy to use but
> still powerful implementation into kdeui, thereby removing all the
> other code bloat.
> 
> Any comments welcome.

Can we make it so that it could be extended to support other formats
(for example hex and binary numbers as well).

Rich.

> 
> --
> Dirk A. Mueller

-- 
     Richard Moore		rich@ipso-facto.freeserve.co.uk
http://www.robocast.com/	richard@robocast.com
http://developer.kde.org/	rich@kde.org

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