From kde-core-devel Fri Jul 23 14:52:38 1999 From: Richard Moore Date: Fri, 23 Jul 1999 14:52:38 +0000 To: kde-core-devel Subject: Re: RFC: kdeui/KSliderControl X-MARC-Message: https://marc.info/?l=kde-core-devel&m=93274598508001 "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