Gale Andrews wrote:I see no need for the font size for the label to affect the font size of the label info.
Monitor resolutions of 2560x1600 & 5120×2890 are out there and 1920x1080 is pretty much the norm for desktop monitors and most laptops now. The Audacity Developers have seen fit to give the user control of the font family & size when drawing labels; there's a reason for this – almost all the other text is fixed (it doesn't change constantly) so once a user gets out a magnifying glass and reads it a few times they can ignore it, however, the Label text must be easily read. (Aside – I contend that the Time Text Controls and the Rulers also fault (sic - I spoke the word "fall") into this must-be-easily-readable category.)
For Audacity the default 2.8 wxWidgets font (on Windows) is 8, 10 or 12 points (depending on where the font is being used); the 8 point is virtually illegible at 1920×1080, the 10 point is barely better and, with my reading glasses on, I still need to get uncomfortably close to a 19 inch screen to read 12 point.
Gale Andrews wrote:[…]the simpler the better. I think three fields (Regions/Points/Before Zero) would fit default label height with the label count alongside.
As Steve points out, given the current default height of 73 pixels, the third line is only partially visible; we would need to make the default about 80 +/- depending on language localization and if there are descenders in the strings. I can also tighten up (even more - I am already subtracting two pixels between each line) the vertical spacing. Unfortunately, "Before Zero" (and probably even "Before 0", but not the very ugly "pre-0"), even at the default font size) completely fills the width of the trackinfopanel. Language localization could also impact Points & Regions in a similar manner.
Gale Andrews wrote:
If we want more options such as default label track height, then I suggest the count display, font choices and other options are accessed by a "Label Preferences..." item in the Label Track Menu.
I really hate the idea of scattering Preference editing all over the place. If we have a menu item (main or context) which brings up a dialog affecting a "sticky" preference value (one that is recalled by being stored in the configuration file) then the "dialog" should just be the proper Preference page (if it is a value which requires textual input we could get fancy and activate the appropriate field). Of course, this brings up the concept of "non-sticky" preferences; these are rightly (pun intended) the purview of a context menu and specialized dialog; however, AFAIK, there are none of these currently.