I should be clearer on which "generic" blocks are which. When we brought in gr-soapy, it had two ymls (for source/sink blocks) that contained logic to handle a variety of different SDRs, with gains and other features being enabled/hidden based on the selected sdr type. When I added one more SDR to the source yml, it became apparent that this wasn't maintainable. Every new SDR required a bunch of mods to lines throughout the yml for special cases. GRC yml is just not a good way to program complicated stuff.
So, I put those ymls in a "deprecated" category in GRC two new kinds blocks.
There are new "generic" blocks that are really generic, i.e., there is no hardware knowledge in the yml, the gains are auto-distributed by Soapy, and some of the most common parameters are available (e.g., bandwidth, gain, agc, dc offset, iq balance, freq correction). There is a "driver" field that gets "lime" or whatever, and there are device and stream arg fields, as well as tune args and "other settings". So, users may set up a single block in a flowgraph and then go back and change the type if they want. The parameters, as in gr-osmosdr, will tend to do what is expected, but can't capture some of the nuances of the hardware. Params set for one SDR may not make sense or work right when the SDR type is changed.
There are also new hardware-specific yml blocks. I didn't really want hardware-specific stuff in GR, but it seemed that (1) many users would want the simple case of a single SDR and would want to see only the most important parameters for that hardware, (2) more control could be provided where available so HackRF shows its gains broken out correctly, others show a single gain, and the actual hardware gain ranges are shown and range checked. So, the one place there is some hardware specific logic is in the SDR-specific yml files, and we can live with that. People can contribute more of them, or write their own. One thing that is admittedly going to confuse people is that the meaning of gain is not standardized, and sometimes for good reason. On a HackRF, it matters how you distribute the gain, some hardware has a separate RF amp that gives part of the gain, etc.
One goal was to make sure that flowgraphs could be built/edited with no hardware or drivers present. So there is no "discovery" in the template code in the yml files. The hardware specific yml files helped with this.
A future goal is to have a Soapy source widget that allows you to discover and interact with hardware at runtime, as in GQRX.
The yml blocks implemented so far are what I figured were enough to get people going and get some feedback, so thanks for starting to look at this. After you try out the generic (non-deprecated) and hardware-specific blocks, let me know what you think.