WhatCable sits in your menu bar and reads the cable data your Mac already has access to. Plug in a cable and it tells you in plain English what it can actually do: charging wattage, data speed, display support, Thunderbolt, etc.
Built in Swift/SwiftUI. Open source, free, no tracking.
Just wanted to say this because I feel it's really crazy that I can just do this today...
Although I imagine if you don't have the motivation to make it in the first place, you likely don't have the motivation to package it.
Edit:
https://github.com/Zetaphor/whatcable-linux
Running on my Fedora KDE machine right now. Also includes a CLI so you could wrap your own widget
I still need to figure out publishing, doing this in between work meetings.
Making something has a well-defined end. Packaging something for distribution is an easy way to walk yourself into a long-term commitment.
Is that date significant somewhere? It was an nice sunny Friday for me.
I fixed lots of old tools' issues with using older broken APIs as well this way.
* Don't like menubar apps? you you can run it as a normal app
* Don't like GUIs? Now you can run it on the command line
Just look at that Changelog:
The problem of course is that on my 14” screen the area to the right of the notch is already close to full and I don’t even have that many things there…
For this kind of read-only tool, I doubt that’s the case. A regular application probably serves most users better.
Also, if you want users to have the option of permanently displaying this kind of info, a desktop widget (https://developer.apple.com/documentation/widgetkit) may be a better option than a menu bar item.
My menu bar is also full and, unlike the Dock, I can’t resize it to fit more.
defaults -currentHost write -globalDomain NSStatusItemSpacing -int 2
defaults -currentHost write -globalDomain NSStatusItemSelectionPadding -int 2
Replace write with delete to undo.
How is this conducive to the typical usage pattern of an app like this?
Well, I can think of one reason why it wasn't that much more trouble. François Chollet had a nice tweet [1] on why removing human cognitive friction is resulting in needless software complexity.
[0] https://github.com/darrylmorley/whatcable/blob/main/Sources/...
If so, it feels like a needlessly indirect and combative way to go about it.
Following that logic, every application you use more than a handful of times should live there.
Anyway. I'm not trying to argue, I think this is a neat tool, but when the Windows tray got bloated with icons people used to complain about it.
Seems the Intel southbridge isn't known to expose the needed info.
1. What does the host support
2. What does the cable support
3. What does the device support
4. What actually got negotiated
Detecting whether the signal characteristics are close enough to in-spec or not requires a speed test, perhaps, but that also doesn't necessarily mean the cable is the problem if such a test failed.
I don't think I can abide running vibe-coded software, but maybe I'll make a hand-coded fork now that the SPI is exposed. (Assuming it works correctly.)
That should be mandatory.
Not sure if it's using the same thing this MacOS thing is doing. In the link the author explains that the cable e-Marker contains a "Discover Identity" message that you can read and display in ChromeOS. Most ordinary Windows hardware can't read it because of BIOS limitations, but Chromebooks can. I'm guessing Macs can too.
You know you can close it? :-)
Interesting - do we know why that api is not allowed? I see no reason, especially if it would also require runtime permission from user.
I like this tool, but I agree that it was rushed and it is still being rushed. I urge the developer to slow down and get it right.
Shipping early is an entirely valid dev strategy.
That's all the program is telling you. It doesn't matter that it's backwards, but technically it is.
WhatCable says "No USB-C Ports Detected".
System info clearly shows my iPhone attached to USB 3.1 Bus.
P.S. Some time ago I learnt through HN of a one-line command in macOS which revealed the power (Wattage) of the connected charger. Can't find it now, but it was very useful.
Gist of random (human-written) power-related commands to peek at random power info: https://gist.github.com/nhecker/8e850773ff229724ce361967cc22...
For your last point, you're probably looking for something like `ioreg -raw0 -c AppleSmartBattery | plutil -extract 0.PowerTelemetryData.SystemPowerIn raw -` (The source for that last command is from the above gist: https://gist.github.com/nhecker/8e850773ff229724ce361967cc22... ) Or maybe `pmset -g ac | head -n3` is helpful, too. HTH.
_nick
(edit1: formatting)
(edit2: there's also https://news.ycombinator.com/item?id=47677607 which seems pretty cool but is quite complex, and might be overkill)
(edit3: different method for printing adapter wattage)
Great work!!!
This would be so useful...
It just tell you want the e-marker said.
You'd need proper hardware capable of testing bandwidth, power, noise, etc, which is prohibitively expensive.
Which isn't helpful if the cable has no e-marker.
USB c is really just a connector standard, but vendors sell the cables as if it’s a cable standard. It’s a failure of the USB standards group to establish conduductor, pinout, shielding and protocol standards for consumers to understand.
There should be color and markings on USB C cables similar to resistors so you can immediately tell WTF the cable is capable of before and during use.
What was the hardest thing you cut to keep it tiny? I keep adding "one more useful thing" and have to talk myself down.
