pixelbox VS nearby

I include the onnx file in resources folder and use tract at runtime. You can see how it's generally used in this file: https://github.com/JosephCatrambone/pixelbox/blob/main/src/image_hashes/convnet.rs

The full source is here: https://github.com/JosephCatrambone/pixelbox/blob/main/src/ui/image_table.rs

I wouldn't recommend it, but here's my source tree if you're curious https://github.com/JosephCatrambone/pixelbox

I didn't think anything would take me away from FLTK, but I've started to default to egui for my projects. I'm still a bit of a novice, but I enjoy it. My code's a mess, but one of the more fun projects I built with it was a desktop image search app: https://github.com/JosephCatrambone/pixelbox

Did they? I know of https://github.com/google/nearby, but I don't think it's enough to implement. I could be wrong but...

nearby is open, hence my suggestion :) https://github.com/google/nearby

You may want to check this project out: https://github.com/google/nearby. It is in C++, though. It is a medium agnostic socket over bt and wifi. It seems similar to what you are trying to do.

Yeah, I respect the fact that Google made Nearby Share open-source recently (https://github.com/google/nearby-connections).

No plans for Linux right now. You're right that parts of the port would be easier for Linux than Windows. We have a /platform folder (https://github.com/google/nearby-connections/tree/master/cpp/platform/impl) that has abstractions for concepts like 'file', 'lock', and 'bluetooth_classic'. We're having to rewrite a lot of the core files ('file', 'lock', 'thread') for Windows while we could have reused what we already have if we were targeting Linux/MacOS. But rewriting the radio classes ('bluetooth_classic', 'wifi_lan', 'ble') would have had to happen regardless.

See: https://github.com/google/nearby-connections