Here is a thought: If you are looking to populate a GUI dropdown or selection menu with a list of discovered devices, it would be nice if the device driver gave a displayable label string that represented the device. I think that this has come up before and we sort of have this somewhat for a few devices as the "label" key in the discovered device handles.
So the thought is that rather than an api addition, or anything like that, the device driver should provide a "label" string as part of the discovered arguments. The label is not a complete set of all information about a device, but rather a convention to identify and easily distinguish a device amongst others in a list, some being of the same device type. The label should be:
reasonable length for display purposes
should identify the type of device
differentiate among similar devices (serial, id number, index...)
For the most part, this isnt an issue on SoapySDR itself, but a thought about adding this convention, which ultimately means going to various hardware support projects and add "label" if its not already present. I'm curious to hear any feedback about how that sounds, and how useful this would be. Personally, I have tried to approximate this behaviour by stringifying the args and looking for things like serial, so this is already more useful in my opinion.
And following up on that. Supposing that a device does not have a label, should we leave it up to graphical projects to make up one, or should soapysdr itself add the missing label by concatenating the driver name, and possibly other special well-known strings like serials. So, an improvised label may not look as nice, but then every application could rely on "label" being present.
All projects should have labels on their master branches. Since several already did, we only make changes to hackrf, bladerf, uhd, and limesdr projects.
Turns out GQRX uses the label convention too, and many of the gr-osmo projects aready had it.
I didn't create an automatic label when missing, but I ended up using "<driver key> <optional serial>" in pothos sdr blocks when missing. It looks reasonable.
I didn't add anything to soapy remote, but I considered appending the server addr to the label. The real goal should be to make sure that labels arent redundant, which would only happen here if the host was running the client app and also running the server.
Here is a thought: If you are looking to populate a GUI dropdown or selection menu with a list of discovered devices, it would be nice if the device driver gave a displayable label string that represented the device. I think that this has come up before and we sort of have this somewhat for a few devices as the "label" key in the discovered device handles.
So the thought is that rather than an api addition, or anything like that, the device driver should provide a "label" string as part of the discovered arguments. The label is not a complete set of all information about a device, but rather a convention to identify and easily distinguish a device amongst others in a list, some being of the same device type. The label should be:
For the most part, this isnt an issue on SoapySDR itself, but a thought about adding this convention, which ultimately means going to various hardware support projects and add "label" if its not already present. I'm curious to hear any feedback about how that sounds, and how useful this would be. Personally, I have tried to approximate this behaviour by stringifying the args and looking for things like serial, so this is already more useful in my opinion.
And following up on that. Supposing that a device does not have a label, should we leave it up to graphical projects to make up one, or should soapysdr itself add the missing label by concatenating the driver name, and possibly other special well-known strings like serials. So, an improvised label may not look as nice, but then every application could rely on "label" being present.