diff options
| author | Danilo M. <danix@danix.xyz> | 2026-08-24 11:13:04 +0200 |
|---|---|---|
| committer | Danilo M. <danix@danix.xyz> | 2026-08-24 11:13:04 +0200 |
| commit | 2703d4c42710418b0f15a41fa896824e2e1a6170 (patch) | |
| tree | c7f463a92c4f56b7f6a1e02def9bc2d53c4894c0 /src/messageview.h | |
| parent | dd6f35b8f35f231ebf1511daef3dd707eaa9839d (diff) | |
| download | qtmaildir-2703d4c42710418b0f15a41fa896824e2e1a6170.tar.gz qtmaildir-2703d4c42710418b0f15a41fa896824e2e1a6170.zip | |
feat(ui): give the message pane its own action bar
Items 139, 140 and 141, built together because the seam between them is
wasted work: 140 needs a container and 141 is that container.
The main toolbar had grown to mix two scopes. Sync, Archive, Delete, Mark
all read and Undo act on the list or the selection; Compose, Reply and
Forward are about one message. With everything in one row the distinction
was invisible, and Forward was on no toolbar at all, reachable only from the
Message menu, which is item 139.
Compose, Reply and Forward now sit on a bar above the message pane, and
LEAVE the main toolbar rather than gaining a second home: that is what makes
the toolbar's remaining contents mean one thing. Toggle HTML joins them at
the right end, separated by an expanding spacer, since changing how a
message is displayed is a different scope from acting on it. That layout was
the open design question item 141 recorded, and it was settled with the user
rather than guessed.
The actions are MainWindow's own QAction objects shown a second time, never
copies: a duplicate would carry its own enablement and drift from the menu
entry updateComposeActions() keeps in step. MessageView::setBarActions() is
the seam, so the pane still knows nothing about the window's action map.
Two things worth recording:
QToolBar has no addStretch(), so the separation is an expanding spacer
widget. A test asserting only on action ORDER passes with that spacer
deleted, measured, so it asserts on the spacer's size policy instead.
noTwoActionsShareAnIcon looked up the toolbar with an unnamed
findChild<QToolBar*>(). There are two toolbars now, so it is pinned to
main_toolbar: pointed at the pane's bar it would have asserted that a
thread action is absent from a bar that never holds any, and passed while
the rule it exists for went unchecked.
Diffstat (limited to 'src/messageview.h')
| -rw-r--r-- | src/messageview.h | 11 |
1 files changed, 11 insertions, 0 deletions
diff --git a/src/messageview.h b/src/messageview.h index 29101d6..b28dcdc 100644 --- a/src/messageview.h +++ b/src/messageview.h @@ -32,6 +32,7 @@ class QLabel; class QMenu; +class QToolBar; class QWebEnginePage; class QPushButton; class QWebEngineView; @@ -245,6 +246,15 @@ public: /// after three wrong theories. Keep the two questions separate. static void addPaneActions(QMenu *menu, QWebEnginePage *page); + /// Fills the pane's own action bar (items 139 to 141). The actions are + /// MainWindow's own, shown a second time rather than duplicated, so they + /// keep one enablement state and one menu entry. \p viewControls are + /// separated from \p messageActions by a stretch: acting on the message + /// and changing how it is displayed are different scopes, which is the + /// confusion the bar exists to remove one level up. + void setBarActions(const QList<QAction *> &messageActions, + const QList<QAction *> &viewControls); + /// Tells the pane whether the query bar currently holds anything. /// /// The menus need it to grey out "Exclude from search": excluding from an @@ -405,6 +415,7 @@ private: CidSchemeHandler *m_cidHandler = nullptr; QLabel *m_headerLabel = nullptr; + QToolBar *m_messageBar = nullptr; QWidget *m_blockedBar = nullptr; QLabel *m_blockedLabel = nullptr; QLabel *m_receiveOnlyRibbon = nullptr; |
