Add a cross-platform Avalonia log viewer control as the successor to the WPF LogMessageReceiver

[karlspace]

Problem

The library's live log viewer only works in WPF. BAUERGROUP.Shared.Desktop targets net10.0-windows;net8.0-windows with UseWPF/UseWindowsForms (src/BAUERGROUP.Shared.Desktop/BAUERGROUP.Shared.Desktop.csproj:4-6). An Avalonia application on Linux therefore cannot use WPFToolbox.LogMessageReceiverWindow (src/BAUERGROUP.Shared.Desktop/WPFToolbox.cs:19) and has to build its own viewer.

A straight port would also bring along problems in the current implementation:

• Two unrelated mechanisms. The window (src/BAUERGROUP.Shared.Desktop/Logging/LogMessageReceiver.xaml:13) hosts LogMessageReceiverControl, which receives log lines over UDP loopback through BGLoggerNetworkListener (Logging/LogMessageReceiverControl.xaml.cs:39). Logging/TextBoxTraceListener.cs is a separate TraceListener that nothing in the library uses.

• Global side effects of the UDP listener. BGLoggerNetworkListener sets BGLogger.Configuration.Network = true (src/BAUERGROUP.Shared.Core/Logging/BGLoggerNetworkListener.cs:43-44) and never sets it back. From then on, every log line is also sent to udp://127.0.0.1:9898 (the default NetworkPort, BGLoggerConfiguration.cs:44, :533, :560) until the process ends. Dispose only cancels and disposes the CancellationTokenSource (:47-52), and the loop checks the token only between blocking UdpClient.Receive calls (:28-30). The socket is therefore released only after the next datagram arrives.

• Buffer is either unbounded or loses history. Both viewers append with Text += (Logging/TextBoxTraceListener.cs:44, Logging/LogMessageReceiverControl.xaml.cs:53), which copies the whole text on every line. TextBoxTraceListener never trims. LogMessageReceiverControl clears all text once it passes 1000 lines (Logging/LogMessageReceiverControl.xaml.cs:57-58) instead of dropping only the oldest lines.

• The producer is blocked. TextBoxTraceListener uses Dispatcher.Invoke (Logging/TextBoxTraceListener.cs:42), so the thread that logs waits for the UI thread.

