The mailbox's multi-select contextual action bar (SelectionTopBar, MailboxScreen.kt:537-630) shows
only Close and Delete as direct icons; Archive, Spam, Move, Select All, and (for a single selection)
Reply/Reply All/Forward are all buried behind one MoreVert overflow DropdownMenu
(MailboxScreen.kt:564-627). The reader's own app bar (ReaderScreen.kt:94-129) already uses direct
icons/buttons for its actions (Reply, Star, Delete) with no dropdown — this brings the mailbox selection
bar in line with that existing pattern.
Proposed behavior
Promote the most common actions to direct IconButtons on the top bar, keeping only the long tail (if
any) in the overflow — similar to how most mail clients show Archive/Delete/Move as icons and reserve the
overflow for rarer actions. Candidates for promotion: Archive, Spam, Move (each already has its own
conditional visibility based on folderRole/canMove). Reply/Reply All/Forward could stay in the
overflow (or promote just Reply) since they only apply to a single selected message.
Suggested approach
SelectionTopBar's actions block (MailboxScreen.kt:560-628) already computes the same visibility
conditions (folderRole != FolderRole.ARCHIVE, canMove, count == 1) used inside the dropdown —
converting a given DropdownMenuItem into an IconButton is mechanical per action. The harder part is
picking icons within this codebase's existing material-icons-core-only constraint (see the Inc 5/Inc 18
notes on sticking to Icons.AutoMirrored/core icons) — there's no dedicated "Move" icon in
material-icons-core, so that one may need a reasonable stand-in or stay text-labeled in a smaller
overflow. A top bar with too many icons can also overflow on small screens, so check at a few widths.
Acceptance criteria
Common actions (at least Archive, Spam where applicable) are direct icon buttons, not hidden in a
dropdown.
Existing conditional visibility (folder role, canMove, single-selection-only actions) is preserved.
Verified on a narrow-width device/emulator that the bar doesn't overflow awkwardly.
## Context
The mailbox's multi-select contextual action bar (`SelectionTopBar`, `MailboxScreen.kt:537-630`) shows
only Close and Delete as direct icons; Archive, Spam, Move, Select All, and (for a single selection)
Reply/Reply All/Forward are all buried behind one `MoreVert` overflow `DropdownMenu`
(`MailboxScreen.kt:564-627`). The reader's own app bar (`ReaderScreen.kt:94-129`) already uses direct
icons/buttons for its actions (Reply, Star, Delete) with no dropdown — this brings the mailbox selection
bar in line with that existing pattern.
## Proposed behavior
Promote the most common actions to direct `IconButton`s on the top bar, keeping only the long tail (if
any) in the overflow — similar to how most mail clients show Archive/Delete/Move as icons and reserve the
overflow for rarer actions. Candidates for promotion: Archive, Spam, Move (each already has its own
conditional visibility based on `folderRole`/`canMove`). Reply/Reply All/Forward could stay in the
overflow (or promote just Reply) since they only apply to a single selected message.
## Suggested approach
`SelectionTopBar`'s `actions` block (`MailboxScreen.kt:560-628`) already computes the same visibility
conditions (`folderRole != FolderRole.ARCHIVE`, `canMove`, `count == 1`) used inside the dropdown —
converting a given `DropdownMenuItem` into an `IconButton` is mechanical per action. The harder part is
picking icons within this codebase's existing material-icons-core-only constraint (see the Inc 5/Inc 18
notes on sticking to `Icons.AutoMirrored`/core icons) — there's no dedicated "Move" icon in
material-icons-core, so that one may need a reasonable stand-in or stay text-labeled in a smaller
overflow. A top bar with too many icons can also overflow on small screens, so check at a few widths.
## Acceptance criteria
- [ ] Common actions (at least Archive, Spam where applicable) are direct icon buttons, not hidden in a
dropdown.
- [ ] Existing conditional visibility (folder role, canMove, single-selection-only actions) is preserved.
- [ ] Verified on a narrow-width device/emulator that the bar doesn't overflow awkwardly.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Context
The mailbox's multi-select contextual action bar (
SelectionTopBar,MailboxScreen.kt:537-630) showsonly Close and Delete as direct icons; Archive, Spam, Move, Select All, and (for a single selection)
Reply/Reply All/Forward are all buried behind one
MoreVertoverflowDropdownMenu(
MailboxScreen.kt:564-627). The reader's own app bar (ReaderScreen.kt:94-129) already uses directicons/buttons for its actions (Reply, Star, Delete) with no dropdown — this brings the mailbox selection
bar in line with that existing pattern.
Proposed behavior
Promote the most common actions to direct
IconButtons on the top bar, keeping only the long tail (ifany) in the overflow — similar to how most mail clients show Archive/Delete/Move as icons and reserve the
overflow for rarer actions. Candidates for promotion: Archive, Spam, Move (each already has its own
conditional visibility based on
folderRole/canMove). Reply/Reply All/Forward could stay in theoverflow (or promote just Reply) since they only apply to a single selected message.
Suggested approach
SelectionTopBar'sactionsblock (MailboxScreen.kt:560-628) already computes the same visibilityconditions (
folderRole != FolderRole.ARCHIVE,canMove,count == 1) used inside the dropdown —converting a given
DropdownMenuIteminto anIconButtonis mechanical per action. The harder part ispicking icons within this codebase's existing material-icons-core-only constraint (see the Inc 5/Inc 18
notes on sticking to
Icons.AutoMirrored/core icons) — there's no dedicated "Move" icon inmaterial-icons-core, so that one may need a reasonable stand-in or stay text-labeled in a smaller
overflow. A top bar with too many icons can also overflow on small screens, so check at a few widths.
Acceptance criteria
dropdown.