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

List:       kde-devel
Subject:    Re: KSlider bug
From:       Christian Esken <chris () wallace ! ping ! de>
Date:       1998-02-21 19:57:28
[Download RAW message or body]

On Mon, 16 Feb 1998 Bjarni Norddahl wrote:
>On Sun, 15 Feb 1998, Christian Esken wrote:
>
>> >Here's a simple program that illustrates it:
>> 
>> I now see the problem. You are right, every program shows this behaviour.
>> It seems the underlying QSlider widget has other ideas on the mapping
>> between mouse position and slider value than the derived KSlider widget.
>> So they get "out of sync" during dragging.
>> 
>> I don't see an easy solution without reimplementing every member function.
>> If anyone wants to try, feel free. Just make a note on kde-devel to avoid
>> duplicate work. I am giving up on this topic.
>
>I tried to have a quick look at it, but since I'm relativ new to this KDE
>projekt, I didn't locate where the bug is. Maybe you could explain me
>where it is, if you know it?

Approximately. KSlider is derived from QSlider. QSlider has a lot of element
functions: Such like buttonPressed() , buttonMoved(), paintSlider(), ...
I have overloaded some of these functions, especially the paint events which
change the look.
But I did *not* overload the mouse movement related member functions. So what
is happening? Something like:

The new "value" of the slider is calculated by the QSlider element functions,
whenever you drag around the slider. But the function calculating this must
take into account the look of QSlider. KSlider has other visual properties, so
the calculation of the "new value" (done by QSlider) is not appropiate for
KSlider. So we have a mismatch between internal state and visualization.

Easy solution: Unknown


Bye,
  Chris

-- 
Christian Esken                        (chris@wallace.free.de)
KDE Desktop environment                (esken@kde.org)

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