Do we try to maintain compatibility with original software for radios? I noticed that original software stores file in a "messed up" way with blocks order changed. Right now, I try to follow memory addresses and use sparse memmap by using its __setitem__ via subscripts and partially overwriting some data from there. Is it okay thing to do as I didn't see any other drivers doing that? It is easier to work with rather than doing some math for auxiliary block. It is way faster than copying entire memory full of unused segments and I can skip fetching non-set channels as I know bitmask.

In general, we store things as a raw dump of the memory in a file. This is sometimes the same as factory software, but often is not. Whatever is convenient is fine. We also often support read-only imports from factory software, which is an easier option in many cases. But, whatever you want to do is fine, as long as you can detect your model's files and they don't cause any false positives with others. We also need to commit to one format and not break stored files that people have from build to build.

Is there (or planned) general purpose table editor widget? It is somewhat ugly to edit FM presets as it is done now. And there is also Automatic Repeaters Offset settings, tone codes, and 4(!) lines of power-on welcome message with various font sizes and alignment. It looks somewhat cluttered now. Some generic table widget would be better. Did I miss it? Is there an example?

I don't think a table view of the settings would be something I'd find more appealing, personally, and I think it would be hard to represent some of the things we have to provide in that fashion. But, you're welcome to work up a proof of concept and try to convince us that it's a better approach.

Is there an extensive list (wiki?) with all common namings? I mean like how to name things in that data blob as I see code outside of drivers uses some... like autorpt. What would I name frequency ranges? I guess more generic question is: are we trying to achieve cross compatibility like loading settings (besides channels) from other radios?

I'm not sure what you're asking exactly. The memory structure definitions you provide to bitwise are really private names and don't need to be standardized for any reason.

Also I see some non-DRY code in drivers regarding charset filtering, block reading/writing and checking things (send something & expect 0x06). There are tons of similar looking code between Wouxon and Baofeng. How shall I approach it? Copy/paste and modify as necessary for now? I feel like since I'm writing the new one, I still can do it right. Perhaps it would be nice to have an extra class to derive from that would define ACK for write commands, and form read command via struct "<cHb" and check "Hb" part in return.

The problem here is that many of these drivers were written by multiple people over many years. Since most of the drivers were written by people borrowing radios, there was no opportunity to refactor a driver that turned out to offer some commonality *and* test that both still worked after that occurred. There is a ton of little stuff like that where someone borrows a piece from a yaseu driver and a piece from a wouxun driver to make a foobar driver. The potential for breakage trying to refactor the two existing into something upon which the third can be built on is high.

It would be nice if we had access to all the models we support so we could clean things up whenever we find commonalities and test that we didn't break anything. That's just not a reality.

If you have the ability to test multiple drivers after doing a refactor, then that's great. But please don't speculatively refactor something that "should work" and ask for it to be applied. Many of these radios are very particular about timing and other related things and breaking things and finding out about it in six months when someone with a rare model realizes it's broken is a bad place to be.

--Dan