Runtime-loaded styles.css; Linux Hamlib/QMX launcher wrapper; readable form-field text - #799
Closed
laniol8926 wants to merge 9 commits into
Closed
laniol8926 wants to merge 9 commits into
laniol8926 wants to merge 9 commits into
Conversation
…time Tauri embeds frontendDist into the compiled binary at build time (confirmed directly: editing the bundled dist/styles.css post-build and relaunching the same binary had zero effect on rendering), so any styling change previously needed a full rebuild to take effect -- painful with a Rust/Tauri build on constrained hardware, and heavy iteration on the stylesheet expected. New get_custom_css command (main.rs) reads a real file from the app's data directory (~/.local/share/FT8AF/styles.css on Linux) fresh on every launch, seeding it from the compiled-in default (public/styles.css, via include_str!) on first run so there's something to open and edit immediately. main.tsx now awaits this and injects the result as a <style> tag instead of a static Vite-bundled import, so editing that file and relaunching the app picks up changes with no rebuild at all -- same "resolved live, not baked in at compile time" idea already used for the Hamlib rig list. Verified end-to-end with a real screenshot test: launched the built binary, edited the on-disk styles.css to a loud, unmistakable color with no rebuild, relaunched the same binary, and confirmed the new color rendered. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…onflict
rig.rs's load_hamlib() does a bare dlopen("libhamlib.so.4") -- resolved
against whatever the dynamic linker finds first. On this machine that's the
distro-packaged libhamlib.so.4 (Hamlib 4.5.4), which has no QMX support at
all (confirmed: 0/283 rigs listed included QMX, and rig_init failed for
model 2057). A separately-built Hamlib 4.7.1 already exists at
/usr/local/lib/libhamlib.so.4 with QMX support (RIG_MODEL_QRPLABS_QMX
present) -- same soname as the system package, so whichever the linker
resolves first wins for any process that doesn't override the search path.
Not fixed by upgrading the system package: other software on this machine
(CQRLOG) depends on the distro Hamlib specifically. desktop/linux/run-ft8af.sh
instead sets LD_LIBRARY_PATH just for FT8AF's own process, so it
preferentially finds the newer build without touching anything system-wide.
Falls back to the system Hamlib (previous behavior) if no /usr/local build
exists.
Verified end-to-end through the wrapper: rig list jumps from 283 to 321
entries (QRPLabs QMX now included), and the app made a real, live CAT
connection to a physical QMX (kenwood_transaction traffic, frequency set,
54ms round-trip) -- confirmed via screenshot showing "rig: qmx" instead of
"no rig".
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…e widget background select and input elements set background: var(--panel) (dark), but WebKitGTK's native rendering doesn't fully respect that for <select> -- confirmed live, the rig/band dropdown and text fields render with a light background regardless, so the existing color: var(--text) (light, #d7e0e8 -- meant for dark panels) made every text box's contents nearly unreadable. Verified live via the new runtime styles.css: edited the on-disk file, relaunched with no rebuild, confirmed all Settings-tab inputs (Callsign, Grid, Display name, Radio) and both dropdowns (rig/band picker, Backend, Input/Output device) now render crisp black text. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Same root cause as the earlier unreadable-text fix (light --text color on a light native widget background), but a separate CSS property: caret-color was never set, so the blinking text cursor was effectively invisible. This explains a real, confusing user-facing symptom: with no visible caret, retyping a value without first clearing the field silently inserts new characters at the actual (but invisible) cursor position instead of replacing anything -- confirmed live, a garbled "AI5IIAI5IIAI555" ended up saved after a few real attempts to enter a callsign, matching exactly what duplicate-insertion-without-clearing produces. Root-caused by resetting the field to empty and typing a single character with the caret-color fix applied: cursor now renders as a clear, visible black line, confirmed both in a screenshot and by the user directly on the live display. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This reverts commit d42c4a8.
…ht native widget background" This reverts commit fb86646.
… field The earlier global select/input color override broke real keyboard input entirely (reverted in fb86646/28463d2 -- see project memory: project_ft8af_webkitgtk_input_bug.md). This is narrower and confirmed different: targets only the one Display name <input> via its placeholder text as a CSS attribute selector (no JSX change, no rebuild needed), not the shared select/input rule that also matches every native <select> dropdown. Verified live, twice, with a real keyboard: text renders white and readable, and typing into the field still works normally -- unlike every variant of the global rule change, which broke input every time it was tried. Callsign/Grid and the <select> dropdowns are untouched by this commit and still use native-default text color. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Extends the single-field-scoping approach validated in 9680d65 (Display name input) to every select that was unreadable against its native light background: Band, Rig control (Backend/Radio/Connection/Serial port/Baud), Audio (Input/Output device), and Developer waterfall FFT (Window function/FFT size/Averaging). Each gets its own id and a CSS rule targeting just that id -- the shared select/input rule stays untouched, since overriding color there is what broke real keyboard input earlier (see project_ft8af_webkitgtk_input_bug.md). Verified live with a real keyboard across two rebuild/retest cycles: closed-select display text and open dropdown-list text both render black and readable, Callsign/Grid typing still works normally, and none of the scoped selects show any of the input-blocking behavior the global rule change caused. Also commits main.rs's `--list-audio` debug helper (used earlier tonight to diagnose the audio device list, analogous to the existing --list-rigs) -- prints cpal's enumerated input/output devices and exits. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
New RX gain slider (0-100%, default 100%/unity) mirrors the existing TX gain pattern end to end: a lock-free atomic in the audio capture callback (AudioInput::set_gain(), read fresh per sample on the realtime thread, no locking), an EngineCommand::SetRxGain handler that persists to config and applies live without restarting capture, a set_rx_gain Tauri command, and an ipc.ts wrapper. Placement: next to the All/CQ/To me filter chips on the Decode screen, not buried in Settings -- real feedback was that this needs adjusting per-band (noise floor varies a lot band to band) while actively watching decodes, the same reasoning that will apply to relocating TX gain next to a future Tune button. Range settled at 0-100% (matching TX gain) after live testing: temporarily widened to 0-800% to confirm the control had real effect (confirmed: mute at 0%, a genuine clip warning near 800%, proportional movement of the raw dBFS meter in between), but adjustment past 100% wasn't practically useful -- the QMX's USB audio codec has no analog preamp stage (confirmed via amixer: only a capture on/off switch, no volume control), so there's no real gain headroom on the input side to exploit past unity. Settled on 0-100% for finer control resolution across the range that matters. Both TX and RX gain sliders now debounce their backend IPC call (~120ms after the last onChange) while keeping the displayed value instant -- dragging fires far more onChange events than needed, and that load stacking on the waterfall's own frequent canvas redraws correlates with a real WebKitGTK renderer crash observed live (the WebKitWebProcess child disappeared entirely, leaving a blank window, while the Rust backend kept running) -- not proven as the sole cause, but a safe mitigation regardless. Also clarified: the waterfall's lack of visible change across the gain range is by design (its own noise-floor-relative auto-leveling, stated in its own code comment), and the raw "audio dB" meter reading "silent" at low gain while decodes keep working is expected too -- it measures broadband RMS while the decoder/waterfall work in narrow FFT bins, and FT8 is designed to decode at very low SNR. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Owner
|
Thanks for the PR! Unfortunately, you had it targeted at |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## dev #799 +/- ##
============================================
- Coverage 21.66% 21.60% -0.06%
Complexity 149 149
============================================
Files 163 163
Lines 20877 20932 +55
Branches 3128 3128
============================================
Hits 4523 4523
- Misses 16167 16222 +55
Partials 187 187
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
7 tasks
Author
Author
|
Done.
Leo, AI5Ii
…On Mon, Sep 7, 2026, 9:09 PM Patrick Burns ***@***.***> wrote:
*patrickrb* left a comment (patrickrb/FT8AF#799)
<#799 (comment)>
Thanks for the PR! Unfortunately, you had it targeted at main instead of
dev. do you mind fixing the PR or close this one and put your changes on a
new one off of dev?
—
Reply to this email directly, view it on GitHub
<#799?email_source=notifications&email_token=A5S7GWDLDOSP32ISBGD6H3D5N5L5JA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNJXG42TGOJTGY42M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-5577539369>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/A5S7GWCINL7IIEM5A5J7XHD5N5L5JAVCNFSNUABGKJSXA33TNF2G64TZHMYTEMZXHA4TOMBVGY5US43TOVSTWNJTGUZDQMRSGE3TTILWAI>
.
Triage notifications, keep track of coding agent tasks and review pull
requests on the go with GitHub Mobile for iOS
<https://github.com/notifications/mobile/ios/A5S7GWGH4J3UXPREWYEHSM35N5L5JA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNJXG42TGOJTGY42M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG>
and Android
<https://github.com/notifications/mobile/android/A5S7GWCT4DYQNSXLJDGKJ3T5N5L5JA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNJXG42TGOJTGY42M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>.
Download it today!
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
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
2 participants
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.
Summary
Three related desktop-app changes from real testing on Linux (aarch64), all verified live against a physical QRP Labs QMX transceiver:
Runtime-loaded styles.css:
styles.csswasimported inmain.tsx, so Vite bundled it into a content-hashed file that Tauri embeds into the compiled binary at build time. Confirmed directly that editing the bundleddist/styles.cssafter a build and relaunching the same binary had zero effect. Now aget_custom_cssTauri command reads a real file from the app's data directory (~/.local/share/FT8AF/styles.csson Linux) fresh on every launch, seeding it from the compiled-in default on first run.main.tsxawaits this and injects the result as a<style>tag before rendering. Editing that file and relaunching now picks up changes with no rebuild at all.Linux launcher wrapper for a real Hamlib version conflict:
rig.rs'sload_hamlib()does a baredlopen("libhamlib.so.4"), resolved against whatever the dynamic linker finds first. On a system with both a distro-packaged Hamlib (no QMX support) and a separately-built newer one (with QMX support) sharing the same soname, the distro one wins by default — confirmed live: 0/283 rigs included QMX,rig_initfailed for the QMX model.desktop/linux/run-ft8af.shsetsLD_LIBRARY_PATHjust for FT8AF's own process, preferring a newer Hamlib build at/usr/local/libif one exists, with zero effect on any other software on the same machine that depends on the system Hamlib package. Falls back cleanly to the system Hamlib if no such build is present.Readable form-field text: on this WebKitGTK build, several
<input>/<select>fields (Display name, Band, Backend/Radio/Connection/Serial port/Baud, Audio Input/Output device, Developer waterfall FFT controls) rendered with light text against a native light background — unreadable. Fixed by scoping acoloroverride to each individual field (viaidor a placeholder-based attribute selector), not the sharedselect, inputrule. That distinction matters: overridingcoloron the shared rule was tried first and reverted after real-keyboard testing showed it broke text entry entirely across the app (confirmed withxevthat realKeyPressevents stopped reaching the window — a WebKitGTK quirk, not a data/logic bug, and not fixed by loading the same CSS the old static way either, ruling out the runtime-loading mechanism as the cause). Scoping the same color change to one field at a time was confirmed safe across every field it was applied to.Test plan
npm run tauri build)styles.cssto an unmistakable color with no rebuild, relaunched the same binary, confirmed the new color rendered--list-rigs: rig count went from 283 → 321 entries with QMX included, and confirmed a real, live CAT connection to a physical QMX transceiver through the wrapperxev-confirmedKeyPressdelivery, and manual typing into every affected field, across multiple rebuild/retest cycles🤖 Generated with Claude Code