| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Drawing nows happens directly when the Dialog or Widget draw methods are
called. This makes it easy to debug why a particular low level draw
method was called, by inspecting the call stack.
This replaces the notion of "buffering" by two independant ways to
control what is drawn and where:
- The active layer is used to select whether the foreground or
background part of the dialogs are rendered by the draw calls.
- The active surface is used to select if the draw calls affect the back
buffer or the screen.
The foreground layer of the active dialog is drawn directly to the
screen. Its background layer is drawn to the back buffer. This way
widgets can restore the back buffer in order to update without having to
redraw the dialog's background.
Dialogs lower in the dialog stack are drawn entirely to the back buffer.
|
|
|
|
Comments explain how the num lock handling works before the
fall-through cases.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This was another inconsistency between changing the widget by
clicking and changing it with the mouse wheel. Hopefully the last
one, though.
|
|
This is consistent with the notification when the widget changes by
clicking. As far as I can tell, that notification was added shortly
before mouse wheel handling was added. It missing from the mouse
wheel handler was presumably just an oversight.
|
|
Otherwise, it will look like the value hasn't changed until the
widget is redrawn for other reasons, e.g. by mouse-over.
Incidentally, does anyone know why handleMouseDown() calls
sendCommand() when the selection changes, while handleMouseWheel()
does not?
|
|
|
|
Some backends may break as I only compiled SDL
|
|
svn-id: r54266
|
|
Also renamed the source/header files, now they are more closely
aligned to how we rename most other source files
svn-id: r54264
|