• Relies on window placement. The window is Topmost="True" with Left="5" Top="5" (Logging/LogMessageReceiver.xaml:11). Native Wayland does not honour that. In Avalonia.Wayland 12.1.2, Position, Activate() and SetTopmost() do nothing (WindowImplBase.cs#L67-L72), neither does Move (WindowImpl.cs#L310-L311), and Window.Activate() only forwards to the platform (WindowBase.cs#L142-L145).

• The Trace route is off by default. A viewer that only adds a TraceListener shows no BGLogger output, because the TRACE target is disabled by default (src/BAUERGROUP.Shared.Core/Logging/BGLoggerConfiguration.cs:62, property at :322). I checked this with a small console program against BAUERGROUP.Shared.Core 3.0.8 that registers a TraceListener:

  Configuration.Trace default = False
  lines captured after default: 0
  lines captured after Trace = true: 1
  

These files have not changed between v3.0.8 and origin/main (git diff --stat v3.0.8 origin/main -- src/BAUERGROUP.Shared.Desktop src/BAUERGROUP.Shared.Core/Logging prints nothing).

Proposal

Build an Avalonia log viewer as a control first. It should work the same on Windows, X11 and native Wayland.

1. Embeddable control (e.g. LogViewer). The host places it in its own window: a panel, tab, splitter or overlay. This form does not depend on window position, stacking order or activation, so it behaves the same on every backend.
2. Optional window wrapper (e.g. LogViewerWindow) that hosts the same control. It is shown with an owner (Show(owner), which maps to xdg_toplevel.set_parent on Wayland, WindowImpl.cs#L235-L239). Topmost and Position are hints at most. The wrapper must stay usable when they are ignored, and must not rely on Activate() to bring an existing window back.
3. Log source owned by the control. Attach on AttachedToVisualTree and detach on DetachedFromVisualTree. Both must be safe to call twice, and nothing may be left registered after detach. Two options:
   • (a) A TraceListener that sets BGLogger.Configuration.Trace = true while attached and restores the previous value on detach. This is simple, but Trace is process-wide: all other registered listeners receive the lines too, and several viewers need reference counting.
   • (b) Preferred: a small in-process sink API in Core, e.g. IDisposable BGLogger.Configuration.AddLiveSink(Action<LogLine>). It adds an NLog target while at least one sink is registered, has no Trace side effects, and can pass the level along for colouring or filtering.
   • Not UDP: inside the same process, a fixed port and a global Network switch add nothing.
4. Bounded buffer. Use a ring buffer of N lines (configurable, default e.g. 5000) that drops the oldest lines. Render only what the buffer holds, e.g. a virtualized list, or a text view rebuilt from the buffer at a throttled rate. Never re-assign the entire accumulated text for each line.
5. Threading. The logging thread only enqueues (non-blocking, never Dispatcher.Invoke). A UI timer (e.g. every 100-250 ms) empties the queue in batches, so a burst of lines causes one UI update instead of one Post per line.
6. Autoscroll to the newest line by default, as v1 does (Logging/LogMessageReceiverControl.xaml.cs:60). Pausing it while the user has scrolled up is optional.
7. Headless tests (Avalonia.Headless) for: nothing left registered after detach, the buffer limit, and batched draining.

The UI-independent parts (the sink API and the ring buffer) belong in BAUERGROUP.Shared.Core. The existing WPF LogMessageReceiverControl can then use them too, replacing the UDP listener and fixing its buffer.

Open decision: packaging

Option	Pros	Cons
New BAUERGROUP.Shared.Avalonia package (net8.0;net10.0, no -windows)	Linux consumers get no WPF/WinForms dependency; WPF consumers get no Avalonia dependency; TFMs stay simple	One more package to version and release; CI has to build and test it on a non-Windows TFM
Inside BAUERGROUP.Shared.Desktop	No new package	Desktop is *-windows with UseWPF/UseWindowsForms (csproj:4-6), so a Linux net10.0 build cannot reference it without multi-targeting and conditional compilation; every WPF consumer would pull in Avalonia

Context

bgIndustrialAutomation Client (bauer-group/OT-AutomationClient) moved from WPF to Avalonia 12 and targets Windows and Linux. It now runs natively on Wayland through Avalonia.Wayland 12.1.2 where the compositor supports it, and falls back to X11 otherwise (bauer-group/OT-AutomationClient@0c8529b). As a workaround the application rebuilt the F12 viewer in src/BAUERGROUP.bgIndustrialAutomation.Client.App/Views/LogWindow.axaml(.cs) (application references below are at its main, commit 3f6fb39). Its remarks say the code should move into a BAUERGROUP.Shared.Avalonia package once it has proven itself (LogWindow.axaml.cs:15-20). The rebuild shows the gaps described above:

• It is a topmost window at Position="5,5" (LogWindow.axaml:9-11). Pressing F12 again calls _logWindow.Activate() (App.axaml.cs:299-303), which does nothing on Wayland.
• Its StringBuilder _buffer (LogWindow.axaml.cs:40) grows for as long as the window stays open, e.g. a whole shift. On every line, Text is replaced with the whole buffer (:87-92), so each new line costs more than the last.
• It adds a TraceListener (:55-58) but never enables BGLogger.Configuration.Trace, so under library defaults no BGLogger lines reach it (see the check above). That is a defect in the application. It is mentioned here because a control that owns its log source rules out this mistake.

The application uses BAUERGROUP.Shared.Core 3.0.8 and does not reference BAUERGROUP.Shared.Desktop. Library references are to origin/main at 02325dd.

[karlspace]

Thanks for the detailed proposal, especially the Wayland findings against the Avalonia sources. They rule out the "just port the window" approach before anyone builds it.

Feasibility: yes, and the proposed architecture holds up. I checked the current code against your problem list and it matches main (today's push changed BGLogger/BGLoggerConfiguration for #132–#135/#137 and #133, but none of the viewer, listener or Trace-target code you cite). My take on each part:

Part	Assessment
In-process sink API in Core (option 3b)	Preferred. It avoids the process-wide Trace side effect and the UDP detour. A small NLog Target subclass added to BGLoggerConfiguration.Targets while ≥ 1 sink is registered (reference-counted, removed with Reconfigure() on the last dispose) fits the existing target-toggle pattern. It can pass LogEventInfo.Level, so colouring and filtering work.
Ring buffer in Core	Straightforward and UI-independent. It also fixes the WPF LogMessageReceiverControl (Text +=, clear-all at 1000 lines) once that control uses it.
Threading (enqueue only, UI timer drains in batches)	Right for both WPF and Avalonia. ConcurrentQueue plus a 100–250 ms DispatcherTimer avoids Dispatcher.Invoke on the logging thread.
Embeddable LogViewer + optional LogViewerWindow with Show(owner)	Right split for Wayland. The control owns attach/detach, so the app-side mistake (TraceListener without Trace = true) can't happen.
Headless tests	Feasible with Avalonia.Headless + xunit. They need a non-Windows-only test project, because tests/BAUERGROUP.Shared.Test is *-windows.

Packaging recommendation: a new BAUERGROUP.Shared.Avalonia package (net8.0;net10.0). BAUERGROUP.Shared.Desktop is *-windows with UseWPF/UseWindowsForms. Putting Avalonia there would force conditional multi-targeting and push Avalonia onto every WPF consumer. The extra release cost is small: the release workflow builds and packs from BAUERGROUP.Shared.slnx, so the new project mainly needs adding to the solution, plus a Linux-capable build/test job (CI currently runs on windows-latest only).

Suggested order, so each step ships something useful on its own:

1. Core: BGLogger.Configuration.AddLiveSink(...) returning IDisposable, plus the ring buffer, with tests. Non-breaking.
2. Desktop (WPF): switch LogMessageReceiverControl to the sink and ring buffer, drop the UDP path, and mark BGLoggerNetworkListener/TextBoxTraceListener [Obsolete]. This also ends the "Network stays on forever" side effect.
3. New package: BAUERGROUP.Shared.Avalonia with LogViewer, LogViewerWindow and headless tests, plus a Linux CI job for it.

This is a feature of meaningful size (new package, CI change), so I haven't started implementation in this triage. Leaving the issue open for your go-ahead on the packaging option. Happy to split it into the three sub-issues above if that helps planning.

[karlspace]

Implemented. Thanks for the write-up — the Wayland findings against the Avalonia sources and the problem list for the existing viewer shaped the design directly, and the packaging decision you made ("new assembly") is what it was built against.

What shipped (in 4.0.0, after this push):

Part	Where
In-process live sink	BGLogger.Configuration.AddLiveSink(Action<BGLogRecord>, LogLevel?) returning IDisposable, reference-counted NLog target LIVE, no Trace side effects, no UDP (16daa65)
UI-agnostic model	BGLogRecord, BGLogViewBuffer (bounded pending ring, drop-oldest with DroppedCount, batched Drain()), BGLogViewUpdate — in Core, shared by both viewers
Avalonia package	BAUERGROUP.Shared.Avalonia (net10.0;net8.0, no -windows): embeddable LogViewer + optional LogViewerWindow with Toggle(owner) for F12 (500405e)
WPF viewer	LogMessageReceiverControl rebuilt on the same pieces; UDP path gone (95e9736)
Deprecations	[Obsolete] on BGLoggerNetworkListener and TextBoxTraceListener, behaviour unchanged (334de66)
CI	ubuntu-latest job builds and runs the Avalonia tests; release and PR validation depend on it (a4a865b)

Your requirement list, point by point:

1. Embeddable control first — LogViewer is the control; the window only hosts it.
2. Window wrapper — Show(owner) only. No Topmost, no Position, no Activate(); Toggle reads ownership back from owner.OwnedWindows, so there is no static state and no reliance on activation. Escape closes.
3. Control owns the log source — option (b), the in-process sink. Attach/detach are idempotent and gated on IsVisible, and after detach nothing stays registered (asserted against LiveSinkCount and FindTargetByName("LIVE")).
4. Bounded buffer — MaxLines (default 5 000, clamped 1..100 000) on both the pending buffer and the view; the oldest are dropped and counted, and the counter is shown in the toolbar.
5. Threading — the logging thread only enqueues; a 150 ms DispatcherTimer drains in batches, so one burst costs one UI update. Dispatcher.Invoke appears nowhere.
6. Autoscroll — follows by default, pauses while you scroll up (with a "jump to newest" button), resumes at the bottom.
7. Headless tests — 46 tests × net8.0/net10.0 covering exactly the three you named (nothing registered after detach, buffer limit, batched draining) plus scroll/pause, virtualization, theming and clipboard.

Two problems the review caught before release, both reproduced first:

• Deadlock. A sink that disposed its own registration could deadlock against another thread doing the same (config lock vs. NLog's target lock, ABBA — hung at 0/300 rounds). AddLiveSink and the registration handle now fail fast with InvalidOperationException when called from inside a callback, and the contract is documented. 300/300 afterwards.
• Leak. The first WPF version registered its sink on Loaded regardless of visibility, so a collapsed viewer captured forever. Both viewers now gate on IsVisible.

WPF burst test (20 000 lines, 4 threads): 5 000 rows kept, 2 618 counted as dropped, 71 ms maximum dispatcher latency, LiveSinkCount back to 0 after closing, Network still false, no UDP listener on 9898.

For the bgIndustrialAutomation Client: LogWindow.axaml.cs already attaches its own NLog target to BGLogger's configuration, so the migration is a straight swap — LogViewerWindow.Toggle(this, "Diagnostics") in the F12 handler, and its hand-rolled target, StringBuilder and Activate() call can go. Its Topmost/Position="5,5" were never honoured on Wayland anyway; the new window uses owner semantics instead.

Two notes: the target name LIVE is reserved for this sink (NLog replaces same-named targets silently), and the capture level defaults to LogLevel.Trace for parity with the old viewer — raise MinimumLevel in chatty processes.

[github-actions]

🎉 This issue has been resolved in version 4.0.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