v1.5.0-beta.5 is up

[darrylmorley]

Hi all,

@jimmyorz @aguilaair @cannotcollide @Caruso8677 @Mostxlnt @aldobalducci @themadturk7 @official-Cromatin

Beta 5 is on the releases page: https://github.com/darrylmorley/whatcable/releases/tag/v1.5.0-beta.5

A lot of this build came from this group, full credits in the release notes. The short version: the Connected devices tree now gets Thunderbolt 5 daisy chains right too (beta.3 fixed TB3-era docks, which work differently; TB5 chains share one USB controller and needed their own fix), port cards hold still while power readings settle, plugging in a dock posts one notification, e-marker wording is more honest about chargers and docks blocking the read, cables with blank e-marker IDs are now trackable, and beta builds default to offering beta updates (once, without overriding a choice you've made).

Things worth poking:

• A Thunderbolt daisy chain, if you have one: open Connected devices and check every device sits under the box it's actually plugged into. TB5 gear especially.
• Plug and unplug a dock: one notification each way, naming everything.
• Save a cable that previously refused to be tracked, if you have one of those unbranded specials.

"Looks fine on my setup" replies are as useful as bug reports. Anything that looks like an actual bug gets its own issue, labelled beta, so it's findable later.

[official-Cromatin]

Can confirm that the cable change notifications name everything in one notification each way, tested with both of my docks and devices like my Apple Keyboard. Although the issue that notifications fired in close succession are silently hidden in the Notification Centre persists.
Although if you expand the notification after plugging in the dock, and leaving it expanded while unplugging it again, the notification that the device disconnected is not shown after closing the held-open notification. Neither is it saved in the Notification Centre.
In my testing it was only shown after plugging in a device that triggers a notification (charger or docking station), but it is of note that the timestamp of the notification matches the time the dock was actually unplugged versus when the notification was actually displayed. Might be some weird macOS behaviour as well.

---

After updating via the built-in updater (right-click on the menu bar icon to check for updates and confirm the update via the pop-up), I clicked on the notification after the update to learn more about it. Though it never opened it in my system-wide default browser.

While trying to replicate the issue, I downloaded the app from the prior release and upon startup I got the "You're on 1.5.0-beta.4. Click to view release notes." notification, it didn't show me the release notes upon clicking on it either.
Clicking on the main dashboard, or pop-up after manually checking for updates, on the "View release"-button worked however and opened the release of the pending update in my browser.

---

During my testing, my MacBook was plugged into the wall, via a normal charger, and after each start of the app, I got the "Charger connected"-notification about 30 seconds after the app started, when not opening the dashboard manually. When opening the dashboard, before the notification is delivered while it is closed, it triggers the notification to be displayed after two seconds or right after the app reads the negotiated PD profile.
Also of note is that the dashboard (when opened before the 30 seconds mark) updates and shows the "Charging well" right after the notification is displayed, when opening it after said mark, the dashboard already shows the "Charging well".
When my MacBook was plugged into a dock that supplied power as well, only the "Charger connected" notification is shown, not the "USB devices connected".

As I think my message is difficult to understand, the described behaviour as a mermaid diagram:

graph TD
    Start([App Starts]) --> Init{User Action?}
    Start --> PowerSource{Power Source?}

    %% Scenario 1: Dashboard remains closed
    Init -->|Dashboard remains closed| ClosedPath[Wait in background]
    ClosedPath -->|After ~30 seconds| Notif1[Notification: 'Charger connected']
    Notif1 --> OpenDashboardLater[User opens Dashboard AFTER 30s mark]
    OpenDashboardLater --> State1[Dashboard already shows 'Charging well']

    %% Scenario 2: Dashboard opened early
    Init -->|Dashboard opened manually| OpenDashboardEarly[User opens Dashboard BEFORE 30s mark]
    OpenDashboardEarly --> ReadPD[App reads negotiated PD profile]
    ReadPD --> TriggerNotif[Force notification trigger]
    
    TriggerNotif -->|After 2 seconds OR right after PD read| Notif2[Notification: 'Charger connected']
    Notif2 --> State2[Dashboard updates to 'Charging well']

    %% Special Case: Wall Charger vs. Dock
    PowerSource -->|Normal Wall Charger| Normal[Behaves as described above]
    PowerSource -->|Dock supplying power| DockPath[Only 'Charger connected' notification shown]
    DockPath --> NoteDock[Notification 'USB devices connected' is NOT shown]

Loading

---

On the note of the connected / disconnected devices notification, when testing with my Thunderbolt 3 dock, the notification still said "USB devices ..." and not "Thunderbolt devices ...". It’s an admittedly small thing, but it would be great if notifications would be aware of the connection standard the port uses.

Same goes for when labeling a cable, it would be awesome if the name would be shown in the title of the notification. Maybe even together with the used connection standard.

[darrylmorley]

Thanks @official-Cromatin, this is great work. Both docks tested, timings down to the second, and a diagram when the prose got tangled. Four issues straight out of one comment.

#567 goes wider than the release-notes banner: notification clicks were never wired up at all, so no notification click does anything. Small fix, my miss. #568 is the charger notification on app start, #569 the lost disconnect (I'll try to reproduce before blaming Apple), #570 tracks both your wording suggestions.

On the colliding banners: macOS gives no way to guarantee a banner each when several post at once, but reposting under the same identifier updates a notification in place, and that's what WhatCable will do: one standing notification per event type (devices, charger), updated rather than stacked. No more banners racing each other or piling up in Notification Centre. Design notes are on #568, and it'll be in a beta for this group to judge on real desks.

[cannotcollide]

Looks good! It's nice to be able to track more cables I have lying around