reassigning to daniel. can be delegated to someone else but not to phillip. important bug. please fix.

Assigning this to default assignee because mbi-bug-manager is not a person and cannot evaluate/reassign this bug. Would you please assign it to the correct product/component and estimate whether it is relevant for the 1.0 release? Thank you.

In the search for the bug, we discovered:

In the constructor

setMouseTracking(true)

enables sending of mouseMoveEvent of QT even when no button is pressed.

But for the upper side it is not working; For the upper 30 pixels of the QmitkSliderLevelWIndowWidget no mouseMoveEvent is sent from QT at all.

However when clicking in a region under the 30 pixels and moving the upper bound (by dragging with the mouse) of the levelwindow, all mouseMoveEvents are sent as regular intended by QT.

news:

when moving the bar into the center and then dragging the upper side to the topmost corner, everything is fine.

For catching the mouse event in the upper region of the levelWindowWidget the enterEvent was reimplemented. The position of the cursor is calculated by converting the global position to the local coordinates of the widget. With this position the mouseMoveEvent is called manually.

A new feature: the slider lenght can be changed in any position above and below the slider and not only in a defined small region as done before.

Because the LevelWindowWidget was implemented long time ago it should be redesigned some day. For example a spanSlider can be used instead of painting a slider in the paintEvent (s. T5245).

[SVN revision 25794]
FIX (#2188): reimplemented enterEvent to reactivate the str-drag on the upper side of the levelWindowWidget.

What's the status of this bug? sounds as if it's ready to be closed