#8387 closed patch (wontfix)
GUI: New Slider Widget look and fixes
| Reported by: | salty-horse | Owned by: | fingolfin |
|---|---|---|---|
| Priority: | normal | Component: | GUI |
| Version: | Keywords: | ||
| Cc: | Game: |
Description
Included:
Graphic changes: 0) Redesign of the slider graphic, based on the original SCUMM widget.
Fixes: 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.
Improvements: 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.
Notes: 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)
Change History (4)
by , 20 years ago
| Attachment: | slider.patch added |
|---|
comment:1 by , 20 years ago
| Owner: | set to |
|---|---|
| Resolution: | → wontfix |
| Status: | new → closed |
comment:2 by , 20 years ago
comment:3 by , 6 years ago
| Component: | → GUI |
|---|
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 CVS.
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.