Let each person choose toolbar buttons

[HMarzban]

Status: raw idea. This needs a discussion and a plan before any build.

The idea

Each person should control, sort, and manage which buttons show in the pad toolbars.

Edward Saperia asked for a toolbar toggle that shows a QR code of the page. That toggle will be its own issue. This note is only the larger setting.

Why now

Toolbars only grow. A new button has nowhere to go except a hard-coded row. People who do not want that button still see it.

What we have today

These lists are read from code, not measured in a browser.

Pad header. Desktop PadTitle paints a fixed row. It shows the mark, Pad title, sync, Filter chips, Private, and Read-only. The right side shows faces, Share, History, the bell, and the profile. A signed-out reader sees a theme button and Sign in. The bell shows only for a signed-in person. Mobile MobilePadTitle is a second fixed row. It shows the menu or Done, the title or Undo and Redo, sync, Private, Read-only, the bell, and the profile.

Desktop editor toolbar. EditorToolbar paints one fixed row. The formatting controls are Block style, Bold, Italic, Underline, Strikethrough, Highlight, Insert Media, Comment, Hyperlink, Lists, Blockquote, Code, and Clear formatting. Lists and Code are menus with a fixed item array in that file. The utility buttons sit at the right. They are the Discord button, Copy document, Documents, Bookmarks, Find, Filter, and Document settings. Documents and Bookmarks show only for a signed-in person.

Phone editor toolbar. ToolbarMobile paints a fixed main row. It shows the heading stepper, link, image, comment, and the format toggle. FormatSelection paints a fixed set of marks, lists, and Clear formatting. The bar is absent unless the keyboard is open and the chat pane is closed.

Chat composer. FORMAT_TOOLBAR_GROUPS is a fixed list of button components. Desktop FormattingToolbar reads the groups. The phone ComposerFormatPanel reads the same list as one flat grid. The groups are Bold, Italic, Strikethrough, and code; Hyperlink and Mention; the two lists; Blockquote and Code block. The bar starts closed. Open or closed is stored for this tab only, under docsy:composer-format-toolbar:. The insert menu is a separate fixed list: Attach file, Text formatting, and Record voice.

Slash menu. SLASH_ITEMS is a fixed catalog. The list filters by the typed query and by whether the command can run. Rows cover headings, Subtitle, Normal, lists, Blockquote, Code block, Picture, and a section link.

Heading action chips. hoverChatPlugin builds a fixed pair: chat, then comment. A text selection adds one comment chip.

Media toolbar. This bar is data-driven. BASE_ACTIONS plus a per-node recipe builds the list. The host hook mediaActions can add, drop, or reorder actions. getMediaActionsResolver adds Comment after Download. mediaToolbarIcons supplies the icons. Each action is inline or in the overflow menu.

Other button rows. The docked chat header is fixed: path, faces, Share, notifications, and Close. The history toolbar is fixed: Back, Print, copy link, and Changes. The gallery builds one action list and places each action on the pill or in overflow. That list is not a user setting.

Where settings live. Settings tabs are Profile, Documents, Appearance, Security, Notifications, and Connected apps. Theme preference is stored in the browser under docsplus-theme. Wide TOC width is docsy:toc-width. Docked chat height is docsy:chat-height. Heading folds use editor-folds- plus the document id. Documents sort and view use session storage. The server profile is public.users, with extra fields in profile_data. Bio, links, and notification preferences live in that object. update_notification_preferences merges a patch into that object. No table and no field stores a toolbar layout. A layout could reuse an action id list, like the media toolbar. It could reuse a JSON patch, like notification preferences. It could reuse a browser key, like the theme store.

Options to discuss

Scope. Per person: the layout follows the account, so a shared computer needs a sign-in. Per device: the layout stays in that browser, so a second device starts from the default. Per workspace: one account can differ by pad, so the store grows with every document. Per document owner: the owner picks the bar for every reader, so a reader loses their own set.

Storage. Browser only: no server work, and a new browser loses the layout. Profile on the server: the layout follows the account, and a signed-out reader has no profile to save. Both: the server can win after sign-in, and the two copies can disagree.

