aMuleGUI - Improvements to remote server log view/retrieval

[ghysler]

Some low priority suggestions for improving the experience of the server log view/retrieval in aMuleGUI:

1. Upon launching the remote application, the initial view of the server log in the aMule Log tab only shows the last few lines after retrieving the server log. See screenshot below. When scrolling up one line, the rest of the log entries appear.

2. While the retrieval speed of the server log was greatly improved recently, it still feels rather slow when replaying the log from multiple days with a large download queue. In my situation it takes ~20 seconds to replay a log of ~16000 lines, which seems to be quite a bit slower than the "5000 lines per poll" implemented in Slow retrieval of remote log file in aMuleGUI #445.
   Would it be possible to retrieve the entire server log file in a single request, instead of polling lines?
   EDIT: it appears the GUI is actually slowing this down. When minimizing the GUI after the download queue is loaded, the retrieval of the log finishes in ~5 seconds. Perhaps smooth scrolling is resulting in high CPU load on the remote application, because I see a CPU spike during the log retrieval (also see no. 5)

To summarize:
~20 seconds when aMule Log tab is visible on screen
~10 seconds when Downloads Panel is left activated instead
~5 seconds when application is minimized during log retrieval

3. There should be no need to replay the entire server log when reconnecting after a disconnect, because the server log is already in memory. Only on a fresh start of the application the entire log file should be retrieved. Would it be possible to retrieve only the new lines from the log since the last disconnect?

4. It would be nice to see the remote daemon version string in the server log.
   Initialising aMuleD GIT compiled with wxBase(GTK3) v3.2.8 and Boost 1.83
   Although unsure if this entry normally includes the version string when running a stable release.

5. Smooth scrolling is being forced inside the aMule Log tab. Could this be prevented?

aMuleGUI 3.0.1-227 on Windows 11 x64
aMule developer build 07/20 on Docker Linux 29.6.2

[got3nks]

Thanks for the thorough testing throughout this, @ghysler.

I ended up reworking it more substantially than a scroll tweak: the log panes (aMule Log, aMuleGUI Log, server info) now use a Scintilla-backed control (wxStyledTextCtrl) instead of the old RichEdit one. Scintilla renders only the visible lines, so the full multi-day log is kept while scrolling stays instant regardless of size — that covers the slow retrieval/scroll (2) and the forced "smooth scrolling" (5). The initial view now paints correctly and lands at the bottom (1), including when the backlog arrives while the Networks tab is in the background.

• (3) Fetching only new lines on reconnect turned out to be moot once rendering is fast — it would need an EC-protocol change, and with the log now cheap to replay it isn't worth the extra complexity for now.
• (4) The GIT version string is just the develop-build placeholder; a stable release shows the number, so nothing to change.

Verified on macOS, Linux and Windows. Once this merges, a packaging build produces fresh portables — I'll drop the x64 link here for you to try.

[got3nks]

Merged — and a packaging build produced fresh x64 portables. Signed in to GitHub:

• windows-x64 → unzip → unzip the inner aMule-3.0.1-228-g2c5a8ec61-Windows-x64.zip → run amule-portable-x64\bin\amulegui.exe

Worth a run with a large log: scrolling should stay instant, the view lands at the bottom on first open (including when the backlog arrived while you were on another tab), and the aMuleGUI Log / server-info tabs behave the same. Full history is kept — no truncation.

[ghysler]

@got3nks
Thanks for the fast response and changes made.

With this build, the retrieval of the log is definitely faster. It now takes ~10 seconds to load 16k lines with the aMule Log tab visible on screen. Scrolling is also confirmed instant now.

The initial view however, does not land at the bottom of the log file. Instead it lands at the end of the second to last poll.

[got3nks]

That’s weird I tested on my Windows VM.

Did you switch to the network panel before the full log was retrieved from the remote daemon?

[ghysler]

Yes, after the download queue is loaded, I switch to the Network panel.

After some further testing it seems to be related to the main window width and the log lines being wrapped onto multiple lines.

With a width of 1280 pixels, some of my log lines don't fit and are being wrapped onto two lines and the initial view does not end at the bottom.
With a width of 2560 pixels, all of my log lines fit on a single line, so no wrapping, and the initial view does end at the bottom.

[got3nks]

Your width/wrap observation is the key clue here — thanks for narrowing it down. My best read: with word-wrap on, Scintilla lays out the wrapped lines incrementally (over several idle cycles), so the one-shot scroll-to-bottom likely runs before the tail is wrapped and stops short; on a window wide enough that nothing wraps, there's no incremental layout so it hits the bottom first try. I haven't reproduced your exact setup here, so treat this as a candidate fix rather than a confirmed root cause — the scroll now re-applies until the layout settles at the true bottom, and backs off the moment you scroll manually.

Fresh x64 portable with the change (fork build, not yet merged). Signed in to GitHub:

• windows-x64 → unzip → unzip the inner aMule-3.0.1-229-g0d026cc6b-Windows-x64.zip → run amule-portable-x64\bin\amulegui.exe

Same test, but resize the window narrow enough that some lines wrap, then switch to the Networks tab after the log finishes loading. If it still stops short, let me know the window width and roughly how many lines and I'll dig further.