Forgot one important thing: You should treat image size (number of sectors) and geometry as 2 different things - both in the drive emulator and in the GUI.
When you configure a drive via percom put (eg with the "configure drive" option in MyDOS) you have geometry information available. That could also be eg a 720 sectors SD "hard drive" setup (1 track, 1 side, 720 sectors of 128 bytes). The drive emulator then has to decide what to do with this info, accept it (and calculate the number of total sectors from it) or reject it.
So if you want to accept rather arbitrary geometry layouts from the percom block and show geometry info in the GUI you have to use this information.
Probably noone will care about the actual geometry info, except maybe a few expert users trying to diagnose some odd issues with DOSes/programs that are picky about drive geometry.
The important info, which is also preserved when saving and later loading an ATR is the number of sectors and the size of each sector.
When creating a new image you could present options to specify the geometry - but as there are practically no use cases for that it would only be confusing to users.
So, I'd say, best keep it simple. Leave the geometry info out, display it only on demand or display it as secondary info after/below the image size.
The primary info should be the unambiguous number of sectors+density and when creating new images standard options like 90/130/180/360k should be well understood by users.
Yes, this is what RespeQt actually does. It uses (for formatting) a disk geometry information derived from a PERCOM block if received from a DOS.
However when we format a disk according to the information from a PERCOM block and store the disk as ATR image, it does not preserve the geometry.
When we later open the ATR image, ResepQt knows only the number of sectors and the size of each sector and may show different disk format as originally requested.
I talked to Stefan and he explained me that a DOS is actually only interested in a number of sectors and a sector size.
Physical storage parameters should actually be a "private" matter of a floppy drive,
but for some reasons a PERCOM block includes also "low level" information like: "Number of Tracks" and "Sectors per Track".
This values have to provided to a floppy drive from a DOS, however a better way would be to provide an overall "number of sectors" instead (and let floppy drive handle the way how the sectors are physically stored).