Which bars. Utility buttons only: the QR toggle has a home, and the formatting row stays crowded. Formatting controls too: one setting covers both halves of EditorToolbar, and the phone row must follow or drift. Composer too: chat and the pad stay aligned, and the composer list is a different set.

How to manage it. A Settings list with checkboxes and move up or down matches the other settings. The person edits away from the bar. An in-place customize mode: the person sees the real bar, and every toolbar needs that mode. An overflow group: the bar stays short, and a hidden button takes one more click.

Reorder. Move up and move down need no drag. A drag-only reorder fails WCAG 2.2 Success Criterion 2.5.7, because dragging must have a single-pointer path that does not drag.

Default and Reset. Ship the current button set as the default. Reset puts that set back, so a bad edit is reversible.

Groups. Keep the current groups, so a move stays inside a group. A free order can place a divider in a nonsense spot.

Buttons that stay. Share and History are how a reader leaves the pad and opens versions. Document settings is where Private and Read-only change on the pad. The plan should name every button that cannot be hidden.

New buttons. The media toolbar already takes a host list through mediaActions. The editor toolbar has no such list. A QR toggle needs a registry, or the next button is another hard-coded node.

Phone. The phone bar is a short row with a 44px target, and it shows only while the keyboard is open. A long desktop set cannot copy onto that row as it is.

Read-only pad. The editing lock blocks edits for a non-owner. A layout setting must say which buttons remain for a reader who cannot edit.

People who already use the app. Missing storage means the current set. A new button should stay off until the default says to show it.

Telemetry. No toolbar-layout event exists in the code read for this note. The plan should say whether to count which buttons people hide.

Cost. Six button rows are fixed in components. The skeleton must match the real controls. A change to the media toolbar is a published extension change. A wrong hide can remove Share, History, or the Private control.

Reference points

• The WAI-ARIA toolbar pattern gives the toolbar one Tab stop. Arrow keys move among its controls. https://www.w3.org/WAI/ARIA/apg/patterns/toolbar/
• WCAG 2.2 Success Criterion 2.5.7 says a drag action needs a single pointer path without dragging, unless dragging is essential. https://www.w3.org/WAI/WCAG22/Understanding/dragging-movements.html
• Word documents a Quick Access Toolbar. A person can add, remove, reorder, and reset those commands. https://support.microsoft.com/en-us/office/customize-the-quick-access-toolbar-43fff1c9-ebc4-4963-bdbd-c2b6b0739e52
• VS Code lets a person hide the Activity Bar or move it from a menu. Customize Layout stores density across restarts. https://code.visualstudio.com/docs/configure/custom-layout
• Chrome lets a person drag an extension icon to reorder it, Unpin to hide it, and Pin to show it. https://support.google.com/chrome_webstore/answer/2664769

The desktop editor toolbar is a plain div. It does not use the ARIA toolbar role. Adopting that pattern is a separate choice.

Earlier decisions

• Favorite has no toolbar star. Do not add one.
• Report stays a Settings row. Do not put Report on the pad header.
• History stays available without a session. Restore stays hidden for a visitor and when the editing lock is on.
• The media action list uses inline or overflow. Do not rename that placement to menu.
• There is no signed-out Settings path.
• Issue Extend and add more toolbar buttons #104 is closed. It asked for more buttons and a horizontal scroll. It is not this setting.
• Issue Refactor Toolbar, I need to remove unused toolbar buttons or move them to the TOC modal #93 is closed. It asked to drop unused buttons. It is not this setting.
• Issue Hide the phone edit toolbar when the pad is read-only #308 is open. It asks to hide the phone edit toolbar on a read-only pad.
• A discussion search for a toolbar layout setting found none. Discussion Revise the mobile view #105 is about the mobile view.

Open questions

• Which bars are in scope?
• Which buttons can never be hidden?
• Does the layout follow the account, the browser, or both?
• Does a new button, such as the QR toggle, start visible?
• Does the phone bar use the same list?
• Who can change the bar on a read-only pad?

Next step

Discuss the options here. After that, split the work into issues. Do not start a build from this note.

[HMarzban]

The QR toolbar toggle is filed as issue #377. That issue covers only the QR toggle. This discussion covers the larger toolbar setting.