Pr adjust codeql - #477
Merged
Merged
Conversation
Contributor
|
You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool. What Enabling Code Scanning Means:
For more information about GitHub Code Scanning, check out the documentation. |
mrjimenez
pushed a commit
to mrjimenez/amule
that referenced
this pull request
Jul 15, 2026
…ject#445) + list rows blanking on scroll/keyboard (amule-project#478) (amule-project#477) * fix(remote-gui): stop the log view blanking on Windows by dropping Freeze/Thaw (amule-project#445) amule-project#471 tried to fix the "log view goes blank on every new line" Windows regression by thawing before scrolling, but it made no difference: the AppendText still ran while the control was frozen. Appending to a frozen wxTE_RICH2 (RichEdit) on Windows leaves its line/scroll metrics stale, so on Thaw the view renders blank with the newest line pinned to the top until a manual scroll forces a recompute. The Freeze()/Thaw() that amule-project#451 wrapped the per-poll appends in is the actual culprit, not the scroll order. Drop the Freeze()/Thaw() and append on a live control (as the pre-amule-project#451 code did). Keep the two real wins from amule-project#451: the daemon's 5000-lines-per-poll cap and the conditional SetDefaultStyle, plus one coalesced ShowPosition per poll instead of per line (m_logBatching still suppresses the per-line scroll). The per-line SetDefaultStyle was the dominant first-sync cost, so responsiveness is retained without the frozen-append rendering corruption. macOS/GTK recompute metrics regardless and were unaffected either way. * fix(remote-gui): repaint list rows on scroll & keyboard nav on Windows (amule-project#478) amule-project#348 replaced the vendored wxListMainWindow::OnScroll's synchronous HandleOnScroll(event) with event.Skip() -- HandleOnScroll became a private member in wx 3.3.3, so the macOS/Linux CI (on wx 3.3.x) stopped compiling. On wxMSW the resulting deferred-scroll path (wxScrollHelperBase::HandleOnScroll -> ScrollWindow) blits the retained rows and only invalidates the newly exposed strip, which is then left unpainted: rows go blank on mouse-wheel, scrollbar and pagination scrolling until a redraw is forced. Verified in the wx 3.2.10 and 3.3.x sources that the scroll+repaint mechanism is identical, so this is a wxMSW platform behavior, not a wx-version one. Rather than gate on platform or wx version (both fragile -- the former needs the now-private HandleOnScroll, the latter breaks once Windows ships wx 3.3.3), reimplement the synchronous scroll using only the public wxScrollHelper API (GetViewStart / GetScrollLines / GetScrollPageSize / Scroll), mirroring HandleOnScroll()/CalcScrollInc(): translate the scroll event into a target position in scroll units and scroll to it. Factor the "scroll + repaint" sequence into a shared ScrollListTo(x, y) helper (Update() to flush pending paints so the blit is clean, Scroll(), then ResetVisibleLinesRange() so the exposed rows repaint) and route both OnScroll (scrollbar/wheel) and MoveToItem (keyboard nav) through it. This also fixes the keyboard HOME/END/PgUp/PgDn blanking, which was the same bug from a different path: MoveToItem only reset the visible-line range after Scroll() under __WXMAC__, so on Windows the range stayed stale and keyboard scrolls came up blank. The reset now runs on every platform via the shared helper, and the old __WXMAC__-only workaround is gone. Not skipping the event means the base scroll helper won't also scroll, so no double-scroll. Works on every supported wx (>= 3.2.0) and every platform with no version or platform guard; compiles against wx 3.3.3. Refs amule-project#478
got3nks
added a commit
to got3nks/amule
that referenced
this pull request
Jul 22, 2026
The amuleGUI log panes used a wxTE_RICH2 (RichEdit) control, which holds the whole document and reflows O(n) on scroll. A remote-GUI first sync can dump tens of thousands of daemon-log lines at once, so scrolling crawled and the view mispainted -- only the tail visible until a manual one-line scroll (issues amule-project#445, amule-project#547). Replace the three log/info panes (aMule Log, aMuleGUI Log, server info) with a new CMuleLogCtrl backed by wxStyledTextCtrl. Scintilla renders only the visible lines, so scrolling and full-history retention stay O(visible) at any size, and unlike a virtual list it keeps character-level selection and find. Critical lines are bold via per-line Scintilla styles; the view tail-scrolls only when already at the bottom, so scrolling up to read history sticks. This removes the whole RichEdit workaround stack -- the per-poll append batching, the deferred hidden-page scroll, and the Freeze/Thaw lineage from amule-project#451/amule-project#471/amule-project#477 -- none of which Scintilla needs. wxStyledTextCtrl (the stc component) ships with the wxWidgets packages every platform already builds against, so it adds no new dependency; it is requested only for the GUI library that owns the log views.
got3nks
added a commit
to got3nks/amule
that referenced
this pull request
Jul 22, 2026
The amuleGUI log panes used a wxTE_RICH2 (RichEdit) control, which holds the whole document and reflows O(n) on scroll. A remote-GUI first sync can dump tens of thousands of daemon-log lines at once, so scrolling crawled and the view mispainted -- only the tail visible until a manual one-line scroll (issues amule-project#445, amule-project#547). Replace the three log/info panes (aMule Log, aMuleGUI Log, server info) with a new CMuleLogCtrl backed by wxStyledTextCtrl. Scintilla renders only the visible lines, so scrolling and full-history retention stay O(visible) at any size, and unlike a virtual list it keeps character-level selection and find. Critical lines are bold via per-line Scintilla styles; the view tail-scrolls only when already at the bottom, so scrolling up to read history sticks. This removes the whole RichEdit workaround stack -- the per-poll append batching, the deferred hidden-page scroll, and the Freeze/Thaw lineage from amule-project#451/amule-project#471/amule-project#477 -- none of which Scintilla needs. wxStyledTextCtrl (the stc component) ships with the wxWidgets packages every platform already builds against, so it adds no new dependency; it is requested only for the GUI library that owns the log views.
got3nks
added a commit
to got3nks/amule
that referenced
this pull request
Jul 22, 2026
The amuleGUI log panes used a wxTE_RICH2 (RichEdit) control, which holds the whole document and reflows O(n) on scroll. A remote-GUI first sync can dump tens of thousands of daemon-log lines at once, so scrolling crawled and the view mispainted -- only the tail visible until a manual one-line scroll (issues amule-project#445, amule-project#547). Replace the three log/info panes (aMule Log, aMuleGUI Log, server info) with a new CMuleLogCtrl backed by wxStyledTextCtrl. Scintilla renders only the visible lines, so scrolling and full-history retention stay O(visible) at any size, and unlike a virtual list it keeps character-level selection and find. Critical lines are bold via per-line Scintilla styles; the view tail-scrolls only when already at the bottom, so scrolling up to read history sticks. This removes the whole RichEdit workaround stack -- the per-poll append batching, the deferred hidden-page scroll, and the Freeze/Thaw lineage from amule-project#451/amule-project#471/amule-project#477 -- none of which Scintilla needs. wxStyledTextCtrl (the stc component) ships with the wxWidgets packages every platform already builds against, so it adds no new dependency; it is requested only for the GUI library that owns the log views.
got3nks
added a commit
to got3nks/amule
that referenced
this pull request
Jul 22, 2026
The amuleGUI log panes used a wxTE_RICH2 (RichEdit) control, which holds the whole document and reflows O(n) on scroll. A remote-GUI first sync can dump tens of thousands of daemon-log lines at once, so scrolling crawled and the view mispainted -- only the tail visible until a manual one-line scroll (issues amule-project#445, amule-project#547). Replace the three log/info panes (aMule Log, aMuleGUI Log, server info) with a new CMuleLogCtrl backed by wxStyledTextCtrl. Scintilla renders only the visible lines, so scrolling and full-history retention stay O(visible) at any size, and unlike a virtual list it keeps character-level selection and find. Lines word-wrap as the old pane did; critical lines are bold via per-line Scintilla styles. The view tail-scrolls after new content only when it was already at the bottom, so scrolling up to read history sticks. When the backlog arrives while the Networks page is hidden (the default tab on launch is Transfer) the log control has no laid-out geometry and cannot be scrolled reliably, so the tail-scroll is deferred and performed when the page is next shown. This removes the whole RichEdit workaround stack -- the per-poll append batching and the Freeze/Thaw lineage from amule-project#451/amule-project#471/amule-project#477 -- none of which Scintilla needs. wxStyledTextCtrl (the stc component) ships with the wxWidgets packages every platform already builds against, so it adds no new dependency; it is requested only for the GUI library that owns the log views.
got3nks
added a commit
to got3nks/amule
that referenced
this pull request
Jul 22, 2026
The amuleGUI log panes used a wxTE_RICH2 (RichEdit) control, which holds the whole document and reflows O(n) on scroll. A remote-GUI first sync can dump tens of thousands of daemon-log lines at once, so scrolling crawled and the view mispainted -- only the tail visible until a manual one-line scroll (issues amule-project#445, amule-project#547). Replace the three log/info panes (aMule Log, aMuleGUI Log, server info) with a new CMuleLogCtrl backed by wxStyledTextCtrl. Scintilla renders only the visible lines, so scrolling and full-history retention stay O(visible) at any size, and unlike a virtual list it keeps character-level selection and find. Lines word-wrap as the old pane did; critical lines are bold via per-line Scintilla styles. The view tail-scrolls after new content only when it was already at the bottom, so scrolling up to read history sticks. When lines arrive while a pane is hidden (its notebook page or sub-tab is not selected -- e.g. the first-sync backlog before the Networks tab is opened) the control has no laid-out geometry and cannot be scrolled reliably, so the tail-scroll is deferred and applied on the first idle once the pane is on screen. This lives in CMuleLogCtrl, so all three panes share it. This removes the whole RichEdit workaround stack -- the per-poll append batching and the Freeze/Thaw lineage from amule-project#451/amule-project#471/amule-project#477 -- none of which Scintilla needs. wxStyledTextCtrl (the stc component) ships with the wxWidgets packages every platform already builds against, so it adds no new dependency; it is requested only for the GUI library that owns the log views.
got3nks
added a commit
to got3nks/amule
that referenced
this pull request
Jul 22, 2026
…le-project#548) The amuleGUI log panes used a wxTE_RICH2 (RichEdit) control, which holds the whole document and reflows O(n) on scroll, so a remote-GUI first-sync backlog of tens of thousands of daemon-log lines made scrolling crawl and mispaint (only the tail visible until a manual scroll). Replace the three log/info panes (aMule Log, aMuleGUI Log, server info) with a new CMuleLogCtrl backed by wxStyledTextCtrl (Scintilla), which renders only the visible lines: full history is kept and scrolling stays O(visible) at any size, with character-level selection/find preserved. Lines word-wrap; critical lines are bold via per-line styles. Tail-scroll only fires when already at the bottom; a scroll requested while the pane is hidden is deferred to the first idle once it is on screen (in the base control, so all three panes share it). Removes the RichEdit workaround stack (per-poll batching, the Freeze/Thaw lineage of amule-project#451/amule-project#471/amule-project#477). The stc component ships with every platform's wxWidgets and is requested only for the GUI library; the Windows portable bundles its DLL via the existing GET_RUNTIME_DEPENDENCIES install step. Reported in amule-project#547.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.