Skip to content

Feat - Goto pre mention - #188

Open
crazypeace wants to merge 14 commits into
forkgram:devfrom
crazypeace:goto-pre-mention
Open

Feat - Goto pre mention#188
crazypeace wants to merge 14 commits into
forkgram:devfrom
crazypeace:goto-pre-mention

Conversation

@crazypeace

Copy link
Copy Markdown

This feat is to jump to Pre message mentioned me.

Group menu
image

Effect
fSVRS

To be honest, I know that my fork is not a perfect practice.
But I think the core code logic is done.
I already tested the win10 amd64 compile result.

You can just pick the code you need.
Or, please tell me where I need to improve, I will try my best.
But, to be honest, I just said human language to agent to develop the code.

Add a new context menu item right below 'Go to the first message' in the
group chat menu (fillHistoryActions / fillProfileActions).

Implementation: GoToLastMentionHandler issues a messages.search request
with the inputMessagesFilterMyMentions filter (server-side tag for any
message that mentions me, read or unread), takes the newest matching
message id and jumps to it via showPeerHistory.

Also add a goto-last-mention.yml workflow that builds Windows x64
(Release) with the existing at-me-on-top configuration pattern.
user request: on the goto-last-mention branch, every workflow that compiles
results should only run when triggered manually (workflow_dispatch), not on
push. Set win.yml, linux.yml, mac.yml, mac_packaged.yml, docker.yml,
win_release.yml, linux_release.yml and goto-last-mention.yml to
workflow_dispatch-only triggers.
prepare.py's qt6windows7 stage (new in v7.0.9) hardcodes
%ROOT_DIR%\tdesktop\patches, and ROOT_DIR is computed by walking
4 levels up from Telegram/build/prepare, landing on TBuild. The official
workflow clones the repo as 'tdesktop' under TBuild so that path resolves
to TBuild\tdesktop\patches (= repo root patches).

Cloning the repo under its real name (forkgram-tdesktop) breaks that
assumption and the qt6windows7 patch stage fails with
'could not open ...\tdesktop\patches\0001-...patch'. Fix by pinning
REPO_NAME=tdesktop so the checkout lands exactly where prepare.py expects.
The workflow builds Telegram as Release (CMAKE_CONFIGURATION_TYPES=Release)
but win.bat was called with 'skip-release', so tg_angle and breakpad were
only built in Debug and their Release .lib files were missing -> LNK1181
when linking codegen targets. Match the working at-me-on-top.yml which uses
'win.bat silent' (builds both Debug and Release).
In Qt 5.15 QSslSocket has both a deprecated sslErrors() const query
method and the sslErrors(const QList<QSslError>&) signal with the same
name, so &QSslSocket::sslErrors is an overloaded function that
QObject::connect cannot deduce (error C2665) when building with Qt 5
(the official Windows builds use Qt 6, where this does not occur).

Fix by selecting the signal overload explicitly with QOverload.
The GitHub-hosted Windows runner has limited C: space and TBuild lives on
C: (Libraries path). Building both Debug and Release dependency libraries
leaves the disk too full for the final Telegram.exe Release link (error
LNK1180). Add a cleanup step after Libraries that removes Debug-configured
library trees, .obj dirs and non-Release PDBs; only Release artifacts are
needed for the -D CMAKE_CONFIGURATION_TYPES=Release build.
Replace the single 'Go to the last message mentioned me' action with two
directional actions:

- 'Go to the Pre msg @me': anchor = topmost visible message, then search
  messages with inputMessagesFilterMyMentions and offset_id = anchor id
  (returns strictly older messages), jump to the newest of them (the
  closest mention above the viewport).
- 'Go to the Next msg @me': anchor = bottommost visible message, then
  search with min_id = anchor id + 1 (returns strictly newer messages,
  newest first), jump to the oldest of the returned page (the closest
  mention below the viewport).

Expose the viewport anchors through small public accessors:
- ListWidget::visibleTopItem() / visibleTop() / visibleBottom()
- ChatWidget::listWidget()
- MainWidget::mainSectionAsChat() (dynamic_cast of the main section)
The Pre/Next @me actions always jumped to the same fixed messages
because the viewport anchor was never found: plain group/private chats
render in HistoryWidget (MainWidget::_history), NOT in
HistoryView::ChatWidget, so mainSectionAsChat() returned null and the
anchor stayed 0 (Pre degenerated to 'newest mention', Next to a fixed
page).

Anchor resolution now tries both containers:
- HistoryView::ChatWidget (channels): ListWidget::visibleTopItem() for
  Pre, lookupItemByY(visibleBottom()) for Next (as before).
- HistoryWidget (groups/private): History::scrollTopItem (the message
  at the top of the visible window) for Pre; new public helper
  History::scrollBottomItem(viewportHeight) computes the bottom visible
  message from scrollTopItem + scrollTopOffset + viewport height via the
  existing findItemAndOffset(), for Next.

New plumbing: MainWidget::historyWidget(), HistoryWidget::listViewportHeight()
(declaration in header, impl in cpp — _scroll is only forward-declared in
the header). Next without an anchor now toasts message-not-found instead
of jumping to a fixed message.
window_session_controller.cpp hit 'compiler is out of heap space' (C1060)
during the Release build on the hosted runner. Unbounded --parallel on a
16-core machine spawns too many cl.exe processes; the include growth from
history.h/mainwidget.h/history_widget.h changes makes some translation
units memory-heavy. Cap parallelism at 4 so each cl.exe keeps enough
headroom.
Restoring the 1.4GB out/ cache on top of ThirdParty+libs+Qt caches and
the clone filled the hosted runner's C: drive ('There is not enough space
on the disk' in actions/cache). The out cache has near-zero hit value
(every feature run changes sources anyway) and costs 1.4GB per run.
Full rebuild without it already succeeded in the goto-last-mention round.
C1060 (compiler out of heap space) hit window_session_controller.cpp
and apiwrap.cpp even WITH the 1.4GB build-output cache restored
(incremental). The root cause is many huge translation units compiling
in parallel: each cl.exe peaks ~1-2GB, and 16 concurrent ones exhaust
the hosted runner's memory. --parallel 4 did not help (the failure is
per-process, not scheduling). Build serially so one cl.exe runs at a
time; incremental builds only touch the files changed by our headers,
so time impact is modest.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant