Vixen
dd8b0a81
csharp
public sealed class ToolbarPresenter

A strip of buttons, segmented groups and dropdowns over command ids.

No guide page documents this yet — the page shows what the code says about itself.

Remarks

The third view over the registry, and the one that shows why the registry is worth having: a toolbar is a list of ids, and every button's label, icon, tooltip, shortcut and enabled state is looked up rather than declared here.

⚠ Nothing here computes enablement any more; every button is bound to its id. ButtonBase.Command is what writes Disabled, the label and the check state, from whatever the route resolves the id to — so this class no longer knows that a registry is the thing that answers, and a strip built by an application with a different responder behind it works the same. What it costs is a requirement: the registry has to be reachable from the document, which EditorShell does by installing it as the ApplicationCommandResponder. A presenter over a registry nothing installed shows every button greyed, because nothing responds — which is the binding telling the truth and not a bug in it.

⚠ A bound button follows the invalidation, and this strip is still polled anyway. See Refresh: two of the editor's own toolbar predicates read state that tells the document nothing, so EditorShell.Tick still asks. The poll is now one line calling the same refresh the invalidation would, rather than a second implementation of what a bound button already does.

A command with an icon gets an icon button; one without gets its title. A toolbar of identical blank squares is worse than a toolbar of words, and requiring an icon would mean a plugin could not add a toolbar button without drawing one. It is also doc 20's stated mitigation for the icon set being a design dependency: a glyph that has not been drawn yet costs a wider button and never a blocked feature.

⚠ The bar grows sections, not entries. Doc 20's toolbar is mode buttons | save and build | transform mode, space, pivot, snap | play | layout, and two of those need something a flat list of ids cannot express: a segmented control, so that the three gizmo modes read as one choice, and a dropdown, so that a snap value is a popover rather than eight more buttons. Show takes those; Show is still the flat form, and is the same thing with every entry a button.

Fields and properties (3)

  • public IReadOnlyList<ToolbarEntry> Entries

    What is on it, in order.

  • public IReadOnlyList<string?> Items

    The ids on it, with null for anything that is not a plain button.

  • public Toolbar Strip

    The strip element, which is replaced by every rebuild.

Methods (5)

  • public ToolbarPresenter(UiElement host, CommandRegistry commands, KeyMap keys)

    Builds a toolbar into an element.

  • public void Show(params ReadOnlySpan<string?> commandIds)

    Puts a set of commands on the toolbar.

  • public void Show(params ReadOnlySpan<ToolbarEntry> entries)

    Puts a described strip on the toolbar.

  • public void Rebuild()

    Throws the strip away and builds it again.

  • public void Refresh()

    Asks the route about every command on the strip, and shows the answers.

Used by (14)

  • AttachedVixen.Editor.App
  • ChromeFixtureVixen.Editor.Ui.Tests
  • EditorAffordanceTestsVixen.Editor.App.Tests
  • EditorApplicationVixen.Editor.App
  • EditorModeTestsVixen.Editor.App.Tests
  • EditorShellVixen.Editor.Ui
  • EditorShellTestsVixen.Editor.Ui.Tests
  • MenuTestsVixen.Editor.Ui.Tests
  • ModeTestsVixen.Editor.Ui.Tests
  • ToolbarBindingTestsVixen.Editor.Ui.Tests
  • ToolbarPollTestsVixen.Editor.App.Tests
  • ToolbarSectionTestsVixen.Editor.Ui.Tests
  • TransportTestsVixen.Editor.App.Tests
  • ViewportChromeVixen.Editor.App