diff options
| author | Danilo M. <danix@danix.xyz> | 2026-08-19 10:46:45 +0200 |
|---|---|---|
| committer | Danilo M. <danix@danix.xyz> | 2026-08-19 10:46:45 +0200 |
| commit | a36fff5617f16ac1d17c0c52f2112a20c4fa9336 (patch) | |
| tree | 7da72c963d071fe1563a4b4d9912b03dfad6d21a /src/messageview.h | |
| parent | 98918f4c5f4e05aef1309de823e78da1f50c732d (diff) | |
| download | qtmaildir-a36fff5617f16ac1d17c0c52f2112a20c4fa9336.tar.gz qtmaildir-a36fff5617f16ac1d17c0c52f2112a20c4fa9336.zip | |
feat(pane): offer Select all, and report what a copy copied
Items 115 and 117, both from the user's notes.
Select all was never in Chromium's menu for this pane, measured by hand with a
selection active and against a build with removeBrowserActions() reverted, so
the filter is not what removed it. MessageView::addPaneActions() supplies it,
static and taking the menu, mirroring removeBrowserActions() beside it. Two
comments claiming the standard menu already offered it are corrected; either
would have sent the next reader down the same three wrong theories the item
records.
The copy entries all worked and none of them said so. Four now report through
the pane's existing statusMessage, each naming what it copied rather than saying
"Copied", which is the item's own constraint when three of them sit together in
one menu. Connected to the page's own QActions, so the report follows the entry
wherever it is triggered from.
The two differ in what can be tested, and the tests say so rather than papering
over it. The copy path is fully covered: triggering the action runs the
production path, and mutations for a duplicated message and an unwired entry
both fail. addPaneActions() is covered, but showBodyContextMenu() CALLING it is
not and cannot be, since createStandardContextMenu() returns nothing outside a
real context-menu event; a mutation deleting that call leaves the suite green,
measured. The call site is a hand test and the test file records that so nobody
adds an assertion that appears to cover it.
The copy strings are QT_TR_NOOP inside an array, which CLAUDE.md warns extracts
nothing at file scope. Verified rather than assumed: lupdate found all four
under the MessageView context, because the array sits inside a member function.
387 finished, 0 unfinished.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Diffstat (limited to 'src/messageview.h')
| -rw-r--r-- | src/messageview.h | 23 |
1 files changed, 21 insertions, 2 deletions
diff --git a/src/messageview.h b/src/messageview.h index df20e40..0b18769 100644 --- a/src/messageview.h +++ b/src/messageview.h @@ -155,8 +155,10 @@ public: /// Item 100. The pane is not a browser: every document arrives through /// setHtml() with a fixed base URL, so Back, Forward, Reload and Save page /// have nothing to act on and the interceptor blocks everything by default - /// anyway. Copy and Select all are the reason the standard menu is used at - /// all, so the menu is filtered, not rebuilt. + /// anyway. Copy and View source are the reason the standard menu is used at + /// all, so the menu is filtered, not rebuilt. Select all is NOT among them: + /// Chromium's menu here has never offered it, which item 117 measured and + /// addPaneActions() supplies. /// /// View source is NOT filtered, though it was at first. It has a real /// document and a real use; item 113 implements it as our own dialog, @@ -170,6 +172,23 @@ public: /// without a rendered document or a shown popup. static void removeBrowserActions(QMenu *menu, QWebEnginePage *page); + /// Adds the entries this pane needs and Chromium's standard menu does not + /// supply: Select all, for now. + /// + /// Item 117. Chromium's menu for this pane has NEVER carried Select all, + /// measured by hand with a selection active and against a build with + /// removeBrowserActions() reverted. Do not assume the standard menu + /// provides it and do not "restore" it by relaxing the filter above, which + /// never removed it. + /// + /// Static and taking the menu for the same reason as removeBrowserActions(): + /// createStandardContextMenu() returns nothing outside a real context-menu + /// event, so the production menu cannot be built in a test at all. A test + /// that hand-builds a QMenu proves what THIS function does and nothing + /// about what Chromium offers, which is the distinction item 117 records + /// after three wrong theories. Keep the two questions separate. + static void addPaneActions(QMenu *menu, QWebEnginePage *page); + /// Tells the pane whether the query bar currently holds anything. /// /// The menus need it to grey out "Exclude from search": excluding from an |
