DropdownButtonWidget is a button split in two parts vertically. Clicking
the left part triggers a default action. Clicking the right part shows a
list of other actions the user can choose from.
Using this widget on the launcher lets 'Mass add' be a secondary action
of the 'Add' button, removing the necessity of pressing the shift key to
access the feature.
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.
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?
Cameron Cawley
Bastien Bouclet
Jaromir Wysoglad
Eugene Sandulenko
Alexander Tkachev
Johannes Schickel
Torbjörn Andersson
strangerke
Ori Avtalion
Max Horn