Opened 15 years ago

Closed 15 years ago

Last modified 12 months ago

#8387 closed patch (wontfix)

GUI: New Slider Widget look and fixes

Reported by: salty-horse Owned by: fingolfin
Priority: normal Component: GUI
Keywords: Cc:



Graphic changes:
0) Redesign of the slider graphic, based on the
original SCUMM widget.

1) Clicking and holding the mouse on the widget,
dragging outside of it, releasing the click, and then
moving the mouse back in used to behave as if the mouse
is still dragging.

2) Implemented the inline TODO item: When the mouse is
dragged outside the widget, the slider should snap back
to the old value.

3) The posToValue() behaviour didn't feel natural with
low-scale sliders (0-9 values, for example). Position
rounding was added. The overhead doesn't matter much
since sliders never appear in-game.

Items (1) and (2) are due to the handling of the
MouseLeft event.

4) unsigned int casts were used in drawWidget() and
posToValue to silence a warning. I do not believe this
coordinates could ever be negative. Perhaps the widget
width, coordinates and other class parameters/return
values should be declared unsigned (the labelWidth is
already uint).

5) In handleMouseLeft, ButtonWidget's handleMouse event
is called to handle hilighting. There, draw() is
called, and when we return to handleMouseLeft, draw()
is called once more to reflect the changes. I don't
think anything can/should be done about it.

Man-Machine Interface consulting provided by _sev.

Ticket imported from: #1092378. Ticket imported from: patches/492.

Attachments (1)

slider.patch (4.1 KB ) - added by salty-horse 15 years ago.

Download all attachments as: .zip

Change History (4)

by salty-horse, 15 years ago

Attachment: slider.patch added

comment:1 by fingolfin, 15 years ago

Owner: set to fingolfin
Resolution: wontfix
Status: newclosed

comment:2 by fingolfin, 15 years ago

Re 0): Personally, I prefer the look of our current slider over
this new look. To be frank, I actually think this alternate look
is rather ugly -- but that's just my personal taste, of course.
That said, it's not as if our current slider was beautiful,
either ;-).

Re 1): Proper fix for that is to ensure that the widget on which
a drag is being performed receives the mouse up event. Fixed in

Re 2): That TODO item is outdated -- I think it's not a good idea
to abort dragging when the mouse leaves the slider widget area,
because that makes it much harder for the user to perform a
proper drag: one small mismove of the mouse, and you have to
start over. So quite to the opposite, I think that the
slider/scroll bar should keep on moving even if the mouse leaves
them. The result is easier to handle for our users, and matches
most operating systems / GUIs out there.

Re 3): Hm, maybe the new code is better for low range scales, but
for the volume scalers, it apparently causes a lack of precision:
while with the old code, I can change the volume (range 0-256) in
steps of 3, with the new code, it's alternating between step
sizes 3 and 4. That's odd, I think.

Re 4): Hm, maybe. Width/height of an widget/dialog definitely
should be >= 0 all the time, so those could be changed to
unsigned. The position however may be negative, and sometimes is.

comment:3 by digitall, 12 months ago

Component: GUI
Note: See TracTickets for help on using tickets.