Skip to content

Pr adjust codeql - #477

Merged
mrjimenez merged 7 commits into
amule-project:masterfrom
mrjimenez:pr_adjust_codeql
Apr 25, 2026
Merged

Pr adjust codeql#477
mrjimenez merged 7 commits into
amule-project:masterfrom
mrjimenez:pr_adjust_codeql

Conversation

@mrjimenez

Copy link
Copy Markdown
Contributor

No description provided.

@github-advanced-security

Copy link
Copy Markdown
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:

  • The 'Security' tab will display more code scanning analysis results (e.g., for the default branch).
  • Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results.
  • You will be able to see the analysis results for the pull request's branch on this overview once the scans have completed and the checks have passed.

For more information about GitHub Code Scanning, check out the documentation.

@mrjimenez
mrjimenez merged commit 5f2b16f into amule-project:master Apr 25, 2026
9 checks passed
@mrjimenez
mrjimenez deleted the pr_adjust_codeql branch April 25, 2026 14:04
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.
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.

2 participants