Add HSync

[probonopd]

Repository: https://github.com/HalfSweet/HSync

A modern logic analyzer app

• Stars: 13
• Release with the AppImage: v0.2.0 (2026-10-13T09:28:47Z)
• AppImage asset: HSync_0.2.0_amd64.AppImage
• License: Apache-2.0

Found by .github/workflows/discover-apps.yml, which looks for GitHub
repositories that publish AppImages but are not in the catalog yet. This
entry was not tested by a human; please review it before merging.

[github-actions]

❌ Test failure

@HalfSweet: this pull request adds the AppImage from your GitHub repository to the AppImage catalog; the test reports the following. Could you have a look?

HSync

Tested:

• HSync_0.2.0_amd64.AppImage from release v0.2.0

Compatibility: not self-contained: uses the C library of the system; references glibc 2.35

• The window is empty, e.g., only a menu bar on a blank background. The application must show its content when started without arguments and without network access.

First error in the log:

ERROR: The window appears to be empty (99% one color, almost no text)
Screenshot: letters by script: 0 Latin, 0 Chinese/Japanese/Korean, 0 Arabic, 0 Cyrillic/Greek

What next: once the AppImage is fixed (e.g. in a new release), comment /retest here to test it again. If it should not be in the catalog after all, close this pull request; an app that is already in the catalog can be removed by a maintainer with /remove.

Commit a9202b0. Full log

[HalfSweet]

I reproduced this as a screenshot geometry issue using the original contents extracted from the v0.2.0 AppImage under Ubuntu 22.04 (amd64 via Colima/Rosetta), with networking disabled.

The Xvfb screen is 800x600, while HSync opens a centered 1440x900 window. The run logs show:

0x200003 "HSync": ("hsync" "Hsync")  1440x900+-320+-150  +-320+-150

fit_main_window() in code/worker.sh rejects the negative absolute coordinates: its final [-+][0-9]+[-+][0-9]+ pattern does not match +-320+-150. In my reproduction it consequently selects IceWM's 800x26 taskbar instead. HSync remains off screen, so the screenshot shows only the empty central waveform area.

Moving and resizing the same running window onto the screen reveals the controls. With IceWM started first and enough screen space, the entire startup interface renders; a Demo capture also completes offline with 131072 samples.

Could the window-fitting code handle X11's +-N coordinate format and exclude window-manager helper windows? Allowing an optional minus after each coordinate separator ([-+]-?[0-9]+[-+]-?[0-9]+ for the final absolute coordinates) fixes the selection against the reproduced window-tree output. HSync's minimum window height is 640, so a display taller than 600 would also help.

[probonopd]

@HalfSweet, thank you for the thorough reproduction; your diagnosis is exactly right, and sorry that it took a bug on our side to keep HSync out of the catalog.

I checked the two patterns against the window-tree line you quoted. The final [-+][0-9]+[-+][0-9]+ in fit_main_window() indeed does not match +-320+-150, and take-screenshot.sh has the same pattern, so the largest matching window was IceWM's 800x26 taskbar and HSync was never moved on screen. #10302 fixes both: each coordinate now allows the +-N form ([-+]-?[0-9]+), and the window manager's own windows are left out of the choice. With your three-line sample the fitter now picks 0x200003 1440x900 and the screenshot code parses +-320 +-150, which its clipping already handles.

The 800x600 screen is a separate limitation: HSync's minimum height of 640 is more than the screen allows, so after the move the bottom of the window will still be cut off. A taller Xvfb screen is a wider change (the screenshot checks were calibrated on 800x600 captures) that the maintainers will decide on separately. Once #10302 is merged, this pull request will be re-tested so that the result reflects the fix.

---

Generated by Claude Code

[probonopd]

/retest

[github-actions]

❌ Test failure

HSync

Tested:

• HSync_0.2.0_amd64.AppImage from release v0.2.0

Compatibility: not self-contained: uses the C library of the system; references glibc 2.35

• The window is empty, e.g., only a menu bar on a blank background. The application must show its content when started without arguments and without network access.

First error in the log:

ERROR: The window appears to be empty (99% one color, almost no text)
Screenshot: letters by script: 0 Latin, 0 Chinese/Japanese/Korean, 0 Arabic, 0 Cyrillic/Greek

What next: once the AppImage is fixed (e.g. in a new release), comment /retest here to test it again. If it should not be in the catalog after all, close this pull request; an app that is already in the catalog can be removed by a maintainer with /remove.

Commit a9202b0. Full log

[probonopd]

Not sure whether my fix using Claude is correct. What is the application supposed to show on a 800x600 screen?

[HalfSweet]

@probonopd Your fix works in my local reproduction. This is the expected startup screen at 800×600, using fit_main_window() and take-screenshot.sh from the merged #10302 (bba6b29):

The visible controls should include the Demo device selector, sampling settings, Trigger, Capture, search bar, and Add decoder. The central waveform area is intentionally empty until the user clicks Capture. The built-in Demo device works without hardware or networking; no application arguments are needed. The IceWM taskbar at the bottom belongs to the test desktop.

I tested the original contents extracted from the v0.2.0 amd64 AppImage on Ubuntu 22.04 via Colima/Rosetta, with networking disabled and the same two WebKit rendering environment variables as the worker. The fixed fitter selects HSync and moves it to (0, 0). It requests 796×570; the resulting window is 796×640 because of the application's minimum height. Thus the bottom of the application is still clipped on this screen, but the top controls are visible.

The latest failed run 38950528658 still used the old fitting code:

• The checkout log says HEAD is now at 5ad1c72e2, merging this PR into e18db8263fc973d3ffd797b21143b538c94f307c.
• At 18:52:30 UTC, the printed fit_main_window() still ends its coordinate pattern with [-+][0-9]+[-+][0-9]+ and has no IceWM exclusion.

That run therefore does not validate #10302. Could you run a fresh test whose checkout includes bba6b29, rather than the older merge snapshot? The screenshot above shows that the merged fix resolves the off-screen controls in this reproduction.

[probonopd]

/retest

[github-actions]

✅ Test passed

Please check that the screenshot shows the application's main window.

HSync

Tested:

• HSync_0.2.1_amd64.AppImage from release v0.2.1

Compatibility: not self-contained: uses the C library of the system; references glibc 2.35

Warnings:

• The AppImage contains no update information, so users cannot update it with AppImageUpdate or similar tools. Please consider embedding it when building the AppImage (e.g., appimagetool -u) and publishing the .zsync file next to the AppImage; see https://docs.appimage.org/packaging-guide/optional/updates.html

Commit a9202b0. Full log