gfx/toolbar.h

The pieces, as the reference has them

A ToolbarItemFactory knows every item a toolbar may hold and which of them it starts with, and makes one on request. A Toolbar holds the items it was given in order, lays them out along its length -- separators, fixed spacers and flexible spacers that soak up whatever room is left -- and, when they do not fit, puts the ones past the end behind a chevron that opens them as a menu. A ToolbarItemPalette shows everything the factory can make, and items are dragged from it onto the toolbar, along the toolbar to reorder, and back onto it to remove. toString() and restoreFromString() carry the arrangement to a settings file and back.

Why the toolbar OWNS its items

Nothing else in this SDK owns its children; a plugin keeps its controls as members and adds them. A customisable toolbar cannot work that way: the user creates items by dragging them out of the palette and destroys them by dragging them back, so the items come from the factory and their lifetime is the toolbar's. That is also the reference's arrangement, and for the same reason.

Editing

While a toolbar is being customised its items must not DO anything -- a press on Save while rearranging is a drag, not a save. Each item gets a transparent handle laid over it that takes the mouse and starts the drag, so an item that is a slider or a combo box is rearranged the same way as a button, and none of them has to know what mode it is in.

The customisation dialog is an Overlay inside the editor, like everything modal here (alert.h says why). It leaves a hole over the toolbar itself -- not dimmed, and transparent to the mouse -- because the toolbar is where the palette's items are dropped.